LWN：数据中心中替代TCP，第二部分！

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

Moving past TCP in the data center, part 2

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

在 LWN 上一篇之前关于 John Ousterhout 在 Netdev 0x16 的演讲的文章末尾，他得出结论，由于所说的各种原因，TCP 不适合用在数据中心（data-center）环境。他还认为，没有办法改造 TCP 来使其能够满足数据中心的网络的需求。他说，为了使软件能够充分使用如今的网络硬件的潜力，需要用一个几乎在所有方面都跟 TCP 不同的协议来取代它。讲座的后半部分介绍了他和斯坦福大学的其他人一直在研究的 Homa 传输协议（transport protocol），作为数据中心中 TCP 的一个可能替代方案。

Homa 项目的设立就是希望从头开始设计一个协议以满足现代的数据中心网络的需求。事实证明，按照他的演讲前半部分中所涉及的五个方面来说，Homa 都与 TCP 不同；Homa 对这些方面的选择很好地结合在一起，从而 "产生了一个真正的高性能数据中心协议"。但是，他强调，Homa 不适合广域网（WANs）；它只适合数据中心。

Homa overview

首先，Homa 是基于消息的（message-based），而不是基于字节流的（byte-stream-based），这意味着 "可调度单位（dispatchable units）" 直接被记录在协议里了。每个消息都是由线路上的多个数据包所组成的，这些数据包被组装成一个完整的消息，供应用程序来处理。这解决了 TCP 的线程负载平衡问题，因为多个线程可以安全可靠地通过同一个 socket 中读取信息；如果未来网络接口卡（NIC，network interface cards）获得支持，它也可以允许 NIC 直接向线程来分发消息。

Homa 是无连接的（connectionless）；它的基本单元是一个远程过程调用（RPC），由两个消息组成：一个请求（request）和一个响应（response）。"Homa 协议中明确了'往返（round trip）'的概念"。RPC 之间互相独立，不保证顺序；可以发起多个 RPC，并以任意的顺序来完成。Homa 不会没有保存记录长连接状态（long-lived connection state）；一旦某个 RPC 完成了，那么相关的所有的状态都会被删除。然而，每个对等主机（peer host）都会存储少量（大约 200 字节）的状态，用于 IP 路由信息之类的内容。也不需要额外开销进行连接设置（connection setup），一个 socket 可以用来发送任何数量的 RPC 到任意数量的对端。Homa 会确保 RPC 要么完成、要么返回错误，因此不需要应用程序层面设置 timer。

Homa 的拥塞控制是由接收者驱动的（receiver-driven），这比 TCP 所使用的发送方驱动（sender-driven）的拥塞控制有着很大优势。Ousterhout 描述了 Homa 中流控的工作方式。当某个信息需要被发送到一个接收方时，发送方可以立即发送一些 "不被调度的数据包（unsheduled packets）"，但要发送更多的 "scheduled packets" 则必须等待接收方的明确 "同意（grant）"。这个做法的目的是希望有足够的 unscheduled packets 来隐藏掉 host 之间的往返时间（round-trip time）；如果没有拥塞的话，在发送方发送完所有 unscheduled packets 的时候，就会收到若干 grant 了。这就可以按照硬件线路的全速来发送。

如果接收方检测到其 top-of-rack（TOR）交换机发生了拥堵，它就可以选择不发送 grant；这样就可以暂停或减缓 grant 的回应，直到拥塞情况消失。它还可以根据剩余消息的大小，通过发送或不发送 grant 来确定消息的优先次序。在协议中提供了消息 size，这是很有帮助的，因为 "消息 size 使我们能够预测未来"。一旦收到一个消息包，接收方就知道有多少 unscheduled packets 会到来，之后还有多少计划中的数据包会来，这样它就可以迅速决定一个策略，从而在它收到的各种不同的正在传递中的消息的时候尽量减少拥堵。它的反应比 TCP 要快得多。

Homa 还利用了现代交换机的优先级队列（priority queues）；这些交换机的每个出口端口（egress port）通常有 8-16 个优先级队列。它使用了队列（queue）来实现 "最短剩余处理时间"（SRPT，shortest remaining processing time）算法；当某个接收方有多个正在接收的消息时，它允许较短的消息来使用交换机上的高优先级队列。此外，队列中还提供了一种方法来实现 "吞吐量和延迟之间更好的权衡"。

"Buffers 很有趣；你不能和忍受它们，但你也不能没有它们。" 在交换机上总是需要一定数量的 buffer，从而确保在较高优先级的发送者因任何原因停止发送时，链路带宽不会被浪费。通过让较低优先级的数据包排队，并在较高优先级的发送方出现空闲时来发送这些低优先级数据，从而保持吞吐量；然后 Homa 可以向其他发送者发送 grant，从而让他们加速。他说，对 grant 信息的会提供 "overcommitment（过度承诺）"，再配合上带有优先级的 buffer 功能，就可以在得到高吞吐量到同时，让重要的、较短的信息实现低延迟。

