ECN 代表显式拥塞通知算法。它不像慢启动重启或 AIMD（加性增/乘性减）那样是一种拥塞控制算法。该算法仅有一个职责，那就是通知发送端关于路由器处正在形成的拥塞。因此，ECN 是一种拥塞通知或拥塞信令算法。它会告知发送端有关拥塞的信息，以便采取相应的措施来避免拥塞。
ECN 是在 RFC 3168 中定义的一种拥塞信令机制。它于 1999 年问世，并在 2001 年左右最终定稿。它使用了 TCP 头部中的 2 个位和 IP 头部中的 2 个位。它会对数据包进行标记，这里的“标记”意味着翻转头部中的比特位。
> => 假设 X 正在寄送一个信封给离他两栋房子远的 Z。
> => X 将信封传递给中间人 Y。
> => Y 会观察自己是否变得拥塞。
> => 如果 Y 变得拥塞，他会在信封的一角用笔画一个十字标记，然后将它传递给下一个人。
> => 当 Z 收到信封时，他会观察到信封角上的十字标记，并意识到其中一位中间人发生了拥塞。
> => Z 会向发送端 X 发送一个 ACK（确认），并在 ACK 信封上带有相同的标记。看到这个标记，X 就会知道发生了拥塞。
ECN 可以与 AQM（主动队列管理）算法一起使用。我们知道，AQM 算法会在链路拥塞时主动丢弃数据包。但是，如果不“丢弃”数据包，而是对它们进行“标记”，那岂不是更好？由于 ECN 不会丢弃数据包，这就避免了重传。这就是为什么 ECN 算法如今非常流行的原因。因为其目的仅仅是告知已知的发送端路由器正在发生拥塞，所以既然我们可以通过 ECN 告知发送端，又何必为了这个而丢弃数据包呢？此外，丢弃数据包也无法立即告知发送端拥塞的情况。这对于时间敏感的数据包尤为重要，因为它们的通信量通常很低。
为了使用 ECN 机制；发送端、接收端和路由器“三者”必须都支持 ECN 功能。目前，所有的操作系统中都已实现了 ECN，例如手机、服务器、笔记本电脑，甚至包括路由器等中间设备。但是，它默认是禁用的。原因并不是 ECN 有什么问题，而是因为 ECN 是与 AQM 算法一起部署的。由于参数配置的原因，AQM 并不是那么受欢迎。
RFC 3168 的建议： 绝不能将 ECN 应用于 TCP 控制包。作者强烈建议不要在控制包上应用 ECN。控制包的例子包括：SYN、SYN/ACK、ACK、FIN、RST、PSH、URG。因此，只有数据包才会被 ECN 标记。
TCP 头部中的 ECN 位：
这 2 个位取自保留区域。现在剩下 4 个保留位，其中 2 个被 ECN 占用。这两个位是 CWR 和 ECE。请注意它们出现的顺序。我们不能更改这两个标志位的顺序。CWR 在左边，ECE 在右边。
- CWR: 拥塞窗口减少标志
- ECE: ECE 回显
由于这是 2 个位，因此有 4 种可能的组合。在这里，这些组合被称为码点。
TCP 头部中的 ECN 码点
CWR
Codepoint
To
—
—
—
0
Non-ECN set up
any
0
ECN Echo
Sender
1
Congestion window reduced
Receiver
1
ECN Setup
Receiver- [0 0] 是非 ECN 设置码点。这可以在任意节点之间发送。当这个码点从 X->Y 共享时，X 就是在告诉 Y 它不支持 ECN。
- [0 1] 是 ECN Echo 码点。这是从接收端发送到发送端的。首先，当发送端告诉接收端它支持 ECN 时，接收端会告诉发送端关于它自己的情况，即它是否支持 ECN。如果接收端支持 ECN，它将回复该码点。当接收端告知发送端有关拥塞的情况时，也会使用该码点。因此，该码点有两个用途。
- [1 0] 是 CWR 码点。这是从发送端发送到接收端的。该码点用作从发送端发送到接收端的确认。发送端告诉接收端，当它得知拥塞发生时，已经减少了其拥塞窗口大小。
- [1 1] 是 ECN 设置码点。这是从发送端发送到接收端的。发送端向接收端发送此码点，告知发送端支持 ECN。
ECN 协商：
- Step 1: 发送端向接收端发送带有 ECN 设置码点（CWR=1 和 ECE=1）的 SYN 包。ECN 设置意味着 CWR=1 和 ECE=1。发送端正在告诉接收端它支持 ECN。此信息始终在通过三次握手建立 TCP 连接时的 SYN 包中传递。