摘要

  • ECN 并不取消丢包。它允许主动队列在既定条件下，对已经声明具备响应能力的传输流量进行标记，以替代原本用于通报拥塞的一次丢弃。
  • ECN 是一条闭合控制回路：发送端声明能力，路由器标记，接收端回送证据，发送端降低负载。任何一环断开，标记都只剩装饰作用。
  • 从 RFC 2481、RFC 3168 到隧道规则、实验限制的放宽与 L4S，真正困难的从来不是找出两个空闲比特，而是让相互独立的系统长期维护同一种语义。

在标记出现以前，队列必须先造成损失

拥塞控制最初依靠“没有到达”的报文说话。队列溢出，报文被丢弃，发送端由此推断路径有压力并收缩发送窗口。这套反馈帮助互联网避免拥塞崩溃，却让丢包同时承担两项职责：既破坏传输，又报告导致破坏的状态。

1998 年 4 月发布的 RFC 2309 说明了尾丢弃为什么是一名迟到的证人。只有缓冲区塞满后，路由器才开始丢弃新报文；队列可能长期保持高位，排队时延上升，一次突发还可能造成连续丢包。多个流会同时后退，又在稍后同时增长。文档因此建议部署主动队列管理，在溢出之前行动，并保持较小的平均队列。

可是提前丢弃依然是丢弃。ECN 提供了另一种语言：如果传输层已经声明能够理解显式通知，主动队列可以改写报文上的拥塞码点，而不必把报文销毁。报文抵达终点时，仍携带它经过瓶颈队列的痕迹。

这就是机制史上的转折：网络不必总是先毁掉证据，才能证明压力存在。

两个比特背后是多方权责

2001 年 9 月进入标准轨道的 RFC 3168 在两比特 ECN 字段中定义了四个码点：Not-ECT、ECT(0)、ECT(1) 与 CE。ECT 表示传输具备 ECN 能力，CE 表示已经经历拥塞。

可见的改写发生在路由器里，但 ECN 并不是一个孤立的路由器功能。发送端首先协商或建立传输能力，并给报文设置可接受 ECN 的码点。主动队列到达其拥塞判定条件时，可以对合格报文设置 CE，而不是用丢弃来发送同一类警告。接收端再把标记回送给发送端；发送端收缩拥塞窗口，并表明自己已经处理这次反馈。

每个角色都只掌握局部事实。路由器知道自己的队列，却不知道应用的完整控制状态；接收端看到 CE，却不能直接决定发送速率；发送端控制负载，却没有亲眼看到瓶颈。ECN 的价值正在于把一条短小、可观察的事实跨越这些边界送达。

丢包仍然保留。Not-ECT 报文没有承诺会对标记作出反应；严重拥塞仍可能要求路由器丢弃；路由故障、数据损坏和流量管制也不会因 ECN 消失。准确的事实只是：对符合条件的流量，在规范指定的情形下，标记可以替代一次“用于表达拥塞”的丢弃。

从实验提案到可渐进部署的契约

1999 年 1 月，RFC 2481 以实验性文件提出在 IP 中加入 ECN。两年后，RFC 3168 取代它，并规定 IP 与 TCP 的具体行为。改变不仅是分配字段，还包括能力协商、接收端回显、发送端响应，以及与不使用 ECN 的流量共存。

渐进部署塑造了整个机制。发送端不能假设每个对端和每条路径都会保留信号；路由器不能假设每个报文都可被安全标记；网络也必须保留基于丢包的保护手段。向后兼容不是对旧设备的礼让，而是避免先行部署者把新风险转嫁给其他参与者。

由此可以得到一项运营推论：单层的“已启用”数量没有闭环意义。操作系统可以协商 ECN，而瓶颈队列从不标记；路由器可以标记，而隧道在出口抹掉 CE；路径可以保留 CE，而发送端没有按相应拥塞控制作出反应。产品功能清单统计组件，端到端测量才能统计结果。

