LWN：在数据中心里抛弃TCP - part 1！

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

Moving past TCP in the data center, part 1

By Jake Edge
November 1, 2022
Netdev
DeepL assisted translation
https://lwn.net/Articles/913260/

在最近结束的 Netdev 0x16 会议上，斯坦福大学教授 John Ousterhout 对于数据中心网络（networking in data centers）的发展方向发表了他的个人看法。为了解决他看到的这些问题，建议对这些环境进行一些 "相当重大的改变"，包括抛弃古老的、无处不在的 TCP 传输协议。虽然 LWN 由于日程安排和时区冲突未能参加此会议，但我们观看了 Ousterhout 的主题演讲视频，为您带来这份报告。

The problems

他一开始就介绍说，现在的硬件已经有了惊人的进展。链路速度（link speed）现在已经超过 100Gbps，而且还在上升，硬件往返时间（RTT，round-trip time）现在达到了 5 或 10 微秒，未来几年可能会更低。但应用程序这边并不能得到这种水平的网络速度，具体来说，短小的 message 的延迟（latency）和吞吐量（throughput）距离上面这些硬件数据差得还很远。"我们有一到两个数量级的差距，甚至更多。" 问题就在于软件网络协议栈（software network stack）的开销。

他说，如果我们要让应用程序也能真正达到这种速度，就需要进行一些 "彻底的改变"。有三件事需要做，但其中最大的一件就是替代掉 TCP 协议；他 "也不认为这是一件很容易的事情，但如果你想让硬件潜力得到发挥，确实没有其他办法[…]"。他会用讨论中的大部分时间来介绍如何摆脱 TCP，但还是需要一个更轻量级的远程程序调用（RPC，remote-procedure-call）框架。除此之外，他认为在软件中实现传输层协议（transport protocol）不再有意义了，这些协议最终都需要转移到网络接口卡（NIC，network interface cards）中，这同样需要对 NIC 架构进行重大改变。

人们对数据中心的网络可能会有各自不同的关注点，但他打算把重点放在更高性能这一点上。当发送大尺寸的 object 时，人们希望达到链路的全速，这就是他所说的 "data throughput"。这 "一直是 TCP 的优势"，如今的数据中心网络在这个指标上做得很好。然而，在另外两项衡量标准中，TCP 的表现并不尽如人意。

对于短小的数据包（short message）来说最需要低延迟；油漆是 "低尾部延迟，low tail latency"，希望能有 99%或 99.9%的消息都可以得到非常低的往返延迟（round-trip latency）。他说，原则上，我们应该能够让这个数字低于 10µs，但我们离这个数字还差两个数量级；TCP 的短信息延迟目前在毫秒量级。

另一个衡量标准是短小信息的吞吐量（message throughput for short messages），他之前没有听到别人谈过这个问题。硬件应该能够每秒发送 1000 万至 1 亿条短小消息，这 "对那些紧密配合来完成各种 group-communication 操作的大规模数据中心应用来说非常重要"。今天，用软件方案勉强可以达到每秒处理一百万条信息。"我们确实差得太远了"。他重申，目标是把这种程度的高性能可以完全提供给应用程序。

Ousterhout 说，这种性能要求，就意味着需要满足其他一些要求。首先，需要在多个 CPU core 之间进行负载平衡，因为单个 core 是无法跟上超过 10Gbps 的速度的。但负载平衡很难做好，所以某个 core 负担过重之后就会成为性能瓶颈，从而损害 throughput 和 tail latency。这个问题非常严重，这也是他认为传输协议需要改到网卡里面实现的原因之一。

还有另一个隐含的要求，就是在网络中实现拥堵控制；网络设备中的 buffer 和 queue 需要得到正确管的理。他认为如果能正确地进行负载平衡，就可以避免 core fabric 里的拥堵，但是如今无法做到这一点；"TCP 不能正确地进行负载平衡"。edge 侧（即到最终 host 的下行链路）的拥堵是不可避免的，因为下行链路的容量总是会被多个发送者完全占用光；如果管理不善，那么由于 buffer 不断积累，latency 就会增加。

TCP shortcomings

