4、ECN基本原理：ECN的IP头标记、CE（Congestion Experienced）标记、ECT与Not-ECT、ECN在TCP/IP中的传统用法
ECN（Explicit Congestion Notification，显式拥塞通知）是TCP/IP协议栈中用于提前感知网络拥塞的关键机制。与传统的丢包反馈不同，ECN允许路由器在队列深度达到阈值但尚未被迫丢包时，直接在IP头中打上拥塞标记，从而将拥塞信息显式地传递给接收端。接收端再通过TCP层的ACK反馈给发送端，触发拥塞窗口缩减。这一机制的核心价值在于：将拥塞检测从“被动丢包”提前到“主动标记”，从而减少因丢包导致的重传时延和吞吐量抖动。在RDMA（Remote Direct Memory Access）网络中，ECN更是无损网络（Lossless Network）和DCQCN（Data Center Quantized Congestion Notification）等拥塞控制算法的基础。本节将深入解析ECN的IP头标记字段、CE标记语义、ECT与Not-ECT的区分，以及ECN在传统TCP/IP中的标准用法。
上图展示了ECN从发送端到接收端的完整反馈链路。发送端在IP头中设置ECT（ECN-Capable Transport）标记，表明自己支持ECN功能；路由器在检测到队列拥塞时，将IP头中的ECN字段改为CE（Congestion Experienced）；接收端收到CE标记后，在TCP ACK中设置ECE（ECN-Echo）标志，发送端据此缩减拥塞窗口。整个过程无需等待丢包，实现了拥塞的早期反馈。
4.1 核心原理：ECN的IP头标记与字段语义
ECN机制定义在IPv4头部的ToS（Type of Service）字节和IPv6头部的Traffic Class字节中，具体占用最低的2个比特位。这2个比特位与前面的6位DSCP（Differentiated Services Code Point）字段共同构成一个完整的字节。ECN字段的四种编码状态具有明确的语义：
| ECN 编码 | 名称 | 含义 | 典型场景 |
|---|---|---|---|
| 00 | Not-ECT | 传输不支持ECN，路由器不得标记 | 传统TCP、UDP无ECN能力 |
| 01 | ECT(1) | 支持ECN，使用ECT(1)编码 | TCP连接启用ECN |
| 10 | ECT(0) | 支持ECN，使用ECT(0)编码 | TCP连接启用ECN（更常见） |
| 11 | CE | 路由器标记拥塞经历 | 队列深度超过阈值时设置 |
值得注意的是，ECT(0)和ECT(1)在语义上是等价的，都表示“该数据包支持ECN”。RFC 3168规定，发送端可以选择其中任意一种编码，但同一传输连接中不应混用。路由器在转发数据包时，如果发现ECN字段为ECT(0)或ECT(1)且队列发生拥塞，则将其改为CE（即11）。如果数据包已经是CE，则保持不变。对于Not-ECT（00）的数据包，路由器不得修改ECN字段，只能通过丢包来反馈拥塞。
4.2 判断方法：如何识别ECT与Not-ECT数据包
在实际网络运维和协议分析中，准确识别数据包的ECN状态是排障的基础。以下是几种常用的判断方法：
- 抓包分析：使用Wireshark或tcpdump抓取数据包，在IPv4头部中查看ToS字段的十六进制值。例如，ToS值为0x02表示ECT(0)，0x01表示ECT(1)，0x03表示CE，0x00表示Not-ECT。
- 系统内核参数：在Linux系统中，可以通过
sysctl net.ipv4.tcp_ecn查看TCP层的ECN支持状态。值为0表示禁用，1表示启用，2表示仅接受但不主动发起。 - 交换机计数器：支持ECN的交换机（如Cisco Nexus、Arista）通常提供ECN标记计数器，可以统计被标记为CE的数据包数量，从而判断拥塞发生的频率。
- RDMA网卡状态：在Mellanox（NVIDIA）网卡中，可以通过
ethtool -S eth0 | grep ecn查看ECN相关的收发计数器。
# Linux下查看TCP ECN支持状态
sysctl net.ipv4.tcp_ecn
# 输出示例: net.ipv4.tcp_ecn = 1
# 使用tcpdump抓取ECN标记的数据包（以CE标记为例）
tcpdump -i eth0 'ip[1] & 0x03 == 0x03' -nn
# 该命令过滤IP头ToS字段最低2位为11（即CE标记）的数据包在抓包分析时，需要特别注意：ECN字段位于IP头部的第二个字节（即ToS字节），而不是TCP头。有些初学者容易混淆TCP头的ECE标志和IP头的CE标记，前者是TCP层的反馈标志，后者是IP层的拥塞标记，两者在协议栈中处于不同层级。
4.3 案例拆解：ECN在TCP/IP中的传统用法与交互流程
为了深入理解ECN的工作机制，我们以一个典型的TCP连接为例，拆解ECN的完整交互流程。假设客户端（10.0.0.1）与服务器（10.0.0.2）之间经过一台支持ECN的路由器，网络带宽为1Gbps，路由器队列深度为100个数据包，ECN标记阈值为80个数据包。
场景背景：客户端向服务器发起一个大型文件传输请求，TCP窗口大小为64KB，RTT为0.5ms。在传输过程中，由于突发流量，路由器队列深度迅速增长。
初始现象：当队列深度达到80个数据包时，路由器开始对后续到达的ECT数据包进行CE标记。此时，TCP连接尚未发生丢包，但拥塞已经出现。
关键参数与日志：
- 路由器队列深度：80/100（达到标记阈值）
- 被标记数据包数量：连续5个数据包被设置为CE
- 接收端TCP ACK中的ECE标志：置1
- 发送端拥塞窗口：从64KB缩减至32KB
分析判断过程：接收端收到CE标记的数据包后，在下一个ACK中设置ECE=1，同时保持ACK序号不变（即重复ACK）。发送端收到ECE=1的ACK后，将拥塞窗口减半，并进入拥塞避免阶段。同时，发送端在后续发送的数据包中设置CWR（Congestion Window Reduced）标志，告知接收端已响应拥塞通知。
实际操作步骤：
- 客户端发送数据包，IP头ECT=1（支持ECN）。
- 路由器检测到队列深度超过阈值，将数据包IP头改为CE=11。
- 服务器收到CE标记的数据包，在TCP ACK中设置ECE=1。
- 客户端收到ECE=1的ACK，将拥塞窗口从64KB减至32KB，并在下一个数据包中设置CWR=1。
- 服务器收到CWR=1的数据包后，停止设置ECE标志，恢复正常ACK。
结果对比：如果未启用ECN，路由器在队列满时只能丢弃数据包，客户端需要等待超时或收到3个重复ACK才能触发快速重传，这会导致吞吐量下降约20%-30%。而启用ECN后，拥塞反馈提前了一个RTT，吞吐量下降控制在10%以内，且没有重传开销。
风险与代价：ECN的代价在于：如果网络中某些老旧设备不支持ECN，可能会错误地修改ECN字段，导致连接性能异常。此外，ECN标记本身需要消耗路由器的CPU资源，在高吞吐场景下可能成为瓶颈。
sysctl net.ipv4.tcp_ecn=1）。对于RoCEv2网络，ECN是DCQCN的基础，必须确保交换机和网卡都正确配置ECN阈值，否则拥塞控制将失效。
4.4 常见误区与总结复盘
在理解和应用ECN时，工程师常犯以下错误：
- 误区一：认为ECN可以完全替代丢包反馈。实际上，ECN只能在路由器队列未满时提供早期预警，如果拥塞持续加剧，仍然会发生丢包。ECN的价值在于减少丢包，而非消除丢包。
- 误区二：混淆IP层的CE标记和TCP层的ECE标志。CE是IP头中的拥塞经历标记，由路由器设置；ECE是TCP头中的标志，由接收端在ACK中设置。两者是ECN机制在不同协议层的体现。
- 误区三：在RDMA网络中直接套用TCP的ECN配置。RoCEv2的ECN行为与TCP不同，它不依赖TCP ACK反馈，而是通过CNP（Congestion Notification Packet）报文通知发送端。DCQCN算法对ECN阈值的敏感度远高于TCP。
- 误区四：忽略Not-ECT数据包的处理。对于不支持ECN的流量（如某些UDP应用），路由器不能进行CE标记，只能丢包。如果网络中大量流量为Not-ECT，ECN机制的效果将大打折扣。