Jay's some notes

在传输控制协议（TCP）数十年的演进中，丢包检测与恢复机制始终是影响传输性能的核心环节。从最初依赖序列号判断丢包的 Reno 模式，到引入选择性确认的 SACK，再到基于时间判定的 RACK，乃至进一步强化的 RACK-TLP，TCP 的恢复能力经历了逐步现代化的升级。

本文将带你从理论层面，深入理解 TCP 的四种关键丢包检测机制：FACK、SACK、RACK 与 RACK-TLP，并对比它们的工作原理、适用场景与演进关系。

TCP 丢包检测：为什么重要？

丢包是 TCP 面临的常见网络问题。能否及时发现丢包并快速恢复，直接决定了 TCP 在以下场景中的表现：

• 弱网或移动网络（丢包率高、时延抖动大）；
• 数据中心高吞吐场景（对恢复速度敏感）；
• 中间设备存在乱序、ACK 压缩行为。

传统 TCP 采用 RTO（Retransmission Timeout） 机制来兜底触发重传。但初始 RTO 延迟高达 1 秒，误判多，恢复慢，成为瓶颈。因此，TCP 社区不断探索更快、更精准的丢包检测算法。

SACK：Selective Acknowledgment（选择性确认）

原理：

接收方在 ACK 中显式告诉发送方：“我已经收到哪些数据段”，而不是仅告诉“收到到哪了”。

例如：如果收到了第 1、2、5 段，SACK 可以告诉发送方：我收到了 [1-2] 和 [5]，中间 [3-4] 丢失。

优点：

• 精确指出哪些段被接收；
• 适用于多段丢包场景；
• 避免不必要的重复重传。

局限：

• 虽然能知道“哪里没收到”，但仍依赖序列号判断丢包；
• 容易受到网络乱序、ACK 压缩的干扰，误判丢包或延迟重传。

FACK：Forward Acknowledgment（前向确认）

原理：

FACK 在 SACK 的基础上进一步演化。它不仅看 SACK 报告了哪些段，还估算：“接收方到底收到了多少字节？”

通过前向确认值（Forward ACK），FACK 推测数据流的最前进位置，从而判断哪些段在这个位置之前却没被确认，更可能丢失。

优点：

• 提升丢包恢复的粒度与速度；
• 可以更准确判断哪些段未收到。

局限：

• 依然依赖序列号推断；
• 在中间设备导致乱序或 ACK 抖动时仍可能误判。

RACK：Recent Acknowledgment（基于时间的确认）

定义于 RFC 8985

原理：

RACK 完全抛弃了“序列号先后”来判断丢包，转而使用“发送时间”作为核心依据。

核心思想：如果一个数据段比其他段更早发送，但对方先确认了后发的数据，那么早发未确认的很可能丢了。

举个例子：

• 第 10、11、12 段几乎同时发送；
• ACK 收到 11 和 12，唯独没收到 10；
• RACK 判断：第 10 段被丢了，不等 RTO，直接重传。

优点：

• 更快发现丢包；
• 不受乱序、ACK 压缩等影响；
• 大幅提升弱网或数据中心 TCP 的表现。

前提：

• TCP 栈需准确记录每个段的发送时间；
• 依赖 SACK 辅助判断哪些段被确认。

TLP：Tail Loss Probe（尾部丢包探测）

原理：

TLP 设计是为了解决“尾部最后几个数据段被丢，但连接进入沉默”的问题。

在传统 TCP 中，这种场景只能等待 RTO 超时，可能导致 1 秒以上延迟！

TLP 的做法是：

• 检测连接是否在“尾部”安静阶段；
• 主动发一个探测包（probe）来“敲门”；
• 如果 ACK 回来，一切正常；如果没有，尽快触发重传。

优点：

• 避免长时间挂起；
• 恢复速度远快于 RTO。

RACK-TLP：现代 TCP 的黄金组合

RACK + TLP = 快速、鲁棒的 TCP 丢包检测与恢复体系

RACK 提供 时间驱动的准确丢包检测，TLP 提供 尾部沉默保护，两者组合应对大多数网络复杂场景。

这种组合是目前 Google、Facebook、AWS 等大规模生产网络中的默认选择，也正逐步成为现代 TCP 栈的主流机制。

对比总结

TCP 的丢包检测机制已经从最早的基于序号推测，演进到现在以“发送时间 + 探测包”为核心的智能模型：

• FACK 是对 SACK 的增强，更好地衡量未确认数据；
• RACK 是范式转移，开创“时间驱动的丢包检测”；
• TLP 补齐了边界条件，保护连接不被挂起；
• RACK-TLP 组合，代表了现代 TCP 的最佳丢包恢复路径。