摘要

  • 同一序列范围被发送两次后，一个累计 ACK 可以确认交付，却无法说明是哪个发送实例引发了 ACK；因此它通常不能成为 RTT 样本。
  • RTO 会继续指数退避，直到新发送并得到确认的数据提供干净测量。若 TCP 时间戳能够识别发送实例，则构成例外。

设发送方发出一个 TCP 段并启动重传计时器。计时器到期后，同一序列范围再次发送。随后返回一个累计 ACK。对可靠性而言，结果明确：被确认的字节已经交付。对延迟测量而言，结果并不明确：ACK 可能由第一次发送、第二次发送，或两者共同触发。

RFC 793 描述了早期循环：带序列号的数据进入重传队列，未确认段由计时器管理，计时器到期便重传。其示例性 RTO 过程从发送某个带序列号的字节开始计时，直到收到覆盖它的 ACK，再对 RTT 进行平滑处理。但当同一范围已经发送多次时，它没有说明该 ACK 应归属于哪一次发送。

RFC 1122 要求 TCP 同时实现 Karn 算法和 Jacobson 算法。其 4.2.3.1 节对两种算法明确使用 “MUST implement”，对指数退避明确使用 “MUST include”。Karn 算法决定哪些观测可以进入估计，Jacobson 算法把 RTT 方差纳入计算，而指数退避则在超时后增大 RTO；三者作用不同。更好的计算不能修复因果起点未知的观测。RFC 6298 后来提到把 SHOULD 提升为 MUST，指的是对通用 RTO 算法的支持，并没有把 RFC 1122 这两句明确要求降为建议。

RFC 6298 明确规定，重传段不能提供 RTT 样本，因为 ACK 可能对应第一次或后来的实例。计时器到期时，发送方重传最早的未确认段，将 RTO 加倍（可受 2.5 节允许的可选上限约束），并以退避后的值重启计时器。下一次普通测量必须等待新数据被发送并确认。若 TCP 时间戳消除了实例歧义，重传段才可能安全地产生样本。

Karn 不是丢包检测、快速重传、拥塞控制或 SACK，也不是时间戳规范或延迟 ACK 策略。它只规定测量资格：一个 ACK 可以推进可靠性交付状态，同时仍不适合更新 RTT 估计器。

来源