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

随着今年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多平台发布

你可能感兴趣的:(程序员)