人们可能会认为，较长的信息有可能在一个负载过重的网络上出现饿死的情况（starvation）。他说，他试图在 Homa 中产生这种现场，从而对其进行研究，但他发现这真的很难做到；他可以创建出饿死的场景，但必须得通过 "对 benchmark 进行一些歪曲 "来实现。但是，为了避免出现 starvation，Homa 挪用了接收方的一小部分带宽（通常是 5-10%），将其用于等待时间最久的消息（oldest message），而不是严格地按照 SRPT 所说来传输最短小的消息。这样保证了这些消息可以取得进展；最终它们的剩余 size 变得足够小，就可以与其他 small message 一起被优先处理。

Homa 不要求数据包要按顺序交付；数据包可以以任何顺序到达，接收者将根据需要对其进行分类。他说在实践中无论如何，数据包基本上都是按顺序到达的，所以进行重新排序的计算开销并不高。他认为，Homa 消除了数据中心的核心拥堵（core-congestion）问题，除非整体流量本身就过高了。因为数据包可以通过 core fabric 来采用不同的路径。这就可以在 fabric 中更好地实现负载平衡，以及在接收主机的 CPU 核心之间实现更好地负载平衡。

Replacing TCP?

Ousterhout 说，很难想象一个比 TCP 协议更牢固（entrenched）的标准，所以 "我在进行这项工作时充分认识到，我可能是疯了才会想要这么做"。基于他从 Homa 看到的结果，他已经给自己设立了一个任务，要找出一种方法来让 Homa 接管数据中心中大部分 TCP 流量，否则就要得出一个明确的结论说为什么不可能；"我要一直走下去，直到我遇到一个根本无法解决的障碍"。

做到这一点的第一步是要有一个 "人们可以真正使用的"、达到了生产质量（production-quality）的 Homa 实现。他说，他是 "学术界的一个小怪胎"，因为他喜欢写代码。几年前，他着手为 Homa 编写一个 Linux 内核驱动程序；他本来 "对 Linux 内核一无所知"，但现在已经有了一个可以使用的 Homa 驱动程序。

这个 Homa module 可以在 Linux 5.17 和 5.18 上运行，它并不是一个 "研究原型（research prototype）"，这个术语他不喜欢。研究原型是指无法正常用起来的东西，"可以以某种方式写一篇关于它的论文，并提出关于它的主张，尽管它实际上并不真正用起来"。他说，目前 Homa 模块已经接近生产质量；发现和 fix 剩余 bug 的唯一方法是开始在生产环境中实际运行。

他说，就性能而言，Homa 在所有工作场景和所有各种消息 size 方面已经 "完全超出" 了 TCP 和 Data Center TCP（DCTCP）。他给出了几个样例 benchmark，其中显示在第 50 百分位的 short-message latency 方面有 3-7 倍的改进，而在第 99 百分位（"tail latency"）有 19-72 倍的改进。关于 Homa 的内核驱动的更多信息可以在他 2021 年 USENIX 年度技术会议的论文中找到。

Applications

他在这个任务中看到的最大的问题，是有大量的应用程序通过 socket 接口直接使用 TCP。Homa 的基于 message 的 API 与之不同，他一直无法找到一种 "在现有的 TCP 套接字接口下无缝切换" 的方法。但是，不太可能替换这些应用程序中的相关代码，哪怕只替换大部分，也是不现实的。这种直接使用 TCP 套接字的应用程序中的大部分还需要能在广域网上正常工作，而 Homa 并不是一个好的选择；其他的应用程序确实不需要 Homa 带来的性能提升。真正受益于 Homa 的应用是比较新的数据中心应用程序，它们大多都从少数几个 RPC 框架中选了一个来使用。

在 RPC 框架中增加 Homa 支持，就可以让使用了这些框架的应用程序简单地修改某个小的配置选项就能切换到 Homa，而不需要进行很多代码修改；就像应用程序可以改变他们所使用的服务器名称一样，他们将能够选择 Homa 而不用 TCP。他正在进行将 Homa 支持添加到 gRPC 的工作。C++ gRPC 的集成现在已经可以工作了，尽管不支持加密，而 Java gRPC 对 Homa 的支持还是 "萌芽状态（embryonic）"，但仍在继续正在进行开发。

然而，使用 gRPC 的工作让他 "非常难受"，因为它 "慢得难以想象"。gRPC 在 TCP 上的往返延迟是 90µs，其中三分之二的时间花在客户端和服务端上的 gRPC 层（各占了 30µs）。他说，如果目标是达到 5µs 的往返时间，很明显是无法使用 gRPC 来做到的。使用 Homa 之后，gRPC 的速度大约达到了两倍快，甚至在 endpoint 上的 gRPC 层也能看到这样的速度提升，他对此其实并没有什么好的解释。但即使是这样也离目标很远，所以他认为最终需要开发一个 "超级轻量级 "的框架。

