摘要

  • RFC 2414 允许、但不要求 TCP 使用更大的初始窗口，上限为 min(4*MSS, max(2*MSS, 4380 bytes))。它修改的是新连接的第一批报文，不是空闲或丢包后的所有重启方式。
  • 两个报文段可能在延迟确认计时器到期前触发确认，从而帮助短传输更早完成。RFC 2415 的 ns-2 仿真在不少模拟场景中观察到网页中位时延下降。
  • 混合流量下的结果没有统一答案：中等负载时，IW=3 没有损害 IW=1 组；在一个 32/32 网页客户端的极端拥塞场景里，大窗口组本身反而表现更差。
  • 这些是仿真，不是互联网部署调查。单条连接的提速，与共享路径上影响如何分摊，是两件不同的事。

最初那次确认才是收益所在

这个想法看似不大：让新 TCP 连接一开始发送不止一个数据报文段。它的好处甚至可能在大型传输开始前就出现。若在途只有一个报文段，采用延迟确认的接收端可能要等计时器到期才回复。至少两个报文段抵达时，第二个就可能促使接收端更早确认。对于短邮件或网页对象，少等这一段时间，可能让传输在一个往返内结束。RFC 2414 还指出，对于能够继续扩大拥塞窗口的连接，较大的起始窗口可能在初始慢启动阶段省下最多三个往返和一次延迟确认等待。

RFC 2414 并没有要求每条连接都从四个报文段开始。它于 1998 年 9 月以 Experimental RFC 发布，将允许上限提高到 min(4*MSS, max(2*MSS, 4380 bytes))，并使用 MAY，不是 SHOULD。最大报文段大小很重要：依其取值，上限可能是两个、三个或四个报文段。规则只针对三次握手后新连接的初始窗口；丢包后的窗口仍保持一个报文段，长时间空闲后的重启则被作为独立的可选规则处理。因此，“初始窗口更大”是一项边界明确的实验，不是每次暂停后都把整个拥塞窗口调大的许可。

端点可以选择第一批发送什么，却不能独占这些报文要经过的队列。RFC 2414 同时写出了收益和代价：突发发送可能让发起连接自身遭遇丢包或超时；共享拥塞链路上的其他流量也可能承担丢包或不公平。作者还提醒，如果浏览器同时打开多条连接，每条都使用大窗口，问题会加重。这不是抽象担忧：单流的改进会改变由多个流共同使用的队列所承受的负载。

仿真同时记录了不止一种结果

作为 Informational 文件而非部署报告，RFC 2415 用 ns-2 模拟了这个争论。模型在更快链路之间设置了一个 1.5 Mbps、50 毫秒的瓶颈；网页客户端取 8、16 或 32 个，另加最多三个持续 FTP 传输，并测试从 1 到 4 个、每个 1460 字节的初始报文段。网页模型使用带三个内嵌 URL 的小页面，并在随机等待后再次请求；FTP 则传输 1 MB 文件。这些选择使比较可控，也限定了结果能够说明什么。

在许多模型场景中，较大初始窗口下的网页中位时延更低，常见幅度约为 30%。作者把从一个报文段提高到两个时的显著改善，部分归因于所选 URL 大小分布：中位数的主 URL 和内嵌 URL 都能装进两个报文。换一种内容分布，曲线也可能改变。这是特定机制在特定模型中的结果，不是适用于所有浏览器或链路的通用百分比。

分组对照让问题更清楚。网页客户端以 8/8、16/16 的规模在 IW=1 与 IW=3 之间各分一半时，作者没有观察到一段窗口组受损，而三段窗口组仍保持优势。规模达到 32/32、进入论文所称的病态拥塞场景后，IW=3 客户端反而受损。作者将其归因于大量连接同时开启并出现多次丢包。实验并未证明每次扩大初始窗口都会伤害邻居；它说明总体中位数不足以代表每个分组在所有模拟负载下的体验。

这与已发布的 RFC 2416 文章不同：后者只研究单条连接和一个三缓冲队列。RFC 2415 的证据针对多个共享瓶颈的模拟流量，并观察结果如何随流量构成改变。两项仿真都没有证明真实设备在整个互联网中的行为，也没有提供普适的公平性指标。后来 RFC 3390 以 Standards Track 的可选上限取代 RFC 2414；RFC 5681 记录了这条规则，RFC 6928 又实验了十报文段的初始窗口。后续出版顺序不能倒过来把 1998 年的模型变成部署普查。

卢衡的《运行代码优先》在这里仅作为证据约束：讨论必须贴着实际测试的机制和系统。《现实层次》提供另一条窄提醒：页面时延、队列丢包和整个网络的结论不能压成同一个观察值。这两篇笔记不是 TCP 的历史证据，RFC 2414 与 RFC 2415 才是。

来源