随着今年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[1])的发布，我们需要反思TCP在过去几十年的发展，并想知道未来会发生什么。
传输控制协议(TCP)原始规范在1981年作为RFC 793[2]发布。在过去的四十年里，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[3])，但最终在21世纪初被Linux所取代(现代许多商业操作系统都是从BSD或Linux派生出来的)。
但是Linux版本的TCP不仅仅是参考实现，可以认为Linux内核为TCP的发展提供了一个平台。在阅读RFC 9293的时候，我隐约记得在TCP扩展的鼎盛时期发表过一个RFC，标题为"TCP扩展是有害的(TCP Extensions Considered Harmful)"，我谷歌了一下，是RFC 1263[4]。(其实我也是该研究的合著者，可能我还写过什么东西，但现在早就忘记了。)该RFC介绍了TCP演化的一般机制，而这些机制比TCP扩展选项更合理(实质上是提出了今天被称为语义版本控制[5]的东西)，但其中有一个和现在相关的结论:
由于缺乏任何替代方案，TCP实际上已经成为实现其他协议的平台。它与内核提供了一个模糊的标准接口，运行在许多机器上，并有定义良好的分发路径。
这让我们陷入了一个模糊的两难处境，是将TCP作为平台来发展传输功能，还是作为Linux网络子系统。但实际上两者并没有区别，可选头字段可以作为向内核添加"传输插件"的一种方法。(这里我使用的是平台的一个简单定义，即它是一种工具或框架，可以随着时间的推移添加新功能。)
将Linux TCP作为可扩展框架的另一个例子是拥塞控制。《TCP拥塞控制详解》书中介绍的所有算法都可以在Linux内核中使用(可以选择激活)，在Linux内核中，与TCP本身一样，其实现就是算法的权威定义。因此，出现了一种用于拥塞控制的API，提供了定义良好的方法来不断适应TCP。考虑到特性开发速度，Linux现在提供了一种更为方便安全的方式，即通过*eBPF*[6](extended Berkeley Packet Filter)通过API动态的向内核注入新的拥塞控制逻辑，从而简化试验新算法或调整现有算法的难度，避开了等待相关Linux内核部署的障碍。还可以方便的定制每个流所使用的拥塞控制算法，以及显式的向决策进程开放设备级入口/出口队列。(这就是在Linux内核中支持CoDel和ECN[7]的方式。)
这真是个好消息，但作为研究如何最有效发展软件的案例，结果还是喜忧参半。例如，就API而言，Linux TCP拥塞控制API不是特别直观，唯一的文档都在代码[8]中。其次是其复杂性，虽然API可以将不同算法替换到TCP中，但理想的接口应该支持复用，使不同传输协议(如SCTP、QUIC)可以复用现有算法，而不必维护单独/平行实现。我们看到的第三个结果是，虽然Linux在使文件系统可替换方面做得很好(可以以安全和高性能的方式[9]完成)，但这种方法并不适用于TCP，因为TCP在整个内核中有太多依赖。所有这些，再加上RFC 1263中所提到的TCP可选项的局限性，可能会让我们得出这样的结论，即TCP在这些年里的发展并没有触及其自身，我们至少会对失去的机会感到遗憾。
与此同时，云计算基于TCP发展了起来，其重点是提高特性开发速度。一旦能够决定连接的两端各自运行什么代码，(物理层之上的)协议标准就不那么重要了，云计算和现代应用很好利用了这一点。人们不得不怀疑，如今的TCP是否会在未来消失，不是因为会出现全新的替代品，而是因为有可能被云计算实践所取代。QUIC[10]似乎是对这一假设的很好的测试，它既提供了TCP所没有的价值(设计良好且高效的请求/应答机制)，又提供了持续集成和持续部署[11]新特性的现代方法。
一个可能的结果是网络作为整体成为一个可编程平台[12]，从终端传输协议到网络交换机的转发流水线，提高所有特性的发布速度。平台越完整、敏捷，RFC所定义的规范就越有可能被淘汰。正如RFC 1263中所说:
我们希望能够在更短的时间内设计和分发协议，而不是由标准委员会商定可接受的会议时间。
也许我们正在接近实现这一目标。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind
参考资料
RFC 9293: https://www.rfc-editor.org/rfc/rfc9293
[2]RFC 793: https://www.rfc-editor.org/rfc/rfc793
[3]FreeBSD: https://www.freebsd.org
[4]RFC 1263: https://datatracker.ietf.org/doc/html/rfc1263
[5]语义版本控制: https://semver.org
[6]eBPF: https://www.kernel.org/doc/html/latest/bpf/index.html
[7]TCP拥塞控制详解 | 6. 主动队列管理: https://mp.weixin.qq.com/s?__biz=MzU2MTgxODgwNA==&mid=2247485957&idx=1&sn=ab8fec470c30d41f66dcb6d54c77060b&chksm=fc73b7decb043ec859ab33c90e2f6c23faabac3d0177e913982f67c65f3ad26862368ce35ca8&token=748652781&lang=zh_CN#rd
[8]tcp_cong.c: https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_cong.c
[9]High Velocity Kernel File Systems with Bento: https://www.usenix.org/conference/fast21/presentation/miller
[10]QUIC: https://systemsapproach.substack.com/p/the-importance-of-thinking-across
[11]边缘云之生命周期管理: https://ops.systemsapproach.org/lifecycle.html
[12]可编程平台: https://www.youtube.com/watch?v=CcHBE7maCyo
本文由 mdnice 多平台发布
扫一扫
845
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
