是时候替换数据中心的 TCP 协议了吗？

作为最根深蒂固的标准之一，TCP协议有着悠久而成功的历史。但斯坦福大学教授John Ousterhout表示：“对于现代数据中心来说，TCP是一种糟糕的传输协议。”

2022 年 10 月，Ousterhout发表了一篇名为《It's Time to Replace TCP in the Datacenter》的论文。在论文中，Ousterhout列举了目前传输协议的挑战。他认为关于TCP的一切都是错误的，主张替换 TCP 协议。论文一经发表，便引起了无数的关注与讨论。

该论文认为，对数据中心而言，TCP 中的每个设计决策都可以说是错的，并且无法克服。必须找到一种方法，将一种截然不同的传输协议引入数据中心，Ousterhout给出的答案是 Homa传输协议。搞懂TCP只需要这 28 张图！

传输协议的挑战

在讨论TCP的问题之前，我们先回顾一下数据中心中任何传输协议都必须要解决的挑战：

• 可靠的交付：协议必须可靠地将数据从一个主机传送到另一个主机，尽管网络中存在瞬时故障。
• 低延迟：现代网络硬件使短消息的往返时间 (RTT) 可以达到几微秒，传输协议不得显著增加此延迟。此外，传输协议还必须支持尾部的低延迟，即使在混合流量相对较高的网络负载下也是如此。
• 高吞吐量：传输协议必须以两种不同的方式支持高吞吐量，数据中心应用程序需要高消息吞吐量。

为了满足上述要求，传输协议还必须处理以下问题：

• 拥塞控制：为了提供低延迟，传输协议必须限制网络队列中数据包的堆积。分组排队可能发生在边缘和网络核心，每一种形式的拥塞都会产生不同的问题。
• 跨服务器核心的高效负载平衡：单个核心跟不上单个网络链路，传入和传出负载都必须分布在多个核心上。负载平衡在两个方面影响着传输协议：首先，它可能会引入开销；其次，负载在核心之间分布不均匀。这是软件级别的一种拥塞形式。
• NIC卸载：将来，传输协议需要卸载到专用的 NIC 硬件上。即使是最好的软件协议实现的端到端延迟，也要比应用程序通过内核旁路直接与 NIC 通信实现的延迟高 3 倍以上。

关于TCP的一切都是错误的

本节讨论了TCP的五个关键属性：流向、连接方向、带宽共享（“公平”调度）、发送方驱动的拥塞控制、按顺序发送数据包。对数据中心而言，TCP 中的每个设计决策都可以说是错的，而且没法用任何手段加以根治。唯一的办法就是全面做出修改，包括 API。

流向

当消息在 TCP 流中序列化时，TCP 不知道消息边界。这意味着，当应用程序从流中读取时，无法保证它会收到完整的消息。基于TCP的应用程序都必须在 TCP 之上添加自己的消息格式，并且在收到消息时重新组装消息。这带来了额外的复杂性和开销。

此外，流提供的可靠性保证并不适合应用程序，应用程序需要往返保证。客户端应用程序需要保证其请求将被传递和处理，并且将收到响应；如果其中任何一个失败，客户端将收到错误通知。然而，流只能保证在一个方向上尽最大努力传递数据。如果服务器不发送响应，客户端将不会收到通知。因此即使TCP已经有了自己的定时器，客户端也必须实现自己的端到端超时机制，这些机制会带来额外开销。

连接方向

TCP要求应用程序与之通信的每个对等体都有长期的连接状态。在数据中心环境中，应用程序可能有数百或数千个连接，从而导致空间和/或时间上的高开销。连接的另一个问题是，在传输任何数据之前，它们需要一个设置阶段。在TCP中，设置阶段的成本非常高，因为它需要在主机之间进行额外的往返。

为了减少这些开销，应用程序线程通过一组代理线程进行通信，这些代理线程管理到每个服务器的单个连接，这增加了复杂性和性能方面的开销。

带宽共享

