It‘s Time to Replace TCP in the Datacenter 读后

Posted 2022-11-26 dog250

从经理那了解到一个有趣的分享：

It’s Time to Replace TCP in the Datacenter

以及与它相关的论文：It’s Time to Replace TCP in the Datacenter[PDF]

对 TCP in DC 的吐槽，就我这水平，大致内容和 John Ousterhout 的分享相差亦无几，看起来已是共识。基本上，TCP in DC 的问题在于：

• Stream 抽象无法利用主机并发资源，无法多线程负载均衡处理消息(屡次谈到消息边界)。
• Connection 抽象消耗内存和时间，发送短消息也要三次握手并存储 state。

此外，还有拥塞控制的 issues，不再评论原文。

抛开人文和历史，论文中每一个细节都能作为一个主题来优化，至少可写一篇长文。但这是加薪晋升和公众号涨粉的事，我还是喜欢讲形而上和历史。

DC 和 Internet 有什么本质不同，以至于非要一个 Replacement for TCP in the Datacenter。
DC 不是一个网络，从空中看，一个 DC 就是一台机器，机架就是 CPU 槽，内存槽，每台机器里跑的是 “微服务”，微服务之间传递的是 “消息”。

微服务分布式部署，分布式的愿景是 “不同的部分完成同一件事”，两台机器保存相同的数据意味着冗余，这与分布式愿景背道而驰。只传递指令少传递数据的传输是 DC 中高尚的传输，典型的是 RPC。

多核服务器中，Core 负责计算，Mem 负责数据，无论 Core 间通信，还是 Core 和 Mem 通信，很容易理解减少甚至避免大块内存拷贝的意义，仅做计算以及 Load/Store 指令，换做 DC 网络传输，同理，流式大块数据传输即内存拷贝，趋向减少，尽可避免。

这就是 “TCP in DC 不再适合” 的根本(读一读《云原生模式-设计拥抱变化的软件》是高尚的)。因为场景与 Internet 完全不一致。

要在 DC 传输流式大块数据时，先别问如何优化传输，先问这次传输真的必要吗？为什么不能本地处理，非要传输到远端？如需分布式存储，数据落盘就应散列落盘才对，不同的设计会影响行为制定。

总之，在 DC 网络中很少需要流式大块数据传输，甚至一个 “TCP 连接” 都是转瞬即逝的。

对于短消息传输，Connless 至关重要！它亦是 “颠倒一下” 的典型案例，从而将 per-peer Connection 转换为了 per-call Connection，甚至 per-message Connection。由此，内存的消耗将仅受并发的限制。

试想，如果短消息大扇入的同时又大扇出，若保持 per-peer Connection，为保存 state 的内存占用即 O(n^2)，如果 per-call Connection，state 的生命周期便和 call/message 生命周期一致了。

说下拥塞控制相关 issue。

TCP 那套拥塞控制是反馈式的，Rate-based 也好，AIMD 也好，都在一条持续的流上起作用。对于 DC 网络典型的短消息传输，尚未获取到足够的反馈信息，传输已结束，任何高尚算法的初始参数便同盲猜无异。

So? 拥塞控制的思路一定要改。

和 TCP 长流的慢启动策略相反，对短消息传输，线速突发反而更有效。DC 网卡带宽越来越大，以 25Gbps 为例，DC 内普遍 RTT 在 50us，1 个 RTT 内可发送 100 个 1500B 的报文。现实中，这已是一笔很大的数据。更普遍的场景，一则 RPC 消息在一次突发传输结束的概率非常大。

TCPer 们写了高尚的算法，非常精细地测量和使用 ACK 信息，还没等到 ACK，来不及运作，传输已结束，到头来只有一个 init cwnd 有用，DC 内有效的拥塞控制工作绝大多数时刻只是确定一个 init cwnd。

至于拥塞控制的实际实施，交换机只要支持 “越短消息越优先” 就能保证足够公平，剩下的交给 PFC，ECN，Host-AIMD。

最后，关于可靠传输，这也是循惯了 TCP 的影子后，最令人纠结的一点，连接都没了，哪里保存 Timer，哪里保存重传信息。就好像传输协议必须是 yet another TCP 一样。

早些时候我也没想通，后来从远处看就想通了。

首先，传输不一定必须可靠，应用更懂该怎么做。应用在时间阈值后没得到回复，请求别的目标可能优于死等，换句话说，传输可以失败，只要应用知道如何应对失败即可。

其次，如果应用需要传输层保证可靠，以 per-call 作为事务进行可靠传输即可。该策略亦衍生自短消息特征。每一次传输将消息数量和大小作为元数据，这很容易帮助接收端检测空洞并发起 NAK，同时，发送端在时间阈值内未收到 response 即重传。

下图展示 Homa 的做法：

说回 John Ousterhout 的演讲和论文，我承认他所谓 “We Need a Replacement for TCP in the Datacenter”，但若只为推广 Homa，说这么多反而啰嗦。因为早在多年以前很多人就知道这件事了。

TCP 没有被轻易换掉的原因不是技术，而是成本。若真因为技术，TCP 早被替换好几回了，不光在 DC，在 Internet 或许也早就没了影子。问题在于，罗列对错是一回事，撼动合理的当下是另一回事。

当然，大多数程序员不屑于讨论和技术细节无关的投入产出问题，换句话说，程序员更倾向于识别正确的方案并实现，而不管值不值得。

幸运的是，人们已经认识到一辆普通的车也好于一匹更快的马，将更多资源投入 DC transport 而不是优化 TCP。相反，但凡拿着 TCP 那套可怜而受限的机制迭代优化，其行为便无异于寻找更快的马了。

信惯了 TCP，别的模型都不对。复杂性从主机加诸网卡和交换机，与 Internet 端到端原则背道而驰，会引起很多不适，但事情要从根本去问，端到端原则普遍正确吗？

端到端原则最大的收益是扩展性，这是 Internet 快速发展的核心。但 DC 相对固定，没有异构新节点频繁接入的需求，另一方面，DC 服务器属计算资源，倾向于将传输协议 Offloading 到底层和中心，保持服务器计算密度最大化。这个视角看，端到端原则岂不是罪过？

抛开场景不能谈原则。

我假设上面已经描述清楚。接下来重新审视 DC 传输。

所谓 DC 传输，将一笔数据传到不远处的对端，这笔数据分割，打包，发送，这是显而易见的做法，没有任何理由需要事先建立一个连接，让这笔数据以流的方式按序流入对端内存，说实话，TCP 才是奇怪的方式。

回到 1970年代，以那时主机的内存水平，网络带宽，基于虚电路的流式传输是一个创新之举，但现在不是，无论对 DC 而言，or Internet。

周三经理推荐了个有趣的分享和论文，我看了后表示赞成，不过重新翻译分析一遍论文没意义，本身就是很容易理解的技术点，就看你能不能想到。那就写篇读后感吧，写一点文中没有表述的东西。

浙江温州皮鞋湿，下雨进水不会胖。