TCP 是一个了不起的协议，它是在 40 年前设计的，当时互联网的样子跟今天非常不一样；令人惊讶的是，虽然网络在这一时期发生了这么多的变化，TCP 仍然能持续存在这么长时间。即使在今天，它在广域网络（wide-area networks）也很有效，但在设计 TCP 的时候还没有数据中心，"所以毫不奇怪，它并不是针对数据中心而设计的"。Ousterhout 说，他认为 TCP 设计中的每个主要关注点，在数据中心场景来说都是不适用的。"我无法确定 TCP 的设计里面有什么是适合数据中心的"。

他列举了 TCP 设计的五个主要方面（stream-oriented、connection-oriented、fair scheduling、sender-driven congestion 和 in-order packet delivery），这些方面对于数据中心的应用来说都是错误的，他说他将在演讲中逐一讨论这些部分；"我们必须改变所有这五个方面。要做到这一点，就必须把 TCP 从数据中心里移除，至少要大部分移除掉；它需要被一些其他方案所取代，尽管不是完全被取代。其中一个候选方案就是他和其他人一直在研究的 Homa 传输协议。由于非常难以摆脱 TCP，那么在 RPC 框架下来添加对 Homa 或其他一些面向数据中心的传输层的支持，就可以减少应用程序这边需要进行的改动，从而让过渡更加容易一些。

[Netdev 虚拟平台]

TCP 是 byte-stream-oriented，每个连接都是由一个没有不带有消息边界（message boundary）的字节流所组成的，但应用程序实际上关心的是 message （消息）。接收 TCP 数据通常是在固定大小的 block 来完成的，这些 block 可能包含多个 message、单个 message 的一部分甚至是某种混杂形式。因此，每个应用程序都必须要基于 TCP 之上来添加自己的 message 格式，并且花时间而且耗费额外的复杂度来从收到的 block 中重新组装出 message。

他说这很烦人，但算不上是障碍；真正的障碍是无法使用 TCP 做负载平衡。你不能把接收到的字节流的数据处理分给多个线程，因为线程可能无法拿到一个完整的 message 从而进一步 dispatch 出去，可能某个 message 的各个部分分布在好几个线程里。试图实现某种方式从而让各个线程合作来重新组合出 message 也会是很麻烦的。他说，如果有一天，网卡开始直接将网络数据 dispatch 到用户空间，那么也会有同样的负载平衡问题。

目前有两种主流方法来弥补这个 TCP 的限制：先用一个 dispatcher 线程来收集完整的消息，然后发送给 worker 线程，或者通过静态分配某些网络连接上的所有数据给指定的 worker 线程。他说，dispatcher 实际上是一个瓶颈，它增加了延迟；这会把性能限制在大约每秒 100 万条 short message。而后一种静态负载平衡方式很容易出现性能问题，因为会有一些 worker 负担过重的同时有一些其他 worker 很空闲。

除此之外，由于 head-of-line blocking 机制，可能会有一些 small message 会卡在在 large message 的后面，这就需要等待前面的 message 先被传送完毕才能处理。TCP stream 也没有给应用程序提供它非常需要的可靠性承诺。应用程序总是希望他们的消息能被送达，服务器处理完，之后会返回一个响应；如果其中任何一步失败，他们希望能得到某种错误提示。stream 部分地提供了提示，而在这些 round-trip 往返过程可能发生的许多故障都不会让应用程序知道。这意味着应用程序需要自己添加一些超时机制，尽管 TCP 已经拥有了好几种 timeout 超时。

第二个问题点，就是 TCP 是面向连接的。这就像是 "网络世界的一个信仰"，你需要有 connection 来实现一些 "有价值的属性，如流量控制和拥堵控制，以及恢复丢失的数据包等等"。但连接都是需要存储一些状态的，这个开销可能相当昂贵；在 Linux 上每个 connection 需要大约 2000 字节，还不包括数据包 buffer。然而，数据中心应用程序可能同时有数千个保持开放的连接，而服务器应用程序则可能有数万个，因此，对于各种状态信息的存储会导致大量的内存开销。如果使用 pool 来管理 connection 从而减少内存占用，最终肯定会导致复杂性和延迟的增加，就像对于 TCP 负载平衡使用 dispatcher/worker 解决方案的缺点一样。

此外，在可以发送任何数据之前，都受限需要完成一次 round-trip 往返。在过去这不是一个大问题，因为 connection 是长期存在的，这个配置成本可以被摊薄，但在今天的微服务（microservice）和无服务（serverless）世界中，应用程序可能只需要运行不到一秒钟，甚至只有几十毫秒。Ousterhout 说，事实证明，那些被认为需要 connection、拥堵控制等等特性的功能，实际上完全可以不需要用到这些特性。

