1. TCP重传基础：什么是TCP重传、触发条件与对应用层的影响
各位好，我是老张。做网络排障十几年了，抓过的包少说也有几万个。今天咱们聊聊TCP重传——这个在网络问题排查里出现频率最高、也最容易让人头疼的话题。
说实话，TCP重传本身并不复杂。但很多人一看到Wireshark里满屏的"TCP Retransmission"就慌了，觉得网络要崩了。其实不然。咱们得先搞清楚：重传到底是什么？它怎么触发的？对业务到底有多大影响？
1.1 什么是TCP重传
TCP重传，说白了就是：发送方没收到确认，于是把数据包再发一遍。
TCP是个可靠的传输协议。它保证数据从A到B，不丢包、不乱序。怎么保证的？靠的就是"确认+重传"这套机制。发送方每发一个数据段，都会启动一个定时器。如果定时器超时了还没收到对方的ACK确认，那就认为这个包丢了，于是重新发送。
核心定义：TCP重传是协议栈在检测到数据段丢失或未确认时，自动触发的数据重新发送行为。它是TCP可靠性的最后一道防线。
我记得刚入行那会儿，带我的师傅跟我说过一句话："重传不是病，重传多了才要命。"这句话我一直记着。偶尔一次重传，可能是网络抖动；但如果重传比例超过1%，那就要认真排查了。
1.2 重传的触发条件
TCP重传不是随便触发的。它有几个明确的触发条件。我把它分成两类：超时重传和快速重传。
1.2.1 超时重传（RTO）
这是最基础的触发方式。发送方发完数据后，启动一个定时器。这个定时器的时长叫RTO（Retransmission Timeout）。如果RTO到期还没收到ACK，就触发重传。
RTO不是固定的。TCP会根据网络往返时间（RTT）动态计算RTO。你想想看，如果网络延迟是100ms，RTO设成1秒，那效率太低了。反过来，如果网络延迟是200ms，RTO设成300ms，又容易误判。
我的经验：RTO的初始值通常是1秒（Linux内核默认）。但实际生产中，我见过很多RTO被调整到200ms~300ms的场景，尤其是在低延迟数据中心内部。不过调整RTO要谨慎，调得太小会导致大量虚假重传。
1.2.2 快速重传（Fast Retransmit）
这个机制更聪明。它不等到超时，而是通过"重复ACK"来触发。
场景是这样的：接收方收到一个乱序的包（比如收到了3号包，但2号包还没到），它会立即发送一个ACK，确认它期望的下一个序号（也就是2号包）。如果发送方连续收到3个相同的ACK（都是确认2号包），那它就知道2号包丢了，不用等超时，直接重传。
快速重传的好处很明显——响应更快。我做过对比测试，快速重传比超时重传平均快3~5倍。
| 触发方式 | 触发条件 | 响应速度 | 典型场景 |
|---|---|---|---|
| 超时重传（RTO） | 定时器到期未收到ACK | 慢（通常200ms~1s） | 网络完全中断、严重拥塞 |
| 快速重传 | 收到3个重复ACK | 快（通常10~50ms） | 单包丢失、轻微网络抖动 |
1.2.3 选择性确认（SACK）与重传
这里提一下SACK。很多工程师容易忽略这个选项。
没有SACK的时候，如果发送方一次发了1、2、3、4、5五个包，只有2号包丢了。接收方收到了1、3、4、5，但只能确认1号包。发送方收到3个重复ACK后，会重传2号包，但它不知道3、4、5已经收到了，所以可能把3、4、5也重传一遍——这叫"Go-Back-N"，效率很低。
SACK解决了这个问题。接收方在ACK里告诉发送方："我收到了1、3、4、5，就缺2。"发送方只重传2号包。效率高多了。
避坑指南：我曾经排查过一个案例，某业务频繁出现重传，但网络延迟和丢包率都正常。最后发现是通信双方有一方没开启SACK选项。没有SACK，即使只丢一个包，也可能导致大量不必要的重传。所以，我建议在生产环境中务必确认双方都开启了SACK。
1.3 重传对应用层的影响
重传对应用层的影响，取决于重传的频率和持续时间。我把它分成三个等级：
1.3.1 轻微影响：偶发重传
偶尔一次重传，对应用层几乎没影响。TCP协议栈会在几十毫秒内完成重传，应用层甚至感知不到。比如网页加载时，偶尔丢一个包，用户完全感觉不到延迟。
1.3.2 中等影响：持续重传
如果重传持续发生，比如每秒出现几次，那应用层就会感受到明显的延迟。典型表现：
- 页面加载变慢，但最终能加载完成
- 文件传输速度下降，但不会中断
- 视频流出现卡顿，但不会断开
我遇到过最典型的场景是：某电商平台大促期间，用户反馈下单慢。抓包一看，重传比例从平时的0.1%飙升到2%。虽然业务没中断，但每个请求的响应时间从200ms变成了1.2s。这就是持续重传的典型影响。
1.3.3 严重影响：重传风暴
当重传比例超过10%，甚至达到30%~50%时，就进入"重传风暴"状态。这时候：
- TCP连接可能频繁超时断开
- 应用层请求大量失败
- 数据库连接池耗尽
- 业务几乎不可用
我记得有一次处理金融系统的故障，后台监控显示交易成功率从99.99%骤降到60%。抓包一看，重传风暴。原因是某台交换机端口协商失败，导致大量丢包。TCP不断重传，重传又加剧拥塞，形成恶性循环。
关键指标：重传比例 < 0.1% 为正常；0.1%~1% 需要关注；1%~5% 需要排查；> 5% 属于严重问题，必须立即处理。
1.4 本章知识体系图
下面这张图把TCP重传的核心逻辑串起来了。我建议你保存下来，以后排查问题时对照着看。
1.5 小结
TCP重传不是什么神秘的东西。它就是TCP为了保证可靠性，在检测到丢包后自动触发的重发机制。触发条件有两种：超时重传和快速重传。对应用层的影响，取决于重传的频率——偶尔一次没事，持续发生就会导致延迟，重传风暴则直接让业务瘫痪。
嗯，这一章就到这里。记住一句话：重传不可怕，可怕的是不知道为什么重传。后面的章节，我会带大家用Wireshark一步步定位重传的根因。