在 Rust 中有 包、crate、模块 概念，本文我们介绍一下它们之间的关系和调用方法。 包 和 Crate 在Rust中，包（package）是提供一系列功能的一个或者多个 crate。一个包会包含一个 Cargo.toml 文件，阐述如何去构建这些 crate。 我们先看一下通过 cargo new 创建一个 my_project 包。 ➜ cargo new my_project Creating binary (application) `my_project` package note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html ➜ rust tree my_project my_project ├── Cargo.toml └── src └── main.rs 2 directories, 2 files 它将创建一个 Cargo.toml文件，内容： [package] name = "my_project" version = "0.1.0" edition = "2021" [dependencies] 文件里并没有提到 src/main.rs，因为 Cargo 遵循的一个约定：src/main.rs 就是一个与包同名的二进制 crate 的 crate 根。同样的，Cargo 知道如果包目录中包含 src/lib.

官方文档将一个模块拆分成多个文件时，介绍的是将原来多个模块写在同一个文件中，拆分成了每个模块一个文件。不过还有一种情况没有提到，如果一个模块中的某个 struct 实现代码过多时，仍写在同一个模块文件的话，维护成本就显的比较高了，这时我们可能还需要对这个 struct 的实现按某种粒度拆分成多个文件来实现。 ✗ tree . ├── main.rs ├── model │ ├── article.rs // 文章相关 │ └── user.rs // 用户相关 └── model.rs 这里是按官方教程拆分后的样子 article.rs 是文件模块相关实现 - user.rs 是与用户相关的实现 model.rs 公开模块 model.rs // src/model.rs pub mod article; pub mod user; pub 关键字表示该模块是公开的，可以被其他模块访问。 mod article 声明了一个名为 article 的模块，并且 Rust 编译器会在同文件名的目录下( src/model/ )找到一个名为 article.rs 或者 src/article/mod.rs 的文件来实现这个模块。 文章模块article.rs // src/model/article.rs pub struct Article { id: u32, title: String, } impl Article { pub fn new(id: u32, title: String) -> Self { Article { id, title } } pub fn info(&self) { println!

今天收到一个项目重构的需求，项目源码使用私有 gitlab 托管平台，但由于考虑安全原因，必须通过vpn软件才可以访问。公司用的vpn客户端是 Pritunl, 看了一下项目主页 https://github.com/pritunl/pritunl-client-electron，发现它是一个 OpenVPN 客户端，是基于Golang+Electron 框架开发的一个跨平台的客户端。 以前主要接触的是 wireGuard 和 openvpn 这两个项目，这个客户端还是第一次听说。不过后面发现使用这个客户端会经常出现DNS无法解析的情况，不清楚具体是什么原因引起的，因此不推荐这个客户端。另外从性能方面考虑openvpn也不是推荐方案，推荐优先考虑 wireGuard 这个项目，它的客户端也是跨平台的，而且性能要比openvpn好太多，代码也少很好，无论维护和开发成本都要低的多。个人有很长一段时间一直用wireGuard作为内网穿透方案，不过此方案需要一个公网IP地址，所以后期换成了更节约成本的解决方案，当然这是另一个话题了，不是本文要介绍的内容。 遇到问题 当在macOS上安装好客户端后，使用同事发给我的vpn配置文件，发现一直无法连接到vpn服务器。第一反映就是怀疑是配置文件有问题，但同事反馈一直这样用的，他也是第一次遇到这个情况，所以就排除了配置文件这个原因。 通过查看客户端也并未发现什么原因，一直在重试连接错误。 初步分析 由于以前做零信任网关时，对于网关客户端的流量拦截也是通过vpn这套机制来实现的，因此知道一般会在客户端机器创建一个 tap/tun 虚拟网卡。同时再创建一些路由规则，根据这些规则将需要代理的流量导入到创建的虚拟网卡。然后客户端再从虚拟网卡读取流量内容，然后通过 UDP 协议传到vpn服务端，最后服务端再解包重放从而进入到 vpn服务所在的内网，最终实现流量代理。 虚拟网卡 因此这里首先就要排查本机是否存在tap/tun虚拟网卡，奇怪的是竟然未发现任何虚拟网卡，为什么无法创建虚拟网卡呢？权限问题？正好本机安装有 Cloudflare WARP 这个软件，打开软件测试后，发现本机是可以正常创建 tun 虚拟网卡的，那这样就排除了权限问题了。 路由规则 上面说过vpn的原理，是通过虚拟网卡和路由来配合使用的，路由规则创建了没有？经排查路由规则也没有创建。 客户端版本 难道是客户端版本的原因？咨询了几个同事，版本有的相同，有的不同，但都可以正常连接服务器，并未出现此现象。 openvpn工作原理 由于一直无法找到原因，因此只能还是从vpn工作原理这块入手了。 前面我们知道了虚拟网卡和路由规则都没有创建，那问题会不会出现在前面的一些初始化步骤呢？要确认这一点，首先我们先看一下 openvpn的实现原理： 建立连接：OpenVPN 客户端与服务器之间首先建立一个 TCP 或 UDP 连接。这个连接可以是客户端主动发起，也可以是服务器响应客户端的请求。 身份验证：在连接建立之后，客户端需要通过提供用户名、密码或其他认证方式（如证书）向服务器进行身份验证，以确保连接的合法性。 密钥交换：通过使用密钥交换协议（如 TLS/SSL），客户端和服务器交换密钥，生成一个共享的对称密钥。这个密钥将用于后续的数据加密和解密过程，确保数据的机密性。 数据传输：一旦加密通道建立，客户端和服务器就可以在其中安全地传输数据。数据在发送前会被使用共享密钥进行加密，接收方在收到数据后会使用相同的密钥进行解密。 使用 TUN/TAP 虚拟网络设备：OpenVPN 利用操作系统内核中的虚拟网络设备 TUN/TAP 来转发数据。TUN 工作在网络层，负责 IP 数据包的传输；TAP 工作在数据链路层，负责以太网帧的传输。这些虚拟设备使得 OpenVPN 能够在用户空间处理网络数据。 配置路由：OpenVPN 服务器会为每个客户端分配一个虚拟 IP 地址，并配置相应的路由规则。这样，客户端就成为了虚拟网络的一部分，可以访问服务器所在网络的其他资源。 数据封装：OpenVPN 将网络层的数据封装在 VPN 数据包中，然后通过物理网络发送。在接收端，OpenVPN 将数据解封装，恢复原始数据包，然后通过虚拟网络设备发送给目标。 安全性：OpenVPN 支持多种加密算法（如 AES、DES、3DES 等），并提供了数据完整性检查和抗重放攻击的特性，增强了通信的安全性。 从VPN实现原理得知，我们上面排查的虚拟网卡和路由规则是步骤中的第5和第6步，现在我们只需要对前面这几步进行确认基本就可以找到原因了。

git merge 与 git rebase 的区别 对于两者的区别，网上已经有很多文章做了介绍，不过有些初学者没有亲自实验过，多数也是作为八股文死记硬背而已。本文为了让大家彻底搞懂两者的区别，所以搞了一个实验环境并模拟了一些真实环境的操作。 实验环境主要用到两个分支，其中 main 分支做了主要分支，而 dev 作为开发功能分支。 在生产环境中需要选择合适的分支，这里只是实验环境，所以分支名不是本文关注的重点。 main dev 说明 mkdir git-demo && cd git-demo && git init touch 1.txt && git add . && git commit -m ‘add 1.txt’ f3c82ba touch 2.txt && git add . && git commit -m ‘add 2.txt’ eb061da touch 3.txt && git add . && git commit -m ‘add 3.txt’ 0e71e97 ➜ git log –oneline0e71e97 (HEAD -> main) add 3.

当我们通过域名（例如 www.example.com）访问一个网站时，第一步就是通过DNS服务器找到目的服务器IP地址（例如 93.184.215.14），接着再将请求数据包发送到这个 IP 服务器。 而要想通过 DNS 服务器进行域名，必须得先知道 DNS 服务器地址才行，而这一般是通过读取配置文件实现，在 *nux 操作系统中，DNS 服务器一般配置在 /etc/resolv.conf文件，如 search default.svc.cluster.local svc.cluster.local cluster.local nameserver 10.96.0.10 options ndots:5 用户可以通过 nameserver 指定多个 DNS 服务器，依次对域名进行解析，如果解析成功，则解析操作立即中止，如果解析不到的话，则将回退到公网 DNS 服务器进行解析，这个公网 DNS 服务器一般是由网络运营商来定的，用户不需要关心。如果公网 DNS 仍解析失败的话，则直接响应域名无法解析，此时用户将无法正常访问域名。 什么是 FQDN 在介绍域名解析前，我们先了解一下什么是 FQDN。它是 Fully Qualified Domain Name 的缩写,中文称为 “完全限定域名”。 一个 FQDN 由以下部分组成: 主机名(Hostname): 如 www、mail、app 等,用于标识特定的主机或服务 域名(Domain Name): 如 example.com、company.org 等,用于标识特定的组织或网络域 根域(Root Domain): 表示为".“的根域,代表 DNS 域名层次结构的根 一个完整的 FQDN 看起来类似这样: www.example.com. 注意最后的”.“表示根域的结尾。 FQDN 的作用是唯一地标识互联网上的主机名和域名。它能够避免由于域名冲突导致的解析歧义。例如,如果有 www.example.com 和 www.example.net 两个不同的域名,仅使用 www 是不够的,必须使用 FQDN 来精确指定。