yuff100

V1

2022/11/05阅读:22主题:极简黑

下一代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[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

参考资料

[1]

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

- END -

分类:

后端

标签:

计算机网络

作者介绍

yuff100
V1

俞凡,公众号DeepNoMind