摘要

  • RFC 6928 把 TCP 初始窗口的可选上限提高到十个报文段；精确上限取决于 MSS，发送方仍可选择更小的起点。
  • IW10 能让短传输少等几轮，却也会在尚无路径反馈时占用更多队列；因此首轮遥测与退回 RFC 3390 行为是机制本身的一部分。

TCP 三次握手能确认两端愿意通信，却不会告诉发送方中间链路有多慢、队列还剩多少空间、同一时刻有多少流量正在竞争。初始拥塞窗口处理的正是这段信息空白：在确认信号开始描绘路径之前，发送方可以押上多少数据。

RFC 6928 给出的上限公式是 min(10*MSS, max(2*MSS, 14600))。十段是允许的天花板，不是每条连接必须完成的配额。它作用于三次握手期间或之后第一个数据 RTT；SYN/ACK 以及完成握手的 ACK 都不会凭空增加窗口。

这与 TCP Fast Open 的控制面不同。Fast Open 讨论应用数据能否随 SYN 提前到达；IW10 仍让握手按通常顺序结束，只扩大普通数据的第一轮发送量。前者改变请求出现的时点，后者改变反馈到达前暴露给路径的负荷。

节省的是往返，不是未知性

在 RFC 采用的简化假设下——带宽无限、没有丢包、使用标准延迟 ACK——初始窗口从三段增至十段，可让大于 4 KB 的传输最多减少四个 RTT。文中的 32 段示例从五轮降至两轮。较大的首轮窗口还可能产生足够的重复 ACK，使 Fast Retransmit 在不等待初始重传超时的情况下处理部分丢包。

这些数字说明机制，不是对今天任何网络的性能承诺。接收端公布的窗口若小于十段，收益会被流量控制封顶；文中测试主要基于 1,500 字节以太网 MTU。应用如果同时打开多条连接，每条连接的十段还会叠加成远大于十段的整体突发。

路径先承受突发，发送方后获得证据

慢速接入、浅缓冲或已经繁忙的队列可能在首轮突发中提前丢包，引发重传超时，或让连接过早离开慢启动。部署尚不一致时，IW10 流也可能比遵循 RFC 3390 的流先占用更多容量。深队列会把代价转化为延迟，影响 DNS、语音、游戏等对时延敏感的交叉流量。

RFC 6928 并不认为一次性扩大首轮窗口会单独造成持续拥塞或拥塞崩溃，之后的 TCP 退让仍然有效。但“一次性”只针对单条连接。页面或服务同时建立许多连接时，应用层会不断复制这次行为。

初始、重启与丢失窗口不可混为一谈

RFC 将新连接的初始窗口、空闲后恢复发送的重启窗口、重传超时后的丢失窗口分开。重启窗口至多取初始窗口值与当前 cwnd 的较小者。严重拥塞后的丢失窗口仍保持一个 MSS。若在初始或重启窗口中发送超过 4 KB 后检测到丢包，实现应把重启窗口退回 RFC 3390 的行为。

计时器同样是安全边界。低带宽路径上的串行发送时间可能主导 RTT，使大突发看起来像超时。RFC 6928 因此要求遵循 RFC 6298：每个确认新数据的 ACK 都用当前 RTO 重新启动重传计时器。

证据边界

本文只依据 2013 年 4 月以 Experimental 身份发布的 RFC 6928。它支持公式、实验摘要与有条件部署要求；它不证明某个当代系统已启用 IW10，不证明某条具名网络的效果，也没有为十段以上的窗口提供安全证据。