关于程序员:下一代TCP-网络演进的平台

2次阅读

共计 2507 个字符，预计需要花费 7 分钟才能阅读完成。

随着往年 TCP 最新标准 RFC 9293 的公布，IETF 对过来几十年 TCP 的倒退做解决阶段性总结，同时也是下一阶段倒退的终点。随着网络规模的扩充和倒退，兴许有一天 TCP 会隐没，或者演变为基于业务的可编程平台，置信今后会有很多好玩的货色呈现。原文: 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 中所说: