摘要

  • RFC 793 为 TCP 头部保留了六个比特，并要求发送时将其置零。
  • RFC 3168 将其中两个位置分配给 ECE 和 CWR，用于显式拥塞通知。
  • RFC 9293 保留四个比特，并要求未实现的未来比特在发送时置零、接收时忽略。

受规则约束的空白

1981 年的 RFC 793 在四比特 Data Offset 之后定义了六比特 Reserved 字段。Data Offset 指出载荷从哪里开始；Reserved 字段则留待未来使用，并且必须为零。因此，它不是隐藏的可选功能，也不会改变头部长度或载荷边界。

这一要求维持了 TCP 基本报文格式的稳定性。发送方不能擅自把某个位置变成私有信号，接收方也能继续识别相同的基本布局。这个空间当时没有功能，却以可见、受控的方式留给了后来的标准化工作。

两个位置获得拥塞语义

RFC 3168 于 2001 年把第 9 比特指定为 ECE，把第 8 比特指定为 CWR；第 4 至第 7 比特仍然保留。新功能复用了原有头部，并未移动基本头部的边界。

其信号链条分为几步：发生拥塞的路由器可以把 IP 分组标记为 Congestion Experienced，而不只依靠丢包。接收方在 TCP 确认中置 ECE，向发送方报告这一标记。发送方对拥塞作出反应，缩小拥塞窗口后再置 CWR，告知接收方这一动作已经完成。

RFC 3168 还要求在 TCP 建立阶段协商 ECN 能力。仅仅存在某个比特位置，并不意味着两个端点已经理解或启用它的语义。

当前规则保护两种方向

RFC 9293 将 Reserved 字段描述为四比特。对于实现不支持的未来功能，生成的报文必须把相应比特置零，接收方则必须忽略它。发送时置零可防止意外或私有信号；接收时忽略则避免不支持该功能的主机仅因看到未知比特就拒绝基本报文。

TCP Header Flags 注册表由 IANA 管理。RFC 9293 将 CWR 和 ECE 与六个原有控制标志并列，并把偏移 4 至 7 留作未来使用。保留位置并非任意解释的空白，其含义需要公开规范和受管理的分配。

这段历史不能证明什么

原始保留并不能证明 1981 年的设计者已经预见 ECN。可以确认的说法更有限：他们为未来控制用途保留了线上的位置，后来的标准则把其中两个用于具体的拥塞反馈机制。

保留比特也不保证部署成功。实现可能滞后，中间设备可能采取不同假设，新功能还可能需要协商、状态机变化和运行证据。所引用的 RFC 并未量化这些部署摩擦。

来源