他说，即使有了 Homa，性能仍然与硬件所能达到的水平差一个数量级。"网络速度正在以这种惊人的速度增长，而 CPU 的速度却没有什么变化"。软件根本无法跟上，他认为这个问题没有解决办法。所以传输协议的软件实现就不再有意义了；这些协议都需要转移到网卡（NIC）中。

Moving to user space

有些人会说，你只需要把 "那些可怕的操作系统" 赶走，把所有东西都转移到用户空间就好；他说，这会有一些帮助，但是完全不够的。在 RAMCloud storage project 里，斯坦福大学的研究人员在用户空间实现了 Homa，能够实现 14µs 的 99% round-trip latency，而 Linux 上 Homa 的 tail-latency 是 100µs。

这么高的 tail latency，主要罪魁祸首是软件开销，尤其是负载平衡方面的开销。单个 CPU core 不能处理超过 10Gbps 的数据，但要是你把工作分到多个 core 上，就会固定有一部分的性能损失，这是由于需要进行工作分配。除此之外，还有一个 hot spot 问题，也就是在某些 core 上有太多的工作了，而其他 core 则处于 idle 状态或大部分时间处于 idle；这些都会导致出现一些 high latency 的高峰（spike）。

他没有测量过，但他的理论是，将工作拆分到多个核心上带来的固有降速，是由于 cache interference 导致的。与在单核上进行处理相比，来自于分配工作导致的大量 cache-coherency traffic 降低了性能。不仅仅是他的 Homa 实现中看到了这个数量级的损失；他在谷歌的 Snap/Pony 系统中看到，当从单核切换到多核处理时，它的效率损失是 4-6 倍。他说，这里有一个经验法则，如果你需要不止一个 CPU，那么只增加第二或第三个 CPU 是不够的；"你实际上必须做到四核，才能真正比单核提升更多的性能"。

Ousterhout 说，如果你看一下各种论文中的一些数字，你可能会得出结论，将协议处理转移到用户空间是一个好主意。但是，所有这些用户空间的实现 "基本上只是研究原型，而且它们过于简化"；它们没有完成生产系统所需的大量处理工作。它们也是在最理想的条件下测量的，要么没有负载平衡，要么有完美的人工分析之后进行的分区配置，只处理短消息（"这太容易了"），等等。

但是 Snap 是一个可以用来比较的、达到了生产质量的用户空间实现；它大约比 Linux 内核中的 Homa 好 2 倍。如果你看一下双向实现 80Gbps（80%负载的 100Gbps 网络）所需的 CPU core 的数量的话，Snap 需要 9-14 个内核，而 Linux Homa 需要 17 个。所以用户空间更好，但并不会带来数量级的变化。

To the NIC

他认为人们唯一的选择是将传输层的协议处理转移到网卡中去。应用程序将直接访问网卡，绕过内核，通过一个基于消息的接口来实现；"packet 这个概念从不进入软件"。其他功能，如通过选择一个空闲的应用程序线程来实现负载平衡、虚拟化和加密，也应该被添加到网卡上。

他说，很难明确确认这种网卡的架构；它们需要以硬件线路的速度来处理数据包，同时可以编程来支持多种协议。Ousterhout 说，同样重要的是，这些协议的程序仍然应该是开源的。他认为，现有的 "智能网卡（smart NIC）" 架构没有一个达到了要求，所以这是一个值得计算机架构师来解决的问题。

Homa "并非没有争议"；已经有几篇论文声称发现了 Homa 的一些问题。在其他论文中也提出了一些替代方案，但 "不幸的是，所有这些论文都有相当大的缺陷"。在他看来，他们在不现实的配置中使用 Homa，或者以某种方式阻碍了它；虽然他不 "想陷入一场口水战"，但他已经在 Homa 维基上集中汇总了一些他给出的回应。

但是有一个更大的 "基本问题（meta question）"需要被回答："应用程序是否真的希望利用全部的网络性能？" 今天，我们 "陷入了一个 no-chicken-no-egg 的循环"，没有需要全部硬件能力的应用，因为没有办法支持。因此，今天的应用程序只能利用今天的网络协议栈所提供的性能，并没有什么真正的动力来使基础设施更快，因为没有人在 "呼喊"。

因此，他想知道，如果我们使网络达到 "像我认为的那样快得刺眼" 的程度，是否会出现人们今天由于没有这么快的网络导致人们甚至都没有想到的一些新应用？他很想听听有哪些应用会因为性能的提高而得到极大的改善。作为一个学者，他实际上不需要有市场；他可以建立一些东西，并希望以后有应用出现，但这 "将是一个糟糕的创业方式"。

他最后重申介绍了在他的观念中，如果应用程序想要利用上网络速度的惊人进步，主要需要做什么。会需要一个新的传输协议；他显然是 Homa 的拥护者，但也乐意讨论其他的可能性。除此之外，也非常需要一个新的轻量级 RPC 框架，最终，无论使用什么传输协议，都需要下移到 NIC 中。Ousterhout 的主题演讲提出了对当今数据中心网络状况进行相当彻底的改造的设想；很期待看到未来几年将会如何演变。

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

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

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