在出现竞争时，TCP 使用 fair scheduling （公平调度）从而在所有活动连接中共享带宽。但这意味着所有的连接都会很慢完成；"众所周知，公平调度在对于希望达到响应时间最小化方面，是一种糟糕的算法"。由于处理 flow 中大部分（但不是全部）其实是没有什么好处的，所以有必要采取 run-to-completion 方式；挑选一些 flow，处理其中所有的数据。但这需要知道 message 的 size，从而让系统知道要发送或接收多少 message，而 TCP 并不具备这种能力；因此，公平调度是 TCP 可能采取的最好方案了。他介绍了他所做的一些基准测试，表明 TCP 实际上并不真正公平；当 short message 跟 long message 在一个负载很重的网络上竞争带宽时，short message 会看到速度下降更多（"短信息真的要急眼了"）。

他想强调的 TCP 的第四个方面，就是这个 sender-driven congestion control。sender （发送方）负责在出现拥塞时降低他们的传输速率，但他们没有什么直接方法来知道他们什么时候需要这样做。sender 试图避免把中间 buffer 都用光，所以拥塞程度的信号都是基于 TCP 中 buffer 区域有多满的。

在极端情况下，队列溢出导致数据包被丢弃，进而导致数据包超时；这是 "灾难性的"结果，所以要尽可能地避免。也就使用各种队列的长度来指示是否产生了拥塞，让 sender 根据这些指示来减少其传输的数据。但这意味着，如果没有很多 buffer 积聚起来，就没有办法知道已经发生了拥塞，这就导致了延迟的出现。由于所有的 TCP message 都使用相同的 class of service，因此各种 size 的 message 都在相同队列中排队；short-message 又收到了延迟歧视。

他说，TCP 设计中第五个对数据中心不利的方面是，它希望数据包按照发送时的顺序来被送达；如果数据包不按顺序到达，就会被判定为 dropped packet。这使得硬件和软件都难以实现负载平衡。硬件上来说，stream 中的每个 packet 都必定使用了相同 path 来通过 routing fabric，这样就不应该会导致数据包乱序，但由于 path 是由各个 flow 来独立选择的，如果两个 flow 最终使用同一链路，那么它们都无法使用到全速的网络带宽。哪怕网络 fabric 上的整体的负载很低，这种情况也会发生；如果用于选择 path 的 hash 函数恰好又有碰撞的话，就会发生拥塞。

他假设，在如今的数据中心网络里，造成拥堵的主要原因是 TCP 所要求的这种 flow-consistent routing。他没有看到任何关于这个方面的测量结果，但他很希望能有这样的数据；他邀请有机会进入数据中心网络的与会者可以一起进行调查。

使用软件来处理数据包同样也会存在负载平衡问题。在 Linux 中，通常一个 packet 会经历三个 CPU core，其中一个是运行驱动代码的 CPU core，另一个是运行网络协议栈处理（在一个软件中断里）的 core，还有一个是应用程序所运行的 CPU core。为了防止数据包乱序，一个 flow 中的所有数据包都需要使用相同的一批 CPU core 来处理。但是这里有跟硬件上面类似的问题，如果两个 flow 最终共享一个 CPU core，该 core 就会成为瓶颈。这导致了系统中的负载不够均衡；他通过测量已经看出这是软件导致的 TCP tail latency 的主要原因。他说，对于 Linux 上的 Homa 也有同样的问题。

人们想知道 TCP 是否可以被 fix，但 Ousterhout 认为这是不可能的。需要解决太多的互相搅在一起的基本问题，才能让这个方案变得可行。事实上，他找不到 TCP 中哪个部分值得保留在数据中心里；如果大家认为哪一部分有用，可以告诉他。因此，为了绕过这个 "software tax"，从而让应用程序可以充分利用现有的网络硬件的潜力，就需要一个在各个方面都跟 TCP 不同的新协议。

Ousterhout 的主题演讲的前半部分结束了；接下来就是对斯坦福大学开发的 Homa 传输协议的更多介绍。它的协议设计非常干净，是专门针对数据中心的需求的。我们将在后续会发表的文章中总结这部分内容，敬请关注。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

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

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～