在TCP中，当主机的链路过载（对于传入或传出流量）时，TCP会尝试在活动连接之间平均共享可用带宽。这种方法也被称为“公平调度”。

但像这样的调度规程在负载下表现不佳。当接收到几条大消息时，带宽共享会导致所有消息的处理速度变慢。诸如SRPT（最短剩余处理时间）之类的Run-to-completion方法可提供更好的总体响应时间，因为它们一次将所有可用资源用于单个任务，从而确保任务快速完成。但使用TCP很难Run-to-completion，因为TCP没有关于消息边界的信息。因此，它不知道任务何时“完成”。

发送方驱动的拥塞控制

发送方在检测到拥塞时需要主动降低数据包传输速率，但他们无法直接知道何时需要这样做。TCP中的拥塞控制受到两个限制：首先，只有当存在缓冲区占用时，才能检测到拥塞。当网络加载时，这保证了一些分组排队。其次，TCP没有利用优先级队列。因此，所有数据包都被平等对待，长消息生成的队列（吞吐量比延迟更重要）将导致短消息的延迟。

随着消息越来越短，网络越来越快，越来越多的消息将在不到1个RTT的时间内完成，这使得发送方接收到的信息越来越不可靠。

拥塞控制已经得到了广泛研究，包括TCP和其他流传输方法，如RDMA。这些努力带来了相当大的改进，但在不打破TCP的一些基本假设的情况下，延迟与吞吐量的困境不太可能完全解决。

按顺序发送数据包

TCP假定数据包到达接收者的顺序与发送的顺序相同，并且乱序到达则表示数据包丢失。这严重限制了负载平衡，导致硬件和软件出现hot spots ，从而导致高尾部延迟。

在数据中心网络中，执行负载平衡的最有效方法是执行数据包喷涂（packet spraying），即每个数据包独立路由通过交换结构，以平衡链路上的负载。然而，数据包喷涂不能与TCP一起使用，因为它可能会改变数据包到达目的地的顺序。

TCP无法修复

TCP的问题不仅涉及其实现，还涉及到了其API。为了最大限度地提高数据中心的性能，TCP必须从基于流和连接的模型切换到基于消息的模型，而这是一个将影响应用程序的根本性更改。

我们需要一个在各个重要方面都不同于TCP的替代协议。幸运的是，这样一个协议已经存在——Homa。Homa的存在证明了TCP的所有问题实际上都是可以解决的。QUIC会取代TCP吗？

Homa

Homa基于TCP遇到的问题以及使用Infiniband和RDMA实现大规模数据中心应用程序的经验，对数据中心网络传输进行了全新的设计。

基于消息

Homa 是基于消息的，实现了远程过程调用（RPC），客户端向服务器发送请求消息并最终接收响应消息。消息的主要优点是向传输层公开了可调度单元，这实现了更高效的负载平衡：多个线程可以安全地从单个套接字中读取，并且基于NIC的协议实现可以通过内核旁路将消息直接调度到工作线程池。具有明确的消息边界还可以实现传输中的run-to-completion 调度，例如SRPT，并提供更强大的拥塞信号。

无连接

Homa是无连接的。没有连接设置开销，应用程序可以使用单个套接字来管理任意数量的并发RPC和任意数量的对等体。每个RPC都是独立处理的：并发RPC之间没有排序保证。

尽管缺乏连接，Homa仍能确保RPC的端到端可靠性（或在不可恢复的网络或主机故障后报告错误）。应用程序不需要维护额外的超时。流控制、重试和拥塞控制等机制是使用每个RPC状态实现的。关于Homa的一种思考方式是，它为每个RPC实现了一个短暂的轻量级连接。

SRPT

Homa实现了SRPT调度策略，以支持更短的消息。为此，它使用了几种技术，其中最值得注意的是，它利用了优先级队列。这允许较高优先级（较短）的消息绕过排队等待较低优先级（较长）消息的数据包。所有长度的消息都受益于SRPT：即使是最长的消息在Homa下的延迟也明显低于TCP或DCTCP。

