LWN: TCP 更加精确的拥塞通知

关注了就能看到更多这么棒的文章哦～

Jonathan Corbet
Gemini translation
原文链接：https://lwn.net/Articles/1058666/ 

“更加精确的显式拥塞通知”（More Accurate Explicit Congestion Notification，简称 AccECN）机制由 这份 RFC 草案（RFC draft） 定义。在过去的几个版本中，Linux 内核（Linux kernel）一直在增加对 TCP AccECN 的支持；7.0 版本将默认在通用场景下启用它。AccECN 是对 TCP 工作方式的一次微妙改动，但它有潜力改善公共网络和私有网络上的流量传输。 

TCP 从一开始就包含了几个窗口计数器（window counter），连接双方利用这些计数器来指定在任何给定时间内愿意从对方接收多少数据。这些窗口在防止端点被数据包淹没方面效果显著，但早期的 TCP 并没有考虑到端点之间路由器中的拥塞问题。这种缺陷在 20 世纪 80 年代中后期以严重的拥塞问题形式显现出来。 

大约在那时，Van Jacobson 和 Mike Karels 开始着手解决防止拥塞崩溃（congestion collapse）的问题。他们的核心洞察力在于，丢包几乎从来不是数据包本身损坏的结果。相反，丢包是一个信号，表明端点之间的某个系统正在经历拥塞；事实上，丢包曾是路由器发出拥塞信号的 唯一 方式。Jacobson 实现了第一套拥塞控制算法（congestion-control algorithm），该算法会缓慢提高传输速率，直到发生丢包，这标志着通道容量已达到极限。Jacobson 的 经典论文 详细描述了这项工作。 

以这种方式利用丢包事件使网络重新恢复工作，但这绝非调节传输速度的最有效方式。意识到一个数据包被丢弃需要时间，而且每个丢弃的数据包都代表着资源的浪费。如果 TCP 端点能在拥塞达到丢包程度之前获得通知并调节其传输速度，那将好得多。 

显式拥塞通知

大约在 20 世纪 90 年代末，相关工作开始启动，并最终形成了 RFC 3168，该协议描述了显式拥塞通知（Explicit Congestion Notification，简称 ECN），这是一种路由器告知连接端点其正在经历拥塞的手段。它需要对协议栈的 IP 层（IP layer）和 TCP 层（TCP layer）都进行修改。 

在 IP 层级，从 IPv4 和 IPv6 报头中分配了两个位（bit）；它们被命名为 ECT 和 CE。在 IP 数据包中设置这两个位中的任意一个（但不能同时设置）即表示端点理解 ECN 协议并愿意实施它。当一个正在经历拥塞的路由器收到一个仅设置了其中一个位的包时，它可以选择设置另一个位来表示“经历拥塞”（congestion experienced），希望端点能通过降低传输速率来做出响应。 

在一个典型的 TCP 连接中，一方的传输速率通常比另一方高得多。如果重度传输者导致了拥塞，ECN 信号将到达接收端，而该信号在接收端并非完全有用。因此，TCP 必须进行增强，将该信号转发回传输端。TCP 报头中也分配了两个位，分别命名为 ECE（ECN 回显，ECN echo）和 CWR（拥塞窗口减小，congestion window reduced）。如果在启动连接的初始 SYN 数据包中设置了这两个位，它们将被解释为一个信号，表明发起方实现了 ECN。如果对等端也支持 ECN，它将在发送 SYN-ACK 响应时仅设置 ECE 位。当这两个条件都满足时，连接将使用 ECN。 

当连接的一方收到一个设置了两个 IP 级拥塞标记位的数据包（表明路径中存在拥塞）时，它将开始在发送回另一方的每个 ACK 数据包中设置 TCP ECE 位。端点在收到设置了 ECE 的数据包后，理应像发生丢包时那样做出响应；它将减小其拥塞窗口（并因此降低传输速度）。它还将在发送的下一个数据包的 TCP 报头中设置 CWR 位，以表明已收到 ECE 信号。一旦在另一端观察到 CWR 位，接收者将停止设置 ECE。 

Linux 内核在 2000 年 9 月的 2.4.0-test7 版本中获得了对 ECN 的支持。最直接的结果是给人们上了关于协议僵化（protocol ossification）问题的一课。正如当时 LWN 所指出的 以及 LWN 的报道，互联网上的许多路由器不仅不支持 ECN，而且还会主动丢弃设置了 TCP ECN 位的 SYN 数据包，导致通信无法进行。因此，尽管 Linux 很早就支持了 ECN，但过了很多年它才在大多数系统上被安全地启用，即便在当前的内核中，它也尚未完全启用。 

更加精确的 ECN

ECN 相比之前的方案有所改进，但仍有优化的空间。ECN 协议的设计意味着在连接的每个往返时间（round-trip time，简称 RTT）内只能传达一次“经历拥塞”事件；这就是从传输第一个设置了 ECE 的 ACK 到接收到设置了 CWR 的数据包之间所需的时间。这将减缓对严重拥塞的响应，可能导致数据包仍然被丢弃。AccECN 旨在为 TCP 端点提供更快、更详细的拥塞反馈。 

