作者 | 核子可乐、钰莹
四十年过去了，此番新协议的出炉也许又将掀起一波变革浪潮......
作为过去四十年间最根深蒂固的标准之一，大家耳熟能详的传输控制协议（TCP）没准即将走向生命周期的终点。而这波变革的起点，应该会从全球规模最大的数据中心应用场景开始。但对于其他日常应用场景来说，哪怕有望把消息传递速度提升 100 倍，似乎也无法抵偿协议转变带来的巨大麻烦。
不过从历史经验来看，一切曾经专属于超大规模企业的技术优势，最终都将为中型 IT 部门所用。所以……我们不妨拭目以待。
1 TCP 协议不适用如今的数据中心
四十年前，TCP 一诞生就将目光投向多达上千个地理分布节点网络，且各节点间往往相距数百英里，属于名副其实的前沿科技。即使到今天，TCP 协议仍然能够实现大量数据的远距离传输工作，因此继续作为几乎一切 Web 技术的默认基础。
然而，如今的数据中心可跟当初大不相同。现在我们需要跟成百上千台机器打交道，在极短的时间间隔内进行通信。具体来讲，老迈的 TCP 是为了在毫秒单位下将数据包由网络一端传输至另一端而设计的，如今的数据中心却要求微秒级的数据传输速率。
斯坦福大学计算机科学系教授 John Ousterhout 在采访中表示，“TCP 的问题在于，它妨碍了我们运用数据中心网络的强大能力。现有网络已经可以在更短的时间尺度上实现机器之间的快速消息传递，但 TCP 拖了后腿。TCP 在设计上就没有考虑到这样的使用场景。”
触及 TCP 能力边界早已不是什么新鲜事，研究人员也想办法在某些核心问题上取得了进展。例如在拥塞控制中解决多台机器同时向单一目标发送消息的问题，就是依靠网络备份实现的。但这些都是在给本质上不适用的东西“打补丁”，做增量化调整。而以谷歌为代表的数据中心巨头们，已经不堪忍受 TCP 对于现实应用的种种限制。
在他看来，“对数据中心而言，TCP 中的每个设计决策都可以说是错的，而且没法用任何手段加以根治。唯一的办法就是全面做出修改，包括 API，也就是人们用来发送和接收数据的接口，全都得改。”
当然，这事说着容易做起来难。用“根深蒂固”甚至都不足以表达 TCP 的普及程度——几乎一切软件都依赖于它，而且是以非常具体、非常紧密的方式依附在它之上。
2 颠覆者 Homa 出现
作为系统研究领域的参与者之一，Ousterhout 和他的同行们打算放下历史包袱，勇敢探索这条荆棘丛生但又意义重大的道路。
有些朋友可能觉得 Ousterhout 这名字有些耳熟。没错，他目前的工作是在斯坦福大学研究分布式系统和软件，而且之前就曾经为不再适合时代需求的事物开发过替代技术，例如三十多年前的高级 Tcl（工具命令语言）脚本语言。
这段经历也促使他加入 Sun 公司，最终建立了自己的 Tcl 支持与工具开发商 Scriptics。在他的专利探索与研究当中，贯穿始终的主题一直是从传统技术根源中提取精华，并用更契合现代系统思维的事物取而代之。
对于 TCP 这个“历史遗留问题”，他给出的答案是 Homa。Ousterhout 已经在 Linux 内核上实现了 Homa，并且为生产环境做好了准备。接下来的挑战在于如何推进应用程序转换，让自己的新接口为更多生态成员所接纳。这是一项宏大且漫长的计划，毕竟目前数以百万计的应用程序都依赖于 TCP。
所以工作的第一步就是从超大规模运行环境开始，帮助受 TCP 影响最大的应用程序和用户。大多数运行在谷歌、亚马逊或 Azure 超大规模一数据中心内的应用程序，在编程时往往不会直接使用 TCP 套接字接口，而是使用可实现远程过程调用的库。具体来讲，其中一个程序会向其他机器发送一条消息，要求对方执行一项任务，再通过简短的响应获取执行结果。超大规模数据中心的操作者们大多依赖于相应的远程过程调用（RPC）框架，而且通常会选择内部原研工具，例如谷歌的 gRPC。在 Ousterhout 看来，如果谷歌能够修改自家框架以支持 Homa 和 gRPC，那原本的应用程序只要稍作调整应该就能对接自己的 Homa 新协议。
他解释道，“这也是脱离 TCP 的最大希望所在。如果我们能迈出这第一步，那大部分最重要的数据中心应用程序都可以用上 Homa 新协议。”他很清楚，相当一部分应用程序依靠 TCP 就足够了；只有那些规模最大的数据中心应用程序才有动力转向 Homa，配合内部定制的 RPC 工具将消息传递速度提高上百倍。对任何超大规模基础设施管理者来说，这都是一笔不容忽视的重大性能收益。
3 有关 TCP 协议的研究，国内早已开始
在过去的几十年中，TCP 相关的基本操作未做太大改动，但其拥塞控制算法经历了几代学者和工程师的迭代更新，比如 RFC2581《TCP 的拥塞控制》、加州理工学院研发的 FAST TCP 以及目前在数据中心网络中被广泛使用的 DCTCP 等。
然而，在过去几十年中发生变化的不仅仅是算法本身，网络环境也发生了巨大变化，尤其是云计算出现之后，云租户和应用对网络带宽、延迟以及稳定性的要求比过去的互联网用户提升了一到两个数量级，这导致传统 TCP 协议开始难以适用于云网络（数据中心网络）的高速、低延迟环境。虽然 RDMA 等新一代技术摒弃了传统 TCP 中的一些做法，以换取网络性能的大幅提升，但是 RDMA 拥塞控制算法本身蕴含着相当高的不稳定性风险，阻碍其在大规模网络中得到广泛应用。
三年前，阿里巴巴的一群工程师成功研发出新一代、超高性能云网络环境下对传统 TCP 和 RDMA 拥塞控制算法的替代方案–HPCC，旨在同时实现高速云网络的极致性能和超高稳定性。这一成果已被计算机网络方向世界顶级学术会议 ACM SIGCOMM 2019 收录，引起了国内外广泛关注。
HPCC 是在高性能的云网络环境下，对现有的拥塞控制的一种替代方案。它可让数据中心网络中的报文稳定的、以微秒级的延迟传输。当前主流的拥塞控制算法主要依赖于端的信息（例如丢包信息，延迟信息），以及极为有限的设备反馈信息（如 1 个比特的 ECN）做拥塞控制，而 HPCC 则创新性地运用了最新网络设备提供的细粒度负载信息而全新设计了拥塞控制算法。在 HPCC 的帮助下，主流的云应用，比如分布式存储、大规模机器学习，高性能计算等性能会得到几倍到几十倍不等的提升；云租户相应地将会感受到延迟显著降低，效率和性价比大幅提升。
在计算机网络里，传统的拥塞控制算法主要通过在端上调节流量，以维持网络最佳平衡状态。发送方根据网络承载情况控制发送速率，以获取高性能并避免拥塞崩溃（congestion collapse）导致网络性能下降几个数量级，并在多个数据流之间产生近似最大化最小流的公平分配。发送方与接收方确认包、包丢失以及定时器情况，估计网络拥塞状态，从而调节数据流的发送速率，这被称为网络拥塞控制。HPCC 的核心理念是利用精确链路负载信息直接计算合适的发送速率，而不是像现有的 TCP 和 RDMA 拥塞控制算法那样迭代探索合适的速率；HPCC 速率更新由数据包的 ACK 驱动，而不是像 DCQCN 那样靠定时器驱动。目前业内对网络传输协议的选择基本分为两大类：一类是以 TCP 为主，持续探索如何将 TCP 的性能调至更优的状态；另一类则希望研究可以取代 TCP 的新传输协议。HPCC 的出现为下一代拥塞控制开拓了一个全新的方向，无论是 TCP, 还是 RDMA，抑或是某种新的传输层协议，都可以直接使用 HPCC，或是在其基础上构建适用于高性能云网络的拥塞控制机制。
参考链接：
https://www.theregister.com/2022/07/27/replace_tcp_datacenter/
今日好文推荐
拒绝高估值？这家低代码平台火了后：不能让老员工凭股权成百万富翁、新员工失望
Firefox 的衰落为什么是必然的？
每日优鲜回应清退解散；国内 Go 语言爱好者发起新编程语言；微信安装包 11 年膨胀 575 倍｜Q 资讯
试图颠覆 JavaScript 生态？亲身试用新 JS 运行时 Bun 后，我觉得未来可期
