重传机制概述：为什么需要重传、超时重传与快速重传

TCP 号称可靠传输，但网络环境从来不是完美的。丢包、乱序、延迟抖动——这些才是常态。我做了十几年网络排障，见过太多因为重传配置不当导致业务雪崩的案例。说白了，重传机制就是 TCP 在不可靠的 IP 层之上，自己给自己兜底的一套保命方案。

为什么需要重传？

你想想看，数据发出去之后，发送方怎么知道对方收到了？唯一的证据就是 ACK。如果 ACK 没回来，发送方只能做两种假设：要么数据丢了，要么 ACK 丢了。无论哪种情况，都得重传。

我在项目中遇到过最典型的一个场景：某金融系统的交易网关，白天高峰期突然出现大量超时。抓包一看，TCP 重传率飙到 15%。原因很简单——中间一台交换机缓存满了，把数据包悄悄丢了。如果没有重传机制，那笔交易就永远消失了。

超时重传（RTO）基本原理

超时重传是最原始、最直觉的方案：发一个包，开一个定时器，时间到了 ACK 还没回来，我就再发一次。

但问题来了——这个定时器设多久？设短了，网络稍微慢一点就疯狂重传，造成拥塞；设长了，丢包后要等很久才能恢复，用户体验极差。

我记得刚入行时，有个老工程师跟我说过一句话：「RTO 不是拍脑袋定的，是算出来的。」TCP 会动态测量 RTT（往返时间），然后根据 RTT 的波动情况计算 RTO。公式大致是：

RTO = SRTT + max(G, 4 × RTTVAR)

其中：
SRTT   = 平滑后的 RTT（加权平均）
RTTVAR = RTT 的偏差（抖动）
G      = 时钟粒度（通常 1ms 或 10ms）

这个公式的核心思想是：不仅要考虑平均延迟，还要考虑延迟的抖动。如果网络很稳定，RTO 就接近 RTT；如果网络忽快忽慢，RTO 就要留出余量。

超时重传还有一个关键细节：指数退避。第一次超时后，RTO 翻倍；第二次再翻倍……直到达到上限。为什么要这样？因为连续超时说明网络可能已经拥塞了，这时候再疯狂重传只会雪上加霜。

快速重传原理

超时重传有个致命缺陷——慢。等 RTO 超时，往往已经过去几百毫秒甚至几秒。对于实时性要求高的场景（比如视频会议、在线交易），这个延迟不可接受。

快速重传的思路很巧妙：不用等超时，靠 ACK 来触发。

具体怎么做的？假设发送方发了包 1、2、3、4、5。包 2 丢了，接收方收到包 3 时，发现序号不连续，于是立即回复一个 ACK，确认号还是「期望收到包 2」。收到包 4，再发一个 ACK 要包 2。收到包 5，还是 ACK 要包 2。

当发送方连续收到 3 个相同的 ACK（即重复 ACK 达到阈值），它就知道包 2 大概率丢了，不用等超时，立刻重传。

快速重传相比超时重传的优势很明显：

• 速度快：通常在几个 RTT 内就能恢复，不用等指数退避
• 对网络友好：不会像超时重传那样突然爆发大量重传
• 能配合拥塞控制：触发快速重传的同时，TCP 会启动快速恢复算法，调整拥塞窗口

但快速重传也不是万能的。如果网络丢包率很高，或者接收窗口满了导致接收方不发 ACK，快速重传就失效了，最终还是得靠超时重传兜底。

两种重传的协作关系

超时重传和快速重传不是互斥的，而是互补的。快速重传负责「快」，超时重传负责「稳」。实际运行中，TCP 会优先尝试快速重传，只有在快速重传无法触发时，才退回到超时重传。

我画了一张图，帮你理清这两种重传的决策流程：

从这张图可以看得很清楚：TCP 收到 ACK 后，先判断是不是重复 ACK。如果是，计数加 1；当计数达到 3，立即触发快速重传。如果一直没有收到足够的重复 ACK，那就只能等 RTO 定时器到期，走超时重传的路径。

嗯，这里要注意一个容易被忽略的点：快速重传只重传一个包（那个被确认丢失的包），而超时重传可能会重传整个拥塞窗口的数据。这也是为什么超时重传对网络冲击更大的原因之一。