随着往年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中所说:
咱们心愿可能在更短的工夫内设计和散发协定，而不是由规范委员会约定可承受的会议工夫。
兴许咱们正在靠近实现这一指标。
*你好，我是俞凡，在Motorola做过研发，当初在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。 \
微信公众号：DeepNoMind*
本文由mdnice多平台公布