斯坦福大学教授大力倡导用一种新协议Homa取代TCP

[!quote]+

一位退休的斯坦福大学教授认为，TCP作为几乎整个网络和大部分云计算所建立的数据传输协议，并不适合新兴的人工智能工作负载。为了解决问题，他正在推广一种名为Homa的新协议。

斯坦福大学计算机科学名誉教授John Ousterhout在最近于人工智能工程师世界博览会的演讲中表示：“TCP尽管做了许多令人惊叹的事情，但它并不适合数据中心。”

鉴于全球对该协议的依赖，摆脱TCP听起来是一项巨大的任务。但将Homa纳入网络其实相当简单，Ousterhout告诉《纪事报》。从GitHub源代码编译Homa，然后将模块安装到客户端和服务器上的Linux内核中。不需要重启。

他写道：“Homa与TCP并行工作，因此你可以逐步将应用从TCP迁移到Homa。”运行Homa甚至让剩余的TCP应用运行更快。

陈年美酒，新皮肤

Ousterhout表示，Homa是对网络如何管理交通拥堵的全新思考。

该方案的工作始于2019年由现任谷歌工程师的Behnam Montazeri发表的博士论文。他说，奥斯特豪特退休后，将传播霍马作为他的“毕生使命”承担起了任务。

Homa 与 TCP 的主要区别在于它基于消息，而非基于流。与远程过程调用（RPC）类似，Homa消息长度被明确定义。

与TCP不同，Homa指定接收端管理拥塞控制。接收方收到的第一个数据包包含了有多少数据进入的信息。然后它可以明确安排数据包的发送时间。在此过程中，它使用最短剩余处理时间（SRPT）算法优先处理较短消息。

Ousterhout表示，这种方法将短消息的延迟降低了一个数量级。短消息的第99百分位（p99）延迟是Homa的92微秒，比TCP的1.2毫秒快13倍（基于100 Gbps网络中80%利用率下的数据包）。

奥斯特豪特说，即使是最长的信息，霍玛的表现也好两倍。

TCP在其他任务中表现不佳的长长列表

目前，Ousterhout 正在起草该协议的 IETF 标准化文件，并着手将 Homa 上游到 Linux 内核。3月，该协议被回移植到Red Hat Enterprise Linux的8和9.5版本。

他还在帮助大型企业研究Homa的适用性——目前他正与一家大型金融服务公司合作开发原型。

并不是所有人都支持因为几个延迟问题就放弃TCP。

著名网络架构师伊万·佩佩尔尼亚克（Ivan Pepelnjak）在2023年发表了一篇严厉的立场文件，质疑Ousterhout对TCP的性能描述，并批评Homa作为一个寻找问题的解决方案。

公平地说，AI社区并不是唯一一个对这款老套TCP感到沮丧的生态系统。

在高性能数据库社区，DPDK（数据平面开发套件）被用来绕过TCP协议栈以加快查询速度。存储区域网络转向NVMe-oF（NVMe over Fabrics）以加速通过网络结构访问固态硬盘，使用包括RDMA、光纤通道和TCP等传输方式。对于网络，谷歌设计了QUIC——成为HTTP/3的基础——以绕过TCP的首行封锁，使浏览器能够同时下载更多资源。

此外，高频交易和多人游戏社区也感受到TCP的迟缓带来的压力。

专用的RDMA结构和亚马逊云服务的可扩展可靠数据报也解决了TCP延迟问题。机架顶交换机在管理拥塞、设置队列阈值以及提前通知拥塞数据包方面也变得更加智能。

控制延迟确实存在

Vint Cerf和他的“胡子”伙伴们创建TCP，旨在为网络中混乱的消息包带来秩序，赋予它们适当的流量控制、保证送达、连接握手和拥塞控制。拥塞控制意味着避免网络路径（包括交换机和路由器）过载，同时通过独立的流量控制机制防止发送端让接收端不堪重负。

TCP的数据模型建立在字节流之上，即连续流的数据包，没有差异化。消息以单字节流序列化，没有优先级。对于接收端来说，较长的字节流集与较短的字节流无法区分。

流量洪流的服务器可以向发送方发送延迟输入的警报，但对仍有多少流量的可见性有限。发送方自身根据接收方回应的及时性调节输出，必须猜测该减慢滚动速度的程度。

对于常规互联网流量或数据中心内的大规模传输，适度的延迟增加可能被容忍。但对于延迟敏感的AI工作负载，即使是以毫秒为单位的延迟也会带来刺痛。

想想显卡

推动大型语言模型（LLMs）开发的前沿实验室一直要求在权重梯度、模型权重、KV缓存条目和检查点等任务中具备顶尖的网络性能。

然而，大规模数据传输必须越来越多地与代理和控制任务（如元数据协调和缓存查找）共享带宽。

“对于这些工作负载，真正重要的是延迟，”Ousterhout说。哪怕只有一毫秒的延迟，昂贵的显卡就会进入空闲状态。

“传统协议不适合这种环境，”奥斯特豪特说。

那么，Homa终于找到了自己的问题可以解决吗？还是说它一直都走在了时代前面？至少目前，TCP依然是冠军。 ®