显式拥塞通知的工作原理

更新时间：2026年03月27日作者：spoto 标签(Tag)：

Explicit Congestion Notification（ECN）是互联网协议和传输控制协议的扩展功能。它定义在RFC 3168中。该功能能够在不丢失数据包的情况下，实现网络拥塞的端到端通知。当底层网络基础设施也支持ECN功能时，可以在两个支持ECN功能的终端之间使用这一功能。

在本文中，我们将了解显式拥塞通知的工作原理。

步骤1：假设ECN的协商是在发送方和接收方之间进行的。在最初的握手过程中，发送方和接收方都已经告知对方，他们支持ECN算法。

现在，发送方正在向对方发送一个数据包。在数据包的IP头部中，会设置ECT字段，以告知路由器：发送方和接收方都支持ECN协议，并且他们已经相互通信过了。相反，如果ECN协商失败的话，那么发送方就会在数据包中设置“Non-ECT”标志。无论发送方设置为ECT还是(1)，其实两者都是一样的。这样做是为了让路由器知道：如果出现拥塞情况，不要丢弃这个数据包，而是应该将其标记为特殊数据包并继续转发。

步骤2：在下面的图片中，路由器正在使用AQM算法。请查看底部的队列情况。当这个数据包到达时，AQM算法会启动，并通知路由器将该数据包丢弃。不过请稍等一下，IP头中包含的是ECT字段，路由器无法丢弃这个数据包。因此，路由器会在IP头部将ECT替换为CE。 CE表示路由器正处于拥塞状态。 CE信息是由路由器发送给接收方的。只有路由器才有权将ECT转换为CE格式，其他人都无法做到这一点。该数据包包含ECT信息，并且其IP头部也被修改了。

[0 1] -> [1 1]

步骤3：当数据包被接收端接收到时，接收端会看到IP头部中的CE标记，从而知道路由器处于拥塞状态。此时，接收端的职责就是向发送端报告这一拥塞情况。因此，接收端会将这一拥塞信息标记在数据包上。TCP头部而且，它不会出现在IP头部中，因为某些中间设备可能会对IP头部进行篡改。

接收器会标记TCP头部中的ECE位。需要注意的是，当进行ECN协商时，才会使用ECE位。接收器利用这个ECE位有两个目的。发送方可以通过检查数据包的上下文来避免这种混淆。因为当SYN/ACK位被设置时，ECE位表示的是ECN协商，而不是拥塞情况。不过，现在在ACK包中，ECE位被设置了，因此发送方可以知道路由器处于拥塞状态。

步骤4：现在，CE标志已经送达了发件人手中。发送方会将其拥塞窗口减少一半。如果发送方使用的是NewReno协议，那么cwnd的值将会减少50%。但是，如果携带CE信息的ACK数据包因为网络拥塞而被丢弃，从而无法到达发送方的话，那该怎么办呢？因此，接收方会继续在后续的数据包中持续发送这个CE标志，直到收到发送方的确认为止。如果有一个或多个ACK信号被丢失了，那么至少还有一个ACK信号能够到达发送方，从而通知发送方链路中存在拥塞情况。接收器的配置方式使得它会在不断发送CE信号，直到与发送方取得联系为止。

步骤5：现在，发送方的拥塞窗口已经减少了一半。此时，发送方需要通知接收方，自己已经减少了拥塞窗口，以避免出现拥塞情况。发送方会在TCP头部设置CWR标志，同时也在IP头部设置ECT标志。当数据包到达路由器时，如果路由器检测到拥塞情况，它可以将ECT标志发送给接收方。当数据包到达接收方时，接收方会收到CWR标志，并在后续的ACK数据包中不再向发送方发送CE标志。

因此，IP头部和TCP头部中的标志是协同工作的。

现在，假设发送方获得了CE标志，同时降低了传输速率，然后向接收方发送了CWR标志。在CWR到达接收方之前，接收方会持续向发送方发送CE标志。根据规则，发送方在每次收到CE信号时，都应该将cwnd值再减少一半。但实际上，这种情况并不会发生。发送方只会将拥塞窗口减半一次。它不会为每一个CE而减少该数值。发送方会检查该CE是否属于当前的拥塞窗口范围内。如果某个CE不属于当前的拥塞窗口范围内，那么这意味着该CE是一个新的CE。因此，它会降低cwnd的值。这个功能与NewReno在快速恢复阶段所使用的cwnd减少功能类似。

步骤6：现在，接收方已经收到了发送方发送的CWR。因此，在后续的ACK数据包中，它将不再发送CE。