摘要

  • RACK 只有在“更晚发送的数据已经被确认送达”和“较早数据在估算 RTT 加一个有上限的乱序窗口之后仍未确认”同时成立时，才把较早传输判为丢失。
  • TLP 在 RTO 到来前最多发出一个受控探针，目的是换回新的 ACK，而不是证明原报文已经丢失。探测、判定与恢复发送分属三种权限，不能合并成一次无条件重传。

三个重复 ACK 的盲区在尾部

经典快速重传把三个重复 ACK 当作丢包线索。这个经验法有一个隐含前提：缺口之后还要有足够多的数据抵达接收端，才能连续产生反馈。短网页响应、受应用限制的流，或者刚好发生在发送窗口末尾的丢失，都可能没有这三个“证人”。发送端只好等重传超时；而 RTO 为了在证据不足时仍能安全前进，本来就设置得审慎。

选择确认让反馈更丰富。RFC 2018 允许接收端在累计确认边界之外报告已收到的字节块，RFC 6675 又把这张 SACK 记分板用于恢复。但其主要丢失门槛仍然在序列空间里计数：洞口上方有多少不连续的 SACK 序列或字节。乱序、重复报文和合并 ACK 都会改变这个数。它记录“后面来了多少”，却不回答“较早那次发送已经在路径上暴露了多久”。

Recent ACKnowledgment 因此把坐标轴转向发送时间。RFC 8985 由 Yuchung Cheng、Neal Cardwell、Nandita Dukkipati 和 Priyaranjan Jha 共同撰写，2021 年 2 月作为 IETF 标准轨文档发布。Cardwell 在 IETF 和 Google Research 的官方资料能够确认其身份、网络研究经历及与该 RFC 的联系；它们不能把集体标准写成个人发明，也不能证明他今天控制所有实现。

后发先到，只是立案条件

RACK 为每个尚未确认的段保存最近一次发送时间，重传后的时间也要覆盖进去。当一个 ACK 或 SACK 证明某段数据已经到达，而它的发送时间晚于仍在等待的段 S，发送端才得到第一项关键事实：路径确实交付了一个后发者。

但后发先到并不立刻等于先发丢失。S 还必须继续未获确认，直到其等待时间超过估算 RTT 与乱序窗口之和。RFC 用“每段一个虚拟计时器”描述逻辑，并不要求实现真的分配成千上万个物理定时器；系统可以只维护全部未决数据中最早到期的一项。

时间精度是正确性的一部分。RFC 8985 要求每个未决段的最近发送时间粒度细于最小 RTT 的四分之一。文档估算这种状态通常每段需要四或八个字节，取决于时间戳表示方式；这是该规范语境下的实现估值，不是所有系统必然相同的内存成本。

ACK 所证明的内容仍很窄：某个 TCP 字节范围到达了接收端。它不证明路径健康，不识别拥塞发生在哪里，不说明中间盒是否介入，也不保证应用已经消费数据。无线丢失、合法乱序、路由切换或拥塞，在发送端可能留下近似现象。RACK 不是因果鉴定器，它只是判断现有次序与时间证据是否足以让传输层按“丢失”处理 S。

乱序得到一笔有上限的时间预算

网络完全可能不丢包，只是改变到达顺序。因此 RACK 在 RTT 之外再留出乱序窗口。按照 RFC 所列条件，它可以从零或最小 RTT 的一个小比例开始。如果 Duplicate SACK 证明某次重传其实多余，发送端就获得了更深乱序的证据，可以扩大窗口。文档建议用 DSACK 自适应，并把窗口上限控制在平滑 RTT。

这里没有免费选择。窗口窄，真实丢失能更快修复，但迟到的原报文容易被误判并重复发送；窗口宽，可以容忍更乱的路径，却让真正的缺口等得更久。“基于时间”不等于“确定无疑”，而是把不确定性变成明确、有界、可观测的等待额度。

因此，一条可审计的 RACK 判定记录不该只有结果。它至少要留下可疑段的最近发送时间、后来被交付段的发送时间、提供证明的 ACK 或 SACK、当时的 RTT 估计、乱序窗口，以及曾调整窗口的 DSACK。只报一个 RACK loss 计数，是保留结论、丢掉前提。

TLP 向沉默的尾部只问一次

Tail Loss Probe 处理的正是反馈最稀薄的流尾。探针超时通常围绕两倍平滑 RTT 计算，同时受延迟 ACK 和 RTO 关系的约束。启用 TLP 需要一个新的 RTT 测量，而且任何时刻最多只能有一个探针在途。

计时到点时，如果有新数据并且拥塞窗口允许，发送端优先发新数据；否则重传最高序列号的未确认段。这样选择，是希望制造一个会引出 ACK 的后续事件，让较早数据的状态变得可判断。规范允许这个单独探针暂时超过已经占满的拥塞窗口，但它仍计入在途数据，下一次 ACK 必须消化这笔账。

探针发出本身并不证明原尾段丢了。它是一个带仪器的问题：返回的 ACK 可能给 RACK 带来“更晚发送者已到”的证据，也可能说明原数据早已到达，只是 ACK 时钟停了。如果探针同样丢失，RTO 仍是最后保险。TLP 制造观察机会，RACK 才解释观察。

判丢不等于获准重传

RACK 把一个段标记为丢失以后，仍不能随意发包。RFC 8985 明确要求等待拥塞控制算法允许重传。RFC 5681 规定经典 TCP 拥塞控制义务，RFC 6937 的 Proportional Rate Reduction 则被推荐用于恢复阶段的发送节奏。

这条边界防止更快的传感器变成更激进的执行器。判定模块只说“证据足够按丢失处理”；控制模块决定网络此刻能承受多少修复流量。即便 TLP 可以在满窗口外多发一个探针，这也是范围极小、明文规定且必须记账的例外。

RFC 6298 定义的 RTO 也没有被废除。它在细粒度反馈无法形成结论时确保连接继续前进，并保留谨慎的退避。整个结构是分工叠加：SACK 描述收到哪些范围，RACK 根据时间判丢，TLP 在尾部索取反馈，拥塞控制约束恢复，RTO 接住其余沉默。

精确时钟也不是网络公证人

后发数据到达，不代表整条路径健康，更不能认证端点、定位拥塞或说明应用已经成功。RACK 输出的是发送端可见信号下的传输结论，不是网络取证报告。把时间精度扩大解释为因果精度，是常见却危险的跃迁。

RFC 8985 的安全讨论继承 SACK 的已知问题，同时指出一项较窄优势：ACK splitting 即便每次只多确认一个字节，也不会推进 RACK 所用的“最近交付传输时间”，因此较难借此放大效果。这是对一种策略的抵抗，不是 ACK 的普遍真实性保证。

RFC 9002 在 QUIC 丢包探测中采用时间门槛，并把 RACK-TLP 列入思想来源。但 QUIC 有自己的包号空间、确认规则和拥塞接口。血缘能够帮助比较，不能证明状态、阈值和权限完全相同。

历史数字只能回答历史问题

Cardwell 参与的 2013 年论文《Reducing Web Latency: the Virtue of Gentle Aggression》分析了一份 Google 前端流量样本。在那个明确限定的环境中，观察到的丢失有 77% 最终依靠 RTO 而不是快速恢复修复；论文测试的机制组合使平均延迟下降 23%，第 99 百分位延迟下降 47%。

这些数字说明设计者为何重视短事务的安静尾部。它们不是当前部署普查，不代表今天的 Google 生产行为，也不是 RFC 8985 的效果保证。能够保留的结论更朴素：短流往往先用完能够提供证据的后续报文，才用完等待时间。

来源