摘要

  • RFC 3742 在 cwnd 超过 max_ssthresh 后减缓 TCP 窗口增长，以避免指数式慢启动在一个 RTT 内增加数千个报文段。
  • 已验证的 Erratum 236 修正了每 RTT 的增长区间；示例中增长到 83,000 个报文段至少需要 836 个 RTT，而非恰好 836 个。

“受限”不等于“固定速率”。RFC 3742 是一份 2004 年的实验性、可选提案，针对拥塞窗口可达数千个最大报文段大小的 TCP 连接。cwnd 不超过 max_ssthresh 时，它保留常规慢启动的做法：每收到一个 ACK，增加一个 MSS。越过该阈值后，算法计算 K = int(cwnd / (0.5 * max_ssthresh))，每个 ACK 增加约 1/K 个 MSS。max_ssthresh 并不取代 ssthresh；超过 ssthresh 仍会结束慢启动。

RFC 原文第 2 节对数字的描述比算法本身更肯定：它称超过 max_ssthresh 后，每 RTT 的增量至多为该阈值的一半。但按 ACK 执行的规则中，K 会随窗口分段变化，指向的是一个范围。RFC Editor 核实的 Erratum 236 更正了不变量：增量不超过 max_ssthresh 个 MSS/RTT，且至少为其一半。勘误还把原先单一的到达时间公式改成上下界。因此，阈值设为 100 MSS、目标窗口为 83,000 个报文段时，经常被引用的 836 个 RTT 是“至少”需要的时间。

这是对机制说明的更正，不是新的拥塞控制算法。2004 年发布的 RFC 正文并未被改写；勘误是需要与原文并读的独立记录。它扩大了读者对可能增长幅度和所需时间的理解，却没有把区间端点变成普遍测得的结果。

设置增长限制，既是为发送端，也是为了控制外部性。慢启动中一次大幅增长可能造成成批丢包、重传超时，并使连接退回很小的拥塞窗口。共用瓶颈的其他流量也要承受队列和丢包冲击。RFC 3742 举了 100 MSS 阈值的例子，并提到 Linux 2.4.16 Web100 内核上的早期实验。这些是范围有限的历史证据，不能证明当下普遍部署、全网收益，也不能保证队列永远低于某个数值。

后来的 TCP 文档采用了不同的控制信号。RFC 9438 通常建议 CUBIC 慢启动使用 HyStart++，同时把 Limited Slow-Start 列为实验性选项。RFC 9406 则以 RTT 上升作为可能退出慢启动的线索，再进入保守阶段判断是否退得过早。这与 RFC 3742 按当前窗口调整每 ACK 增量的方式不同，不能混为一谈。

对运营者而言，这项勘误提醒我们：算法的醒目数字未必限定了读者以为它限定的东西。按 RTT 计算的窗口增量不是直接的字节速率上限、队列测量，也不是共享路径上的公平性证明。阈值、ACK 模式、pacing、缓冲区、RTT 和并发流量都会影响实际结果。勘误让 RFC 自身的不确定性更清楚，却没有消除它。

来源