Nonce：反馈是否诚实

显式通知带来一个新的激励问题：接收端会不会隐瞒标记，从而避免让己方发送端减速？2003 年 6 月发布的实验性 RFC 3540 提出 ECN nonce。发送端在 ECT 码点中制造可校验的变化，再利用返回信息检查拥塞反馈是否被隐瞒。

该实验没有成为 ECT(1) 的长期用途，却把一项核心冲突说清楚了。拥塞标记要求某个参与者主动牺牲自身速率，以保护共享资源。网络可以给出证据，但无法仅凭善意保证证据会转化为行动。

2018 年 1 月的 RFC 8311 将 RFC 3540 调整为历史状态，并放宽若干 ECN 实验限制，ECT(1) 因而可以承载其他实验语义。这个比特并非天然空白；IETF 必须先结束旧实验对它的占用，才能为新实验建立边界。

隧道承担证据保管责任

报文进入隧道后，内层头部被外层头部包裹。若外层路径发生拥塞，隧道出口必须协调内外两份 ECN 状态。直接抛弃外层标记，会让内层报文以“路径一直干净”的假象出现；错误合并又可能制造本不存在的拥塞证据。

2010 年 11 月进入标准轨道的 RFC 6040 规定了 ECN 隧道处理。具体表格十分技术化，目标却很明确：在封装与解封装时保留拥塞含义，同时安全处理旧模式。

这是报文处理事实。进一步的推论是：隧道规则也是一套证据保管规则。入口决定外层怎样表达能力，隧道路径可能设置 CE，出口决定内层继承什么。VPN、移动核心网和数据中心覆盖网络都因此成为测量边界。两个端点都支持 ECN，不能证明中间某条隧道没有“漂白”标记。

允许实验，不等于允许假装确定

2006 年的最佳当前实践 RFC 4774 讨论 ECN 字段的替代语义。它没有把两个比特当作任意扩展空间；新的解释必须能够被识别，能够与既有 ECN 共存，并对部分部署风险作出限制。RFC 8311 后来放宽 RFC 3168 的特定约束，使实验可以不再把每次标记都等同于一次经典丢包。放宽是实验许可，不是普遍安全证明。

这一点在 2023 年发布的低时延、低损耗和可扩展吞吐量（L4S）架构中尤其关键。RFC 9330 描述整体架构；实验性 RFC 9331 以 ECT(1) 识别 L4S 流量，并以 CE 提供更频繁的反馈；实验性 RFC 9332 规定双队列耦合主动队列管理框架。

L4S 不是把经典 ECN 的阈值调低那么简单。可扩展拥塞控制需要对频繁标记作出响应，而不把每次标记都当作一次经典损失事件。网络将低时延处理与经典流量的较长排队隔离，再通过耦合拥塞信号共享容量。RFC 9330 强调，这是分离时延，并非无条件的带宽优先级。

架构至少需要三部分：兼容的发送端响应、瓶颈处的队列处理，以及识别协议。单独设置 ECT(1) 不会自动带来低时延。只复制标识、不复制响应行为，会破坏共存所依赖的承诺。

RFC 能证明什么，不能证明什么

这组 RFC 证明了一条明确的制度与技术演进路径：主动队列需要更早的信号；实验提案成为标准机制；反馈诚信接受过检验；隧道与替代语义获得规则；旧约束为受控实验放宽；L4S 在更大架构中重新使用该字段。

它们不能证明 2026 年大多数公网路径都保留 ECN，也不能指出哪台中间设备会抹去码点。它们不能证明每个瓶颈都运行有效的主动队列，更不能证明 L4S 必然成为通用低时延服务。这些是部署与测量问题，不能从 RFC 的类别名称中推导出来。

更持久的成果其实更克制：网络可以在报文损失之前留下拥塞证据。代价是每一层都必须明确——谁有权制造证据，谁负责转交，谁必须采取行动。

报文活着抵达，责任并没有因此变轻。

来源