ECN 的 Not-ECT、ECT(0)、ECT(1)、CE、ECE、CWR、AQM 和 L4S 有什么区别？
网络拥塞不一定要等到丢包才被端系统发现。Explicit Congestion Notification（ECN）允许支持的发送端把 IP 包标记为可接受拥塞通知，拥塞节点再把包标为 CE，而不是必须丢弃；接收端把信号反馈给发送端，发送端相应降低发送速率。
本文目录（18 节）
快速对照
| 名称 | 所在位置 | 谁设置 | 含义 | 不代表什么 |
|---|---|---|---|---|
| Not-ECT | IP ECN 字段 00 | 发送端 | 该包未声明 ECN 能力 | 一定没有拥塞 |
| ECT(0) | IP ECN 字段 10 | 发送端 | 经典 ECN-capable transport 常用标记 | 已经发生拥塞 |
| ECT(1) | IP ECN 字段 01 | 发送端 | ECN 能力；在 L4S 中作为 L4S 标识 | 所有网络都会给低时延服务 |
| CE | IP ECN 字段 11 | 拥塞节点 | Congestion Experienced | 包必须被丢弃 |
| ECE | TCP flags | TCP 接收端/握手双方 | 协商 ECN 或回显拥塞 | 路由器直接改了 TCP 头 |
| CWR | TCP flags | TCP 发送端 | 已对拥塞反馈作出反应 | 拥塞已经彻底消失 |
| AQM | 队列算法 | 路由器/主机 qdisc | 在队列溢出前标记或丢弃 | 等同某一种固定算法 |
| L4S | 端到端架构 | 端系统与网络共同参与 | 低时延、低丢包、可扩展吞吐 | 单独打开 ECT(1) 即可获得 |
ECN 复用 IP 头的两个比特
IPv4 的原 Type of Service/DS 字段、IPv6 的 Traffic Class 中，最低两个比特用于 ECN。四种 codepoint 是 Not-ECT、ECT(0)、ECT(1) 和 CE。DSCP 与 ECN 位于同一字节但用途不同：DSCP 表达差分服务分类，ECN 表达传输是否支持通知及是否经历拥塞。
修改 DSCP 的设备不应把 ECN 两位一起清零；复制整个字节的错误策略会破坏 ECN。抓包显示 tos 0x.. 或 IPv6 traffic class 时，应分别解码高六位 DSCP 和低两位 ECN，不能把十六进制值整体当作 DSCP。
ECN 是逐包信号。同一连接的不同包可能是 ECT、CE 或因控制语义为 Not-ECT。只抓一个包不能证明整个连接的协商与反馈流程。
Not-ECT：该包不接受用 CE 替代丢包
Not-ECT 的二进制值为 00。它表示发送方没有把该包声明为 ECN-capable。拥塞节点不能把 Not-ECT 简单改成 CE，因为这样会把 00 变为 11，接收方可能误以为传输协议能正确响应；对于需要发出拥塞信号的 Not-ECT 流量，节点通常只能丢包。
Not-ECT 不等于路径无 ECN，也不等于发送端系统完全不支持 ECN。TCP 可能未协商成功、该类控制包按规则未标 ECT、应用使用的传输没有启用，或中间设备清除了字段。
看到大量 Not-ECT 时应先检查端系统协商和系统策略，再比较线上入口与出口抓包。不能只在接收端看到 00 就断言发送端从未设置 ECT。
ECT(0)：经典 ECN 的常见可通知标记
ECT 表示 ECN-Capable Transport。经典 RFC 3168 TCP 在协商成功后，数据包通常使用 ECT(0)，即二进制 10。队列没有决定发出拥塞信号时，包保持 ECT(0) 抵达接收端；拥塞时 AQM 可把它改成 CE。
ECT(0) 本身不是“轻微拥塞”或“尚未拥塞”的测量值，只表示这个包支持通过 CE 接收通知。ECN 字段不是计数器，无法从单包判断队列长度或拥塞程度。
发送端也不能因为标记 ECT(0) 就忽略丢包。链路错误、Not-ECT 节点、队列溢出、非 ECN AQM 和策略丢弃仍会产生丢包，传输协议必须保留丢包检测与恢复机制。
ECT(1)：历史上也是能力标志，L4S 中有特定用途
RFC 3168 允许 ECT(0) 与 ECT(1) 表示 ECN-capable，曾设想利用两个值帮助检测 ECN nonce，但该实验后来停止。RFC 8311 放宽了部分早期限制，为后续 ECN 实验和机制留出空间。
L4S 架构使用 ECT(1) 标识希望获得 L4S 处理的包。支持 L4S 的 DualQ Coupled AQM 可把 ECT(1) 流量送入低时延队列，并以更频繁、细粒度的 CE 标记配合可扩展拥塞控制。
因此不能再把 ECT(0) 和 ECT(1) 永远解释为完全可互换。也不能让普通经典拥塞控制仅通过强制改成 ECT(1) 冒充 L4S 流量；如果发送端不按可扩展规则快速响应高频 CE，会损害公平性和队列稳定。
CE：包被保留，但携带拥塞信号
CE（Congestion Experienced）为 11。一个原本标为 ECT 的包经过支持 ECN 的拥塞节点时，可以被改成 CE 并继续转发。这样接收端仍得到数据，传输层同时获得拥塞信号。
CE 不是错误码，也不会携带是哪台路由器、哪条队列或拥塞持续时间。路径上多个节点都可能标记，后续节点看到已经为 CE 的包也无法累加次数。定位拥塞点仍需队列遥测、逐跳指标、主动测量和路径信息。
ECN 不承诺零丢包。当队列已满、AQM 策略选择丢弃、包为 Not-ECT 或设备资源异常时，包仍可能被丢弃。正确目标是更早、更低代价地通知，而不是取消队列容量约束。
TCP 如何协商 ECN
经典 TCP 在三次握手中利用 ECE 与 CWR 的特定组合表示 ECN 能力。发起方在 SYN 中设置 ECE 和 CWR，支持的响应方在 SYN-ACK 中设置 ECE。只有协商成功，后续 TCP 数据包才按经典 ECN 规则使用 ECT 标记并解释反馈。
握手中的 ECE/CWR 含义与已建立连接的数据阶段不同，不能看到 SYN 的 CWR 就说“发送端已经降低窗口”。它是能力协商的一部分。抓包分析必须先区分报文阶段。
若中间防火墙丢弃带这些标志的 SYN，连接可能回退或失败，取决于操作系统策略。现代路径通常更兼容，但诊断应比较启用与禁用 ECN的握手，并检查重传，而不是永久关闭后就结束调查。
ECE：接收端回显拥塞经历
建立连接后，TCP 接收端看到 CE 标记的数据包，会在 ACK 中设置 ECE，通知发送端路径出现拥塞。经典 RFC 3168 的反馈是状态式回显：接收端持续设置 ECE，直到看见发送端的 CWR。
ECE 位于 TCP 头，而 CE 位于触发它的数据包 IP 头。路由器通常只标 CE，不直接给反向 ACK 设置 ECE。接收端 TCP 根据收到的 IP ECN 信息生成反馈。
反向路径丢 ACK、ACK 合并和卸载功能会让抓包中的 ECE 数量与 CE 包数量不是简单一一对应。网卡 GRO/LRO/TSO 还可能改变主机抓包所见的分段形态，应在不同位置核对。
CWR：发送端确认已响应拥塞
CWR 是 Congestion Window Reduced。经典 TCP 发送端收到 ECE 后，应像响应丢包拥塞信号一样调整拥塞控制状态，并发送带 CWR 的包，告知接收端已处理该次反馈。接收端看到 CWR 后停止持续回显对应 ECE，直到新的 CE 事件。
CWR 不表示拥塞窗口具体降到多少，也不保证队列立刻清空。实际反应由拥塞控制算法、当前窗口、往返时延和实现决定。分析性能需结合 cwnd、发送速率、RTT、重传与队列数据。
仅统计 TCP flags 也可能漏掉使用不同反馈机制的传输，例如 QUIC 在其 ACK 帧中携带 ECN 计数，而不是使用 TCP ECE/CWR。
AQM：在队列溢出前做决定
Active Queue Management（AQM）在队列完全填满之前，根据队列延迟、长度或算法状态选择标记 ECN-capable 包或丢弃包。它区别于简单 tail drop：后者通常等到队列满才丢包，容易造成长队列、同步丢包和延迟膨胀。
AQM 是机制类别，不是单个参数。RED、CoDel、PIE、FQ-CoDel 和 DualPI2 等算法的控制目标、流隔离和 ECN 行为不同。开启“ecn”选项还需确认具体 qdisc 是否标记 ECT 包、对 Not-ECT 如何处理，以及硬件队列是否绕过软件 qdisc。
端系统开启 ECN 但瓶颈队列只做 tail drop，仍可能几乎看不到 CE。反过来，网络会标 CE 而发送端不正确降速，也不能获得稳定收益。ECN 是端到端反馈闭环。
L4S：低时延队列加可扩展拥塞控制
Low Latency, Low Loss, and Scalable Throughput（L4S）不是把一个 sysctl 打开就完成。RFC 9330 定义整体架构：发送端使用可扩展拥塞控制与 ECT(1)，网络使用能区分 L4S 与经典流量的 AQM，接收端提供足够精确的拥塞反馈。
RFC 9331 给出 Prague 类可扩展拥塞控制的要求；RFC 9332 定义 DualQ Coupled AQM，使 L4S 低时延队列与经典队列共存并耦合拥塞控制。L4S 可以比经典 ECN 更频繁标 CE，因为可扩展发送端对标记比例作细粒度响应，而非把每次 CE 都当成经典的大幅减窗事件。
若路径没有 L4S AQM，ECT(1) 不会凭空获得低时延；若错误分类不响应的流量进入低时延队列，可能造成不公平。部署必须同时验证端系统算法、反馈、队列和回退行为。
隧道为何会丢失或放大 ECN 语义
IP-in-IP、GRE、VXLAN 和其他隧道有内层与外层 IP 头。入口需要按规则把内层 ECN 语义映射到外层，出口再把外层 CE 正确传播回内层。RFC 6040 定义通用隧道 ECN 封装与解封装行为。
简单把外层 ECN 清零会让隧道内部发送端看不到瓶颈标记；无条件复制错误组合又可能把非 ECN 流量伪装成可通知。排障要在隧道入口前、外层路径和出口后分别抓包，比较内外头。
加密隧道仍可让外层头携带 ECN，但设备需要正确实现传播规则。不能因为内层 payload 加密就假设 ECN 必然不可用。
Linux tcp_ecn 的含义
Linux net.ipv4.tcp_ecn 控制 TCP ECN 行为，具体数值语义应以运行内核的 ip-sysctl 文档为准。当前文档区分主动发起连接时请求 ECN、只接受对端请求和禁用等模式；发行版默认值可能不同。
sysctl net.ipv4.tcp_ecn
sysctl net.ipv4.tcp_ecn_fallbacktcp_ 涉及握手中检测 ECN 兼容性问题后的回退。更改全局值会影响所有命名空间或相应范围的连接，不应只为一个失败目标永久关闭。应先用 per-route、实验主机或受控流量验证，并记录内核版本。
主机 TCP 开启不代表 UDP/QUIC 自动采用相同策略；各传输协议和应用栈需要独立支持。
抓包如何逐层判断
- 抓 SYN 与 SYN-ACK，确认 TCP ECN 协商标志；
- 查看已建立连接数据包的 IP ECN 是否为 ECT；
- 查找路径后段出现的 CE，确认不是发送端原始产生；
- 查看反向 ACK 的 ECE 和发送端后续 CWR；
- 同时记录重传、RTT、吞吐与 cwnd，不只统计 flags；
- 在瓶颈队列读取 AQM mark/drop 计数；
- 有隧道时分别解码内外层 ECN；
- 考虑 TSO/GRO/硬件卸载对主机抓包的影响；
- 比较 ECT(0) 经典流与 ECT(1) L4S 流，避免混合解释；
- 用受控负载制造队列，再验证反馈闭环是否完整。
ECN 与丢包、RTT、吞吐的关系
CE 增加通常意味着某个支持 ECN 的队列发出了拥塞信号，但它不是丢包率。一个流可以 CE 较多而重传很少，也可以完全无 CE 却因不支持 ECN 而大量丢包。
低 RTT 也不证明无拥塞，短路径或小缓冲仍可能拥塞；高 RTT 可能来自传播距离而非排队。应将基础 RTT 与负载下 RTT 比较，结合 AQM mark/drop、传输重传和发送速率。
吞吐下降可能是发送端正确响应 CE，也可能是应用、接收窗口、CPU、整形或路径切换。ECN 指标只能解释拥塞控制的一部分。
常见误区
CE 表示包已经被丢弃
错误。CE 的价值正是让支持 ECN 的拥塞节点可以保留包并标记；队列仍可在其他条件下丢包。
ECE 是路由器写入 TCP 头
错误。路由器在 IP 头标 CE，TCP 接收端在 ACK 中用 ECE 回显。
CWR 表示网络已不拥塞
错误。它表示发送端已响应反馈，不是路径状态证明。
开启 ECT(1) 就是开启 L4S
错误。L4S 还需要可扩展拥塞控制、精确反馈和兼容的低时延 AQM。
ECN 开启后不再需要重传
错误。网络仍会丢包，传输层必须继续检测和恢复丢失数据。
FAQ
1. ECT(0) 与 CE 的区别是什么？
ECT(0) 表示包可以接受 ECN 通知；CE 表示支持 ECN 的拥塞节点已经对该包发出拥塞信号。
2. ECT(1) 一定比 ECT(0) 延迟低吗？
不一定。只有路径部署了 L4S 兼容分类与 AQM，且端系统使用合规可扩展拥塞控制时，才可能获得对应服务。
3. 为什么握手看到 ECE，数据包仍是 Not-ECT？
可能协商未真正完成、中间设备改写、系统策略或抓包点不同，也可能所看的是不应标 ECT 的控制包。需跟踪完整流。
4. 为什么有 CE 却没有一一对应的 ECE？
经典 TCP 反馈是状态式的，ACK 合并、丢失、卸载与抓包位置都会改变可见数量，并非单包一一映射。
5. AQM 会标记所有 ECT 包吗？
不会。它只在算法判断需要发出拥塞信号时标记或丢弃，具体概率和阈值取决于算法状态。
6. ECN 能穿过 VPN 吗？
可以，但隧道入口和出口必须正确传播内外层 ECN。错误清零或映射会丢失信号，应按 RFC 6040 验证。
7. Linux 打开 tcp_ecn 后 QUIC 也会开启吗？
不一定。该 sysctl 针对 TCP；QUIC/UDP 的 ECN 支持由应用和传输实现独立决定。
8. 怎样证明 ECN 真正生效？
要同时证明协商、ECT 数据包、瓶颈 CE、接收端反馈、发送端响应和队列计数，而不是只看到某一个标志。