摘要

  • 在经典 RFC 3168 中，接收方看到数据包上的 CE 后，会在后续确认包中持续设置 ECE，直到收到携带 CWR 的新数据包。
  • 因而，一次 CE 观察可以产生一串 ECE；这串标志维持的是抗丢失反馈状态，不等于同样次数的拥塞事件。
  • 建连阶段还用 ECE 与 CWR 协商 ECN 能力；隧道传播、单向观测和后续实验规范都会进一步限制原始计数的解释力。

接收方为什么不只说一次

假设监测器连续看见七个带 ECE 的 ACK。“出现七个 ECE 包”是忠实记录，“发生七次拥塞”却多走了一步。建立连接后的数据阶段里，接收方若在 ECN 可用的数据包上看到 Congestion Experienced 编码，就会在确认包中设置 ECE。若延迟确认一次覆盖若干数据包，只要其中至少一个带 CE，这个 ACK 也会带 ECE。

接下来，即使新到的数据包没有 CE，接收方仍会在后续 ACK 上保持 ECE，直至发送方的 CWR 抵达。这个状态不是重复测得若干次队列事件，而是同一通知仍未完成闭环。一次 CE 可以对应多少个 ECE 包，取决于数据节奏、确认策略、返程丢包和发送方反应时间。

这种重复解决了一个朴素问题：第一枚确认包可能丢失。如果只回显一次，网络恰好丢掉这枚返程包，发送方就听不到拥塞通知。持续设置 ECE，使后续 ACK 仍能传递同一事实。因此更合适的观测单位是 ECE 区间：由 CE 打开，由一串回显维持，再由 CWR 关闭。

CWR 是关闭状态的回执

在经典算法下，发送方把 ECE 当作拥塞信号，按类似丢包的方式收缩拥塞窗口。但它不应对每一个重复 ECE 都再缩一次。在一个数据窗口内、时间大约相当于一次往返的 CE 或丢失序列，应只触发一次窗口缩减。

作出反应后，发送方在随后发出的第一枚新数据包上设置 CWR。RFC 3168 明确建议不要把这个响应放在重传包上。接收方收到该新包后，才会对其后的无 CE 数据停止回显 ECE；之后若又观察到 CE，才开启新的反馈区间。

若携带 CWR 的新数据包本身丢失，接收方的 ECE 状态不会凭空消失。持续回显可以促成后续反应和新的 CWR。这个失败路径恰恰说明，多枚 ECE 是为提高送达概率而保留的状态，不是多枚 CE 的副本。即使观察到 CWR，也只能支持“发送方在相关数据发出后作出了反应”；它不能证明某一枚特定 ECE ACK 已送达，更不能指出是哪台设备实施了标记。

建连时，同一标志讲的是另一件事

在 SYN 阶段，标志组合承担能力协商。发起方把 ECE 和 CWR 同时放在 SYN 上，请求启用 ECN；支持 ECN 的对端以 ECE 为一、CWR 为零的 SYN-ACK 回应。此处的 ECE 表示能力，不是在回显 SYN 遭遇的拥塞。

因此，只抽取“ECE=true”而丢掉 TCP 阶段、方向和其他标志的系统，会在每次成功协商时虚构一次拥塞。协商成功本身也不保证一方日后发出的每个数据包都会采用 ECT 编码。证据模型必须保存语法所处的阶段。

经典 RFC 3168 对纯 ACK 还有另一项边界：它们以 Not-ECT 发送。数据接收方的 ECE 状态反映的是去程数据包上的 CE 观察，并不能以同一机制普查 ACK 返程上的拥塞。

回显无法给队列写出履历

RFC 7567 指出，主动队列管理可以在轻度或中度拥塞时用 ECN 标记代替丢包，也可以在队列填满之前采取行动。因此，CE/ECE 不能单独证明缓存溢出、实际丢包、具体时延或某台设备的阈值。

隧道又拉开了信号与位置的距离。隧道内部转发设备可能只看到外层首部，并只修改外层 ECN 字段。RFC 6040 规定端点如何组合内外层字段，把拥塞信息带回内层。终点看到的 ECE 可以真实，却仍不足以定位原始标记点。

重复 ECE 也不能与 RFC 5681 中的重复 ACK 混为一谈。后者有自己的判定条件，可能来自丢包、乱序或复制。ACK 号、序列空间、重传、ECE、CWR 与时间都应作为独立证据保存。

RFC 8311 允许有文档约束的实验放宽 RFC 3168 的部分限制，尝试不同的标记或发送方响应。本文讨论的是经典 RFC 3168 的 TCP 状态机，而不是所有 ECN 实验与传输协议的通用解释器。

来源