接收方驱动的拥塞控制

Homa通过接收方而不是发送方来管理拥塞，接收方知道其所有传入消息，因此它可以更好地管理这种拥塞。当发送方发送消息时，它可以单方面发送一些未调度的数据包（足以覆盖往返时间），但剩余的调度数据包只能在接收方授予的响应中发送。有了这种机制，接收方可以限制其下行链路的拥塞，并且它还使用授权来对较短的消息进行优先级排序。

无序数据包

Homa的一个关键设计特征是它可以容忍无序的数据包到达，这为负载平衡提供了相当大的灵活性。如果Homa得到广泛部署，假设只要核心没有系统过载，核心拥塞将不再是一个重要的网络问题。Homa对无序到达的容忍度也为软件负载平衡提供了更大的灵活性。

Infiniband呢？

除了Homa之外，还有其他的TCP替代方案，但似乎都不能满足数据中心计算的需求。最有名的替代方案之一是Infiniband，它被广泛应用于高性能计算（HPC）领域，并且最近通过RoCE在数据中心中得到了越来越多的应用。RoCE是RDMA协议在普通以太网卡上的实现。

RDMA通过将传输协议实现卸载到网卡，并允许用户进程绕过内核直接与网卡通信，在无负载的网络上提供了非常低的延迟。Infiniband/RDMA网卡有着极高的性能。

然而，RDMA也与TCP存在着大部分相同的问题。它基于流和连接（RDMA也提供不可靠的数据报，但这些数据报存在与UDP类似的问题）；需要按顺序发送数据包。RDMA的拥塞控制机制基于优先流控制 (PFC)，虽然与 TCP 不同，但也存在问题。而且，它没有实现SRPT优先级机制。

此外，RDMA还有一个缺点。基于NIC的协议实现是专有的，因此很难准确地了解它们的行为并跟踪问题。例如，RAMCloud项目发现，在高负载时Infiniband存在一些性能异常。在大多数情况下，由于协议实现的封闭性，没办法追踪到它们。

未来的传输实现应该采用Infiniband的内核旁路方法，但Infiniband本身似乎不太可能解决TCP的所有问题。

结论

对数据中心而言，TCP设计的每一个方面都是错误的，没有值得保留的部分。如果我们想消除“数据中心税”，就必须找到一种方法，将大多数数据中心流量转移到一个完全不同的协议上。

John Ousterhout这篇论文表达的观点引起了很大的争议。

网络架构师Ivan Pepelnjak认为，论文中对TCP协议为什么很糟糕，以及为什么面向消息的传输协议会好得多进行了长篇大论，但并未详细回答下面这些简单的问题：

• Infiniband 有什么问题？关注低延迟的环境通常使用Infiniband。如果我们有现成的成熟技术，为什么还要使用 Homa ？
• RoCE 有什么问题？如果不喜欢 Infiniband 而更喜欢以太网作为传输架构，可以使用 RoCE作为低延迟高吞吐量机制。
• 现有的替代方案有什么问题？如果也不喜欢 RDMA的话，还可以在多个现有的面向消息的传输协议之间进行选择。比如SCTP和QUIC ，还有AWS 使用的SRD 。
• 为什么大家还在用TCP？每个人都对TCP不满意，那为什么我们还在使用它？为什么没有人使用像 SCTP 这样的替代方案？为什么没有人（除了像谷歌和 AWS 这样的巨头）投入大量资源来开发替代协议？

此外，Ivan Pepelnjak认为论文只关注了应用程序到应用程序的消息传递，完全忽略了代表大多数数据中心大部分流量的长期大容量连接：存储流量。

某位知乎博主表示，TCP 没有被轻易换掉的原因不是因为技术，而是成本。若真是技术原因，TCP 早被替换好几回了，不光在数据中心领域，在 Internet 或许也早就没了影子。问题在于，罗列对错是一回事，撼动合理的当下是另一回事。

*本文系SDNLAB编译自John Ousterhout博士的原论文