AccECN 对 IP 层级的 ECN 改动极小；两个位的使用方式与以前相同。在 TCP 层级，它占用了另一个报头位。这个位曾在 2003 年由 RFC 3540 分配给一个从未部署过的“稳健 ECN”（robust ECN）机制。该位现被重命名为 AE，并在新协议中以几种方式使用。在连接建立时，支持 AccECN 的站点应同时设置 AE 位以及 ECE 和 CWR；如果另一方也支持 AccECN，它将返回设置了 ECE 和 AE 的响应。如果接收方不理解 AccECN 并忽略了 AE 位，它将看到类似于“经典 ECN”的配置并做出相应反应。（请注意，连接协议与其它部分一样，比这里描述的要复杂一些；详情请参见 RFC 草案）。 

在使用 AccECN 时，每一方都维护一组计数器，其中一个是接收到的带有“经历拥塞”标记的数据包数量。连接建立后，AE、CWR 和 ECE 位被组合成一个单一的 3 位字段，不可避免地被称为 ACE。该字段的内容将是数据包计数器的最低三个有效位，为另一方提供一个持续更新的视图，显示已看到多少个带有拥塞标记的数据包。当 ACE 计数值改变时，传输方可以感知到在传输过程中有多少个数据包被盖上了拥塞标记，并据此做出响应。 

不用说，三个位无法提供很大的计数范围。RFC 草案提供了一套复杂的规则，用于确定计数是否可能发生了翻转，并猜测翻转了多少次。ACK 的发送频率相对较高——在持续的数据流中大约每两个数据包发送一个 ACK——这使得大多数情况下 ACE 计数器发生多次翻转的机会很小。无论如何，随着每个 ACK 变化的八个计数器值（而不是每个往返时间只能变化一次的一个位）能提供关于两个端点之间路径拥塞情况的更高分辨率信息。 

到目前为止所描述的 AccECN 显然旨在尽可能避免协议僵化问题。即便如此，它也包含了多项规定，用于检测中间设备（middlebox）对 ACE 位及整个计数的干扰。现代互联网的本质决定了协议更改必须非常谨慎，即使这些更改符合协议本身的规范。 

不过，如果连接支持，AccECN 还有更多功能。连接的每一方都被要求为传入数据维护另外三个计数器。有两个计数器用于追踪在设置了其中一个（但不是同时设置）IP 级 ECN 位的情况下接收到的 字节 （byte）数，还有一个计数器用于追踪在两个位都设置的情况下（表示拥塞）接收到的字节数。有一对 TCP 选项（TCP option）可用于将这些计数器（更准确地说是每个计数器的低 24 位）传达给另一方。这些计数器能更准确地指示实际发生了多少拥塞，并且可以被一些高级拥塞控制算法有效利用。 

当然，TCP 选项的问题再次指向了中间设备，它们通常不会放行包含无法识别选项的数据包。因此，连接建立的过程包含了数次尝试发送带有 AccECN 选项的数据包，以查看它们是否能毫发无损地到达另一端；除非这些测试通过，否则不会使用这些选项。在互联网上成功使用这些新选项的机会可能相对较小，但 AccECN 也旨在用于数据中心内部，那里的任何中间设备都在所有者的控制之下，可以强制其允许这些选项通过。 

Linux 中的 AccECN

Linux 内核对 AccECN 的支持最早出现在 6.15 开发周期中，随后的版本又补充了更多部分。在 7.0 版本中，许多最后的问题已得到修复，并且在某些连接中默认启用了 AccECN。具体来说，如 Documentation/networking/ip-sysctl.rst 中所述，AccECN（以及一般的 ECN）的使用受 net/ipv4/tcp_ecn sysctl 开关控制。在之前的内核中， tcp_ecn 的值默认是 2，这意味着在传入连接请求时使用经典 ECN，但不尝试在传出连接中使用它。在这种配置下，AccECN 被完全禁用。新的默认值是 5，这为传入连接启用了 AccECN，但仍然禁用了所有形式的传出连接 ECN。换句话说，对协议僵化的担忧依然存在，因此 Linux 系统默认不会对它们发起的连接尝试使用任何类型的 ECN。 

这里进行的一些高度科学的“在网上随便试一试”的测试表明，在诞生大约 25 年后，经典 ECN 对传出连接启用是安全的。要确定 AccECN 是否同样如此，可能还需要一些时间。虽然在数据中心内的部署可能会快得多，但启用 AccECN 的服务器要在互联网上普及也需要一段时间。尽管可能需要几十年，但最终应该会达到一个点，即更精确的显式拥塞通知能在更大范围内让网络运行得更加顺畅。 

LWN 评论概述：

评论者们探讨了路由器和交换机厂商对新协议的潜在反应，以及对“僵化”（ossification）这一术语在网络协议演进中深刻含义的趣闻。 

欢迎分享、转载及基于现有协议再创作～