TCP的RTO、Fast Retransmit、SACK、DSACK和RACK-TLP有什么区别？
抓包中看到 TCP Retransmission、Fast Retransmission、Duplicate ACK、SACK、DSACK 或 Tail Loss Probe 时，不能把它们都理解为“网络丢包”。RTO 是等待确认超时后的兜底重传；Fast Retransmit 根据重复 ACK 较快推断缺口；SACK 告诉发送方哪些非连续数据块已经收到；DSACK 可反馈重复收到的数据；RACK 用发送时间与确认反馈判断丢失；TLP 则在尾部缺少 ACK 时发送探测，争取避免进入昂贵的 RTO。
本文目录（29 节）
六个概念快速对比
| 机制 | 类型 | 依赖信号 | 解决的问题 | 是否直接重传 |
|---|---|---|---|---|
| RTO | 定时器 | 一段时间没有足够确认 | 所有其他反馈不足时恢复 | 是 |
| Fast Retransmit | 丢失判断 | 传统上3个重复 ACK | 窗口中间段丢失 | 是 |
| SACK | TCP选项 | 接收方报告已收数据块 | 精确识别多个缺口 | 否，提供信息 |
| DSACK | SACK扩展用法 | 第一个SACK块报告重复数据 | 识别重复到达或虚假重传 | 否，提供信息 |
| RACK | 时间型丢失判断 | 每段发送时间与SACK/ACK | 重排、短窗口及重传再次丢失 | 标记后触发恢复 |
| TLP | 尾部探测 | PTO 到期且 ACK 不足 | 尾包丢失、应用受限流量 | 发送一个探测段 |
这些机制会组合工作，而不是互相完全替代。现代 TCP 可以协商 SACK，用 RACK 判断丢失、用 TLP 激发 ACK，同时仍保留 RTO 作为最终恢复保障。
TCP为何必须能够重传
IP 网络可能因拥塞、链路错误、队列策略或路径变化丢失数据包，也可能产生乱序和重复。TCP 以字节序号记录已发送和已确认范围，发送方保留未确认数据，必要时重新发送。
接收方 ACK 中的确认号表示下一段期望收到的序号。累积 ACK 可以确认之前连续的所有字节，但单靠它难以描述连续边界之后已经收到的多个离散数据块，这正是 SACK 的价值所在。
重传标签不等于线路确定丢包
抓包工具通常根据观察到的序号、时间和 ACK 推断 Retransmission。若抓包点漏包、网卡卸载合并数据、镜像端口丢帧，工具可能把未观察到的原包或确认误判为重传。
即使发送端确实重传，也可能是原包只是延迟或乱序，后来与重传副本一起到达。要证明链路丢包，需要结合双端抓包、接口计数、路径遥测和 DSACK 等证据。
RTO是什么
Retransmission Timeout 是发送方等待确认的动态超时。RFC 9293 要求按 TCP RTO 算法计算，具体估计依据平滑 RTT 和 RTT 变化，并对超时实施退避。
当重传计时器到期，发送方重传最早未确认数据，并显著收紧拥塞窗口。RTO 能处理没有足够后续数据或 ACK 的情况，但等待时间和拥塞响应通常比快速恢复更昂贵。
RTO为何不能设成固定低值
网络 RTT 会随距离、排队、无线重传与路径变化波动。固定且过短的 RTO 会把正常延迟误判为丢包，引发虚假重传与拥塞窗口下降；过长则让真实丢包恢复缓慢。
TCP 通过采样 RTT 动态估算超时，并设置下限、退避等规则。应用层超时也不能简单代替 TCP RTO，因为应用只看到请求级等待，不掌握每个 TCP 段的确认状态。
Karn算法解决重传后的RTT歧义
某段重传后收到 ACK，发送方通常无法确认 ACK 对应原始发送还是重传副本。若直接把这段时间作为 RTT 样本，估计可能严重失真。
Karn 算法避免从存在重传歧义的确认中采样 RTT，并配合 RTO 退避。启用 TCP Timestamp 时可提供更多信息，但实现仍需遵循适用的 RTT 测量规则。
Fast Retransmit如何工作
接收方收到高于当前缺口的乱序段时，会立即发送 Duplicate ACK，继续确认它仍期望的序号。传统 Fast Retransmit 在发送方收到3个重复 ACK 后，推断某段可能丢失，不等待 RTO 就重传缺口开头。
“3个”是判断阈值，不代表网络固定丢了三包。每个后续乱序到达的段都可能产生一个重复 ACK，它们共同说明数据仍在流动但序号空间存在缺口。
Fast Recovery与Fast Retransmit区别
Fast Retransmit 是触发缺失段重传的判断与动作；Fast Recovery 是重传之后对拥塞窗口和新数据发送的管理。RFC 5681 将两者一起描述。
由于重复 ACK 表明部分后续段已到达，ACK 时钟仍在运行，发送方无需像 RTO 后那样完全回到最保守起点，但仍会减少拥塞窗口，因为丢失通常被视为拥塞信号。
Duplicate ACK也可能由乱序产生
多路径、链路聚合、无线重排或设备并行处理可能让后发送的数据先到达。接收方看到缺口便产生重复 ACK，即使缺失段只是稍晚到达。
如果重排深度达到传统阈值，发送方可能产生虚假快速重传。DSACK 与 RACK 的重排窗口适应可帮助识别和减少此类问题，但不能把所有 Duplicate ACK 都自动归类为无害乱序。
SACK解决累积ACK的信息不足
RFC 2018 定义 Selective Acknowledgment。连接建立时双方通过 SACK Permitted 选项协商能力；之后接收方可在 ACK 中列出已收到的非连续字节块。
例如连续确认停在1000，但接收方已收到2000–3000与4000–5000，SACK 可报告这些块。发送方据此优先补1000–2000和3000–4000，而不必重传所有后续数据。
SACK Block如何理解
每个 SACK Block 用 Left Edge 和 Right Edge 描述一段连续已收字节范围，右边界本身不包含在块内。TCP 头部选项空间有限，所以一次 ACK 只能携带有限数量的块。
SACK 不改变主 ACK 字段的累积含义。主确认号仍只前进到连续接收边界；当缺口被填补后，它才跨过已经缓存的后续数据。
SACK本身不决定重传策略
SACK 是接收方向发送方提供信息的机制。发送方如何维护 Scoreboard、判断某段丢失以及安排重传，由损失恢复算法决定，例如 RFC 6675 或 RACK。
因此抓包看到 SACK 不代表发送方一定立即重传，也不代表拥塞控制被关闭。SACK 改善多包丢失时的信息精度，发送方仍必须遵守拥塞控制。
DSACK是什么
RFC 2883 定义 Duplicate SACK。接收方使用第一个 SACK Block 告诉发送方某段数据被重复接收，可以是整个重复段或其中一部分。
重复到达可能来自网络复制，也可能是发送方在原包只是延迟时做了虚假重传。DSACK 为发送方判断重排和调整恢复算法提供证据。
DSACK如何帮助识别虚假重传
若发送方重传某个范围，而接收方随后报告该范围出现重复，结合时间与确认进度可推断原包和重传都到达。实现可以据此认识到先前丢失判断可能过于激进。
但单个 DSACK 不能准确指出哪条链路或哪个副本先到。它是端到端传输证据，需要和发送时间、抓包位置及 RACK 状态一起分析。
RACK的核心是按时间判断
RFC 8985 的 Recent ACKnowledgment 利用每个数据段最近一次发送时间，以及 ACK/SACK 表明的交付情况进行时间型推断。如果后发送的段已经交付，而较早发送的段在重排容忍窗口后仍未确认，RACK 可把较早段标为丢失。
它不依赖必须凑够固定数量的重复 ACK，因此对应用受限、小 Flight、重传段再次丢失和较深重排更有效。
RACK为什么依赖SACK
RACK 需要知道哪些非连续数据已经交付，并维护相应的 SACK Scoreboard；还要记录每个段最近发送时间。RFC 8985 将 SACK 支持列为要求。
如果连接未协商 SACK，发送方获得的交付信息较少，无法按同一 RACK 算法工作。检查系统是否启用 RACK 时，也应确认连接实际协商结果，而不是只看内核默认参数。
Reordering Window有什么作用
RACK 不会在看到后发段先确认时立刻宣布所有早发段丢失，而是保留 reo_wnd 作为重排容忍时间。窗口太小会把正常乱序判为丢失，太大则延迟真实丢包恢复。
实现可根据 DSACK 等信号自适应调整重排窗口。网络路径改变后，历史重排特征也可能变化，所以排查应观察一段时间而非单次事件。
TLP解决尾部丢失
如果一个发送窗口最后一个或几个段丢失，后面没有更多数据到达接收方，就不会产生足够 Duplicate ACK；应用受限连接也可能只有少量在途段。传统恢复可能只能等 RTO。
Tail Loss Probe 在 Probe Timeout 到期时发送一个探测段，促使接收方返回 ACK。这个 ACK 可让 RACK 判断实际缺失并进入较快恢复，争取避免 RTO。
TLP探测包一定是重传吗
不一定。算法可以发送新的数据；若没有新数据可发，则重传合适的尾部数据。抓包工具可能将后者标为重传，但其目的在于激发确认反馈。
看到 TLP 后应检查随后 ACK 是否揭示丢失、是否进入 RACK 恢复，以及最终有没有 RTO。单独统计探测次数不能直接等同业务故障次数。
PTO与RTO不要混淆
PTO 在 RACK-TLP 中用于安排尾部探测，目标是在 RTO 前获取 ACK 反馈；RTO 是 TCP 的最终重传超时与恢复机制。二者定时依据和拥塞后果不同。
QUIC 中也使用 PTO 一词，但其恢复规范与 TCP RACK-TLP 不同。分析工具若只显示“PTO”，必须先确认传输协议和实现上下文。
RACK-TLP与传统DupACK方案关系
RFC 8985 推荐 RACK-TLP 作为传统重复 ACK 计数方法的替代方案。它仍使用 ACK、SACK、RTT 和拥塞控制，只是把主要丢失判断从计数转向时间与交付顺序。
系统可能在不同连接条件下同时保留多个机制，RTO 更不会消失。不能期待启用 RACK 后抓包中再也没有 Fast Retransmit 或超时。
多包丢失时为何SACK更重要
一个窗口内多个不连续段丢失时，累积 ACK 每次只能暴露最左侧缺口。没有 SACK，发送方可能需要多个 RTT 才逐步发现全部丢失，或者进行不必要重传。
SACK Scoreboard 让发送方知道已到达块与缺口，再结合恢复算法安排多个重传。高带宽时延积链路尤其受益，因为一个窗口可包含大量在途数据。
如何从抓包区分几种事件
RTO 常表现为较长静默后重传最早未确认段，且之后发送速率明显下降；Fast Retransmit 前通常有连续 Duplicate ACK；SACK 位于 ACK 的 TCP Options 中；DSACK 的首块报告已由累计 ACK 或其他块覆盖的重复范围。
RACK 与 TLP 属于发送端实现逻辑，单点网络抓包未必能完全还原内部状态。结合操作系统 TCP 统计、eBPF/内核追踪和发送端日志，证据更可靠。
抓包点为何决定结论
在发送主机抓包可能受 TSO/GSO 影响，看到超大逻辑段；接收端则受 GRO/LRO 影响。中间镜像口可能因拥塞丢弃镜像流量，而真实业务包没有丢。
最好在发送端与接收端同步抓包，并校准时间。某包发送端存在、接收端不存在，才更接近路径丢失证据；只在一端看到分析器标签不足以定位责任设备。
常见调优误区
直接把 RTO 调低、关闭 SACK、强制固定重复 ACK 阈值或无限扩大重排窗口，都可能让另一类网络条件变差。应用延迟也可能来自服务端处理、接收窗口受限或队头阻塞，而非损失恢复。
调优前应测量 RTT 分布、重排深度、SACK/DSACK、拥塞窗口、RTO 次数和真实丢包位置，并在可回滚环境进行 A/B 验证。
推荐的排查顺序
先确认业务延迟与 TCP 重传时间是否相关；再核对抓包点与卸载影响；检查握手是否协商 SACK；区分 Duplicate ACK、Fast Retransmit、RTO 与 TLP；最后结合双端数据确认丢失还是重排。
若只在特定路径发生，再比较 MTU、ECMP、QoS、无线质量和中间设备队列。若所有路径均发生，则检查主机 CPU、网卡、驱动、缓冲区和应用读取速度。
常见问题
1. 三个Duplicate ACK一定表示丢包吗？
不一定。它也可能由数据重排或复制产生；传统算法把它作为足够强的丢失信号并执行快速重传。
2. 开启SACK后还会RTO吗？
会。SACK需要 ACK 反馈；如果 ACK 也缺失或在途数据太少，最终仍可能依赖 RTO。
3. DSACK表示接收方丢包了吗？
不是。DSACK 表示接收方收到了重复数据，原因可能是网络复制或发送方虚假重传。
4. RACK能完全消除误判吗？
不能。它通过时间和自适应重排窗口提高鲁棒性，但参数、路径变化和极端重排仍可能影响判断。
5. TLP会增加网络流量吗？
它会发送一个探测段，但目标是及时获取 ACK 并避免更昂贵的 RTO；仍需由拥塞控制和算法规则约束。
结论
RTO 是没有足够反馈时的最终超时恢复；Fast Retransmit 用重复 ACK 快速补缺；SACK 报告已收的离散范围；DSACK 报告重复到达；RACK 用发送时间判断丢失；TLP 用尾部探测激发 ACK。准确诊断需要区分“接收方反馈”“发送方算法”和“抓包工具推断”，再用双端证据判断真实丢包、乱序或虚假重传。
参考来源
- RFC Editor：RFC 9293 — Transmission Control Protocol (TCP)，https:
/ / www. rfc- editor. org/ rfc/ rfc9293. html - RFC Editor：RFC 6298 — Computing TCP's Retransmission Timer，https:
/ / www. rfc- editor. org/ rfc/ rfc6298. html - RFC Editor：RFC 5681 — TCP Congestion Control，https:
/ / www. rfc- editor. org/ rfc/ rfc5681. html - RFC Editor：RFC 2018 — TCP Selective Acknowledgment Options，https:
/ / www. rfc- editor. org/ rfc/ rfc2018. html - RFC Editor：RFC 2883 — An Extension to the Selective Acknowledgement Option for TCP，https:
/ / www. rfc- editor. org/ rfc/ rfc2883. html - RFC Editor：RFC 6675 — A Conservative Loss Recovery Algorithm Based on SACK，https:
/ / www. rfc- editor. org/ rfc/ rfc6675. html - RFC Editor：RFC 8985 — The RACK-TLP Loss Detection Algorithm for TCP，https:
/ / www. rfc- editor. org/ rfc/ rfc8985. html