摘要

  • RFC 2416 模拟了一台接在 9600 bps 调制解调器后的接收端，以及一个只能容纳三个包的队列；在这个模型中，四包启动的第四个包必然被丢弃。
  • 这次局部丢包并不是实验对连接的最终判决。常规慢启动后来也形成了相近的突发，两条仿真轨迹在时间和包编号错开后进入几乎相同的恢复状态。
  • 扣除调制解调器的发送时间后，四包启动在多数模拟情形中领先约 0.229 秒。备忘录只说“在这个特定情形”无害，并把真实设备表现和网络整体安全留作未解问题。
  • 历史启示在证据边界：既要计入基线后续的丢包和完整结果，也不能把一次仿真扩大成普遍安全结论。

0.229 秒从哪里来

RFC 2416 最醒目的数字不是队列长度，而是约 0.229 秒。两条轨迹进入近似相同恢复状态时，四包启动那一条在时间上早了 2.889 秒、包号上早了三个。研究者又估算，三个 1024 字节 TCP 段通过 9600 bps 调制解调器需要 2.66 秒。两者相减，才得到多数情况下约 0.229 秒的领先。

这个小差距不是四包启动的固定承诺。备忘录说明，由于两条轨迹里实际丢失的包不完全相同，个别情况会更早，也会更晚。作者把主要差异归因于另一条轨迹中的调制解调器在等待接收端延迟确认计时器时空转。因而这项测量描述的是特定连接、特定时序下的传输结果，不是普遍吞吐率基准。

基线并没有避开同样的队列边界

故事要从常规一包启动说起。发送端在零秒发出第一个包；约 1.222 秒后收到确认，继续发出第二、第三包；约 2.444 秒后，第四和第五包随之发出。到 3.278 秒，确认第三个包后，第六、七包也进入网络。第七包后来丢失，第三个重复确认在 8.278 秒触发重传。

四包启动则在零秒一次送出第一至第四包。第四包在三包队列处丢失，5.389 秒时第三个重复确认触发它的重传。两个版本并非一边丢包、一边平稳通过；差别在于突发和损失发生的时点不同。把四包启动第一刻的丢包拿来与基线的整段传输相比，会把不同阶段混为一谈。

实验的拓扑把这个比较做得很具体：发送端先经过一段无延迟的 100 Mbps 链路，再经过单向延迟 25 毫秒的 1.5 Mbps 链路，最后由 9600 bps、单向延迟 150 毫秒的调制解调器链路接收。最后一跳前的路由器有三个包缓冲位：一个可以正在发送，两个等待。队列容量因此不是作者推测出来的风险，而是模型设定中的确定条件。

模拟使用 LBL 的 NS 1.2a2，比较 Tahoe、Reno、SACK 与 FACK 模块；备忘录用 Tahoe 轨迹说明过程，并称在这一设置中结论看起来不随模块而变。包按 1024 字节计算链路发送时间，模块使用包编号而非完整 TCP 序号机制，观察点位于发送端附近的高速链路。这些选择让实验可读，也划定了它能够回答的问题。

局部事件不能替代系统判断

RFC 2416 是 1998 年的 Informational 备忘录，不是标准。它的结论刻意限于“这个特定情形”：四包启动没有造成显著性能退化。但作者同时指出，四包启动对整个网络是否安全仍是开放问题，并希望用真实 TCP、真实调制解调器和真实三缓冲限制重复实验。单条连接的完成时间没有回答共享队列里其他流量承担了什么代价。

《Heng Lu 笔记》中的 Running-Code Primacy 和 Reality Layers 可作为分析视角，而不是历史署名。前者要求以实际运行的代码和轨迹压过直觉，同时不把证据外推到未测试的系统；后者提醒我们，队列丢包、单连接完成时间和网络整体稳定性是不同层次的事实。RFC 2416 对前两者提供了有限证据，并明确没有替第三者下结论。

来源