下一代 TCP: 网络演进的平台

随着今年 TCP 最新规范 RFC 9293 的发布，IETF 对过去几十年 TCP 的发展做处理阶段性总结，同时也是下一阶段发展的起点。随着网络规模的扩大和发展，也许有一天 TCP 会消失，或者演变为基于业务的可编程平台，相信今后会有很多好玩的东西出现。原文: [TCP: The "P" is for Platform](https://systemsapproach.substack.com/p/tcp-the-p-is-for-platform "TCP: The "P" is for Platform")

随着最近 TCP 新规范(RFC 9293)的发布，我们需要反思 TCP 在过去几十年的发展，并想知道未来会发生什么。

传输控制协议(TCP)原始规范在 1981 年作为RFC 793发布。在过去的四十年里，TCP 被证明是一个不死板的充满弹性的协议，有众多扩展和实现，因此很难跟踪所有变化，很容易错过某个重要特性。而刚刚发布的 RFC 9293(2022 年 8 月)，就是为了解决这个问题。作为一个重要的里程碑，RFC 793 现在正式过时了。

对于经历了 TCP 大部分发展过程的人来说，阅读 RFC 9293 就像在回忆中漫步，从愚蠢的窗口综合症到慢启动、快速重传、重复 ACK、窗口缩放等等，TCP 的历史就是一个系统演进的很好的研究案例。对研究人员来说，提出全新设计是很有诱惑力的想法，但 TCP 中有太多历史经验和包袱，任何替换方案都需要跨越非常高的门槛。

让我们先忽略掉细节，退后一步看看"系统演进"的故事，其中有几件事让我印象深刻。对于初学者来说，我比较讨厌仅仅基于阅读 RFC 9293(及其引用的其他 RFC)来从头实现 TCP。至于这么做是否可行本就是一个开放问题，多年来 TCP 一直是由其参考实现定义的，RFC 更多的是描述性的而不是规范性的。这不是批评，因为从一开始 IETF 就偏爱基于实现来定义协议，而 RFC 9293 则是这一迭代过程中最新的更新。

如果由实现驱动规范，那么哪个实现是权威的？答案是当今占主导地位的开源实现，也就是最初由 BSD(Berkeley Software Distribution) Unix 所作的实现。BSD 及其后代一直延续到今天(最著名的是FreeBSD)，但最终在 21 世纪初被 Linux 所取代(现代许多商业操作系统都是从 BSD 或 Linux 派生出来的)。

但是 Linux 版本的 TCP 不仅仅是参考实现，可以认为 Linux 内核为 TCP 的发展提供了一个平台。在阅读 RFC 9293 的时候，我隐约记得在 TCP 扩展的鼎盛时期发表过一个 RFC，标题为"TCP 扩展是有害的(TCP Extensions Considered Harmful)"，我谷歌了一下，是RFC 1263。(其实我也是该研究的合著者，可能我还写过什么东西，但现在早就忘记了。)该 RFC 介绍了 TCP 演化的一般机制，而这些机制比 TCP 扩展选项更合理(实质上是提出了今天被称为语义版本控制的东西)，但其中有一个和现在相关的结论:

由于缺乏任何替代方案，TCP 实际上已经成为实现其他协议的平台。它与内核提供了一个模糊的标准接口，运行在许多机器上，并有定义良好的分发路径。

这让我们陷入了一个模糊的两难处境，是将 TCP 作为平台来发展传输功能，还是作为 Linux 网络子系统。但实际上两者并没有区别，可选头字段可以作为向内核添加"传输插件"的一种方法。(这里我使用的是平台的一个简单定义，即它是一种工具或框架，可以随着时间的推移添加新功能。)

将 Linux TCP 作为可扩展框架的另一个例子是拥塞控制。《TCP拥塞控制详解》书中介绍的所有算法都可以在 Linux 内核中使用(可以选择激活)，在 Linux 内核中，与 TCP 本身一样，其实现就是算法的权威定义。因此，出现了一种用于拥塞控制的 API，提供了定义良好的方法来不断适应 TCP。考虑到特性开发速度，Linux 现在提供了一种更为方便安全的方式，即通过eBPF(extended Berkeley Packet Filter)通过 API 动态的向内核注入新的拥塞控制逻辑，从而简化试验新算法或调整现有算法的难度，避开了等待相关 Linux 内核部署的障碍。还可以方便的定制每个流所使用的拥塞控制算法，以及显式的向决策进程开放设备级入口/出口队列。(这就是在 Linux 内核中支持CoDel和ECN的方式。)

这真是个好消息，但作为研究如何最有效发展软件的案例，结果还是喜忧参半。例如，就 API 而言，Linux TCP 拥塞控制 API 不是特别直观，唯一的文档都在代码中。其次是其复杂性，虽然 API 可以将不同算法替换到 TCP 中，但理想的接口应该支持复用，使不同传输协议(如 SCTP、QUIC)可以复用现有算法，而不必维护单独/平行实现。我们看到的第三个结果是，虽然 Linux 在使文件系统可替换方面做得很好(可以以安全和高性能的方式完成)，但这种方法并不适用于 TCP，因为 TCP 在整个内核中有太多依赖。所有这些，再加上 RFC 1263 中所提到的 TCP 可选项的局限性，可能会让我们得出这样的结论，即 TCP 在这些年里的发展并没有触及其自身，我们至少会对失去的机会感到遗憾。

与此同时，云计算基于 TCP 发展了起来，其重点是提高特性开发速度。一旦能够决定连接的两端各自运行什么代码，(物理层之上的)协议标准就不那么重要了，云计算和现代应用很好利用了这一点。人们不得不怀疑，如今的 TCP 是否会在未来消失，不是因为会出现全新的替代品，而是因为有可能被云计算实践所取代。QUIC似乎是对这一假设的很好的测试，它既提供了 TCP 所没有的价值(设计良好且高效的请求/应答机制)，又提供了持续集成和持续部署新特性的现代方法。

一个可能的结果是网络作为整体成为一个可编程平台，从终端传输协议到网络交换机的转发流水线，提高所有特性的发布速度。平台越完整、敏捷，RFC 所定义的规范就越有可能被淘汰。正如 RFC 1263 中所说:

我们希望能够在更短的时间内设计和分发协议，而不是由标准委员会商定可接受的会议时间。

也许我们正在接近实现这一目标。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind