2. 密钥同步基础：常见协议（SSH、TLS、IPsec）的握手与重传机制

我刚开始接触密钥同步那会儿，觉得不就是握个手嘛，能有多复杂？直到有一次线上服务全断了，才发现握手里面的门道太多了。

说白了，密钥同步就是通信双方在建立连接时，互相确认身份、协商加密算法、交换密钥的过程。这个过程一旦碰上网络震荡，就很容易出问题。下面我带你看看 SSH、TLS、IPsec 这三个最常见的协议，它们的握手和重传机制到底是怎么回事。

2.1 SSH 的握手与重传

SSH 主要用来远程管理服务器。它的握手过程，我总结为三个阶段：

1. TCP 三次握手：这是所有连接的基础。网络震荡时，这一步最容易出问题。
2. SSH 版本协商：双方交换版本号，确定用哪个协议版本（大多是 2.0）。
3. 密钥交换与用户认证：这是核心。用 Diffie-Hellman 算法生成共享密钥，然后用公钥或密码验证身份。

我觉得 SSH 的重传机制挺有意思的。它依赖底层的 TCP。Linux 内核有个参数叫 tcp_retries2，默认是 15，意味着会重试 15 次。换算成时间，大概要 15 到 30 分钟才会彻底放弃连接。这个时间窗口，在故障切换时还是挺吓人的。

2.2 TLS 的握手与重传

TLS 协议大家应该很熟悉了，HTTPS 的底层基础。它的握手过程比 SSH 稍复杂，但逻辑更清晰。

经典的 TLS 1.2 握手流程是：

• Client Hello：客户端发来个随机数和它支持的加密套件。
• Server Hello：服务器选好加密套件，发回自己的证书和随机数。
• 证书验证：客户端检查证书是不是真的、有没有过期。
• 密钥交换：客户端用服务器的公钥加密一个随机数（Pre-Master Secret），发给服务器。
• 完成：之后通信就加密了。

TLS 的重传机制是什么？它用的是自己的超时重传。应用层有定时器，如果没按时收到响应，就会重传握手消息。这个超时时间，很多实现都是初始 1 秒，然后翻倍，直到 60 秒封顶。我记得有一次项目里，就是因为 TLS 握手重传间隔太长，导致用户访问页面响应超慢。后来我们把超时配置改短了，情况好了很多。

2.3 IPsec 的握手与重传

IPsec 主要用于站点到站点的 VPN。它有两种模式：传输模式和隧道模式。但不管哪种模式，握手都得靠 IKE（Internet Key Exchange）协议。

IKEv1 的主模式握手有 6 个包，分三个阶段：

阶段	交换内容	备注
阶段 1（ISAKMP SA）	算法协商、DH 交换、身份认证	生成 IKE SA
阶段 2（IPsec SA）	协商具体加密参数、周期性更新密钥	生成 IPsec SA

你想想看，光 IKEv1 主模式就要来回 6 个包。每个包都是 UDP 的，不像 TCP 有内置的确认机制。所以一旦丢了一个包，整个握手就得从头来。这就是为什么在网络震荡时，IPsec 隧道经常一会儿通一会儿断。

IPsec 的重传由 IKE 自己负责。IKE 使用指数退避算法：第一次重传等 1 秒，第二次 2 秒，第三次 4 秒……直到达到最大重传次数（比如 5 次）就断开隧道。我记得有一次排一个隧道频繁重建的故障，发现就是因为对端的 IKE 重传超时设置太短，网络稍微抖一下，隧道就断了。

2.4 三种协议的核心差异总结

好，我们来看个表格，把这三个协议的握手特点放在一起对比一下：

协议	传输层	握手轮次	重传机制	网络震荡时的表现
SSH	TCP（可靠）	2 轮 + TCP 3次握手	依赖 TCP，重传次数可配置	连接长时间不释放，出现死连接
TLS	TCP（可靠）	4 轮（TLS 1.2）	应用层超时重传，指数退避	握手反复重试，可能导致用户等待超时
IPsec (IKE)	UDP（不可靠）	6 轮（IKEv1 主模式）	IKE 层超时重传，指数退避	一个包丢失，整个握手失败，隧道频繁重建

从表格能看出来，SSH 和 TLS 因为跑在 TCP 之上，多少有点“天然的抗丢包能力”——TCP 帮它们做了重传。但 IPsec 就没这么幸运了，它的重传完全靠自己，一旦丢包，代价很大。

2.5 SSH、TLS、IPsec 握手与重传逻辑图

下面这张图，我把这三个协议的握手流程和重传逻辑串在一起了。你看完应该能更直观地理解它们各自的特点。