1. 重传基础：TCP 重传机制概述
各位好，我是老张。做网络性能调优十几年了，今天咱们聊聊 TCP 重传。
重传这事儿，说白了就是「丢了重发」。但你别小看它。我在项目里见过太多因为重传导致整个服务雪崩的案例。嗯，咱们从最基础的说起。
1.1 为什么需要重传？
TCP 是可靠传输协议。它保证你发的数据，对方一定能收到，而且顺序不乱。
但网络环境不是完美的。丢包、乱序、延迟，这些是常态。你想想看，数据包在互联网上跑，经过几十个路由器，任何一个环节出问题，包就丢了。
TCP 怎么保证可靠？靠的就是确认与重传机制。
- 发送方：发一个数据包，启动一个定时器
- 接收方：收到包后，回复一个 ACK（确认号）
- 发送方：如果在定时器超时前收到 ACK，说明传输成功；否则，重传这个包
核心原则：没有确认，就没有可靠。重传是 TCP 可靠性的最后一道防线。
1.2 TCP 重传机制概述
TCP 的重传不是只有一种方式。它有好几套策略，根据场景自动切换。我刚开始做网络开发时，以为重传就是超时重传，后来踩了坑才知道远不止这些。
常见的重传机制包括：
| 机制 | 触发条件 | 特点 |
|---|---|---|
| 超时重传（RTO） | 定时器超时未收到 ACK | 最基础，但等待时间长，效率低 |
| 快速重传（Fast Retransmit） | 收到 3 个重复 ACK | 不用等超时，速度更快 |
| SACK 选择性重传 | 接收方告知哪些包丢了 | 只重传丢失的包，效率最高 |
| TLP 尾丢探测 | 发送窗口尾部数据可能丢失 | 提前探测，减少 RTO 等待 |
我的经验：实际生产环境中，90% 的重传由快速重传处理。RTO 超时重传一旦触发，往往意味着网络已经出了大问题。
咱们用一张图把重传的整体流程看清楚：
1.3 重传对性能的影响
重传是保底机制，但代价很大。我调过不少线上问题，重传往往是性能瓶颈的元凶。
具体影响在哪儿？
- 延迟增加：重传意味着数据要重新发送，RTT 至少翻倍。快速重传还好，RTO 超时重传动辄几百毫秒甚至几秒
- 吞吐量下降：TCP 的拥塞控制会因重传而触发。发送窗口减半，甚至降到 1 个 MSS。吞吐量直接腰斩
- 资源浪费：重传的数据包占用带宽，也占用发送和接收双方的 CPU 和内存
- 连锁反应：一个连接的重传可能影响同主机的其他连接。我在一个金融项目中遇到过，一个连接频繁重传，导致整个服务器的 TCP 连接都跟着抖动
- 定时器超时：发送一个数据包后，启动 RTO 定时器。超时未收到 ACK，立即重传
- 重复 ACK 计数：收到 3 个或以上重复 ACK，触发快速重传
- SACK 信息：接收方通过 SACK 选项告知哪些包丢失，发送方选择性重传
- TLP 探测：发送窗口尾部数据，如果一段时间内没有 ACK 更新，主动发送一个探测包
- 快速重传：触发快速恢复，拥塞窗口减半
- 超时重传：触发慢启动，拥塞窗口降到 1 个 MSS
- 重传有四种主要机制：RTO、快速重传、SACK、TLP
- 重传会显著增加延迟、降低吞吐、浪费资源
- 重传与拥塞控制联动，一次重传可能引发连锁反应
- 排查重传时，先区分类型，再定位根因
我曾经踩过的坑：有一次线上服务延迟飙升，我查了半天发现是某个客户端的网卡有问题，导致大量重传。但更坑的是，这个连接的重传占满了服务器的发送缓冲区，其他正常连接的请求也被堵住了。所以，重传不只是单个连接的问题，它会波及全局。
1.4 重传的触发条件与判定
怎么判断一个包是否需要重传？TCP 内部有一套精密的判定逻辑。
核心判定条件：
我的建议：排查重传问题时，先看是快速重传还是超时重传。快速重传多，说明网络有轻微丢包；超时重传多，说明网络严重拥塞或对端有问题。这两个的调优方向完全不同。
1.5 重传与拥塞控制的联动
重传不是孤立发生的。它和 TCP 拥塞控制紧密绑定。
一旦触发重传，TCP 会认为网络发生了拥塞，然后启动拥塞控制算法：
这意味着什么？
一次重传，可能导致吞吐量骤降。而且恢复需要时间。如果网络持续丢包，TCP 会一直处于低吞吐状态。
关键认知：重传是结果，不是原因。真正要解决的是导致重传的根因——丢包、延迟、缓冲区溢出等。只调重传参数而不解决丢包，是治标不治本。
1.6 本章小结
重传是 TCP 可靠性的基石，也是性能调优的重点关注对象。
记住几个要点：
嗯，这一章就到这里。后面咱们会深入每种重传机制的细节，以及怎么在实战中定位和优化。