QUIC取代了TCP成为HTTP3的基础传输协议,不是因为QUIC能够取代TCP的所有应用场景,而是因为QUIC更适合HTTP的请求/响应业务模型。原文: QUIC Is Not a TCP Replacement
TCP新规范(RFC 9293)的发布是网络界的一件大事,值得围绕这一主题发表第二篇文章(第一篇: 下一代TCP[1]),本文我们将围绕QUIC和TCP的比较展开。
我们在上一篇关于TCP的过去和未来的文章中,谈到了QUIC可能取代TCP的可能性。本文我们想说的是,实际上QUIC解决的问题与TCP解决的问题有所不同,因此不应该被视为TCP的替代品。对于某些(甚至大多数)应用来说,QUIC很可能成为默认传输方式,但这是因为TCP被用到了原本就不适合的场景。接下来看看为什么这么说。
早在1995年Larry和我编写《计算机网络: 一种系统方法》第一版的时候,当我们编写传输协议那一章时,将其命名为"端到端协议[2]"。那时候,互联网上只有两种值得注意的传输协议,UDP和TCP,所以我们分别给它们写了独立的章节。由于那本书旨在教授网络原理而不仅仅是RFC的内容,因此我们将这两个部分框定为两种不同的通信范式: 一个是简单的多路复用服务(以UDP为例),一个是可靠字节流(TCP)。但还有第三种范式,即远程过程调用(Remote Procedure Call[3], RPC),Larry认为有必要介绍这种范式,但并没有真正知名的互联网协议示例实现了该范式。当时我们用来说明RPC的例子现在看来很奇怪,是SunRPC[4]以及Larry当时研究x-kernel[5]时自己写的一个例子。不过现在有许多基于IP的RPC实现,gRPC[6]就是最著名的例子之一。
当大多数网络书籍只涉及TCP和UDP时,为什么我们觉得需要完整的章节来讨论RPC 呢?首先,RPC在当时是分布式系统社区的关键研究领域之一,1984年Nelson和Birrell的论文[7]刺激了一代与RPC相关的项目。在我们看来,可靠字节流并不是RPC的正确抽象。RPC的核心是请求/应答范式。客户端发送一堆参数到服务器,服务器用这些参数做一些计算,然后返回计算结果。是的,可靠字节流可能有助于通过网络正确获得所有参数和结果,但对于RPC来说,还有更多东西。先不考虑通过网络传输序列化参数的问题,RPC实际上并不是传输字节流,而是发送消息并获得对应的响应。有点像数据报文服务(如UDP或IP提供的),但它需要的不仅仅是不可靠的数据报文传递,而是需要处理丢包、无序和重复的消息;需要一个标识符空间来匹配请求和响应;还需要支持消息的分片和重组,以及其他一些需求。可靠字节流可以防止乱序传递,这也是RPC所需要的。这可能是为什么在20世纪八九十年代出现了这么多RPC框架的原因,因为分布式系统需要RPC机制,而标准TCP/IP协议套件没有任何现成的东西。(RFC 1045实际上定义了一种实验性的面向RPC的传输,但从未流行起来。)当时TCP/IP是否会像今天这样占据主导地位也并不明显,因此一些RPC框架(例如DCE)被设计成独立于底层网络协议。
TCP/IP协议栈中缺少对RPC的支持,从而为QUIC奠定了基础。当HTTP在20世纪90年代初出现时,并没有试图解决RPC问题,而是试图解决信息共享问题,但它确实实现了请求/响应语义。HTTP的设计者由于缺乏明显更好的选择,决定在TCP上运行HTTP,由于每个"GET"都使用一个新连接,在早期版本中性能非常差。为了提高性能,引入了对HTTP的各种优化,如流水线(pipelining)、持久化连接以及并行连接,但是TCP的可靠字节流模型从来都不是完美适配HTTP的。随着传输层安全(TLS)的引入,又叠加了一组加密信息的双向交互,HTTP的需求和TCP的支持之间的不匹配变得越来越明显。Jim Roskind在2012年的QUIC设计文档中清晰的解释了这一点,行首阻塞、拥塞响应不佳以及TLS引入的额外RTT都被认为是在TCP上运行HTTP的固有问题。
简单介绍一下这里发生的事情: 互联网的"窄腰(narrow waist)"最初只是IP协议,旨在支持上面的各种协议。但不知何故,"腰"也开始包括TCP和UDP,这两者是唯一可用的传输协议。如果只想要数据报文服务,可以使用UDP。如果需要任何可靠传输,TCP就是答案。如果需要的东西既不能完全映射到不可靠的数据报文,也不能完全映射到可靠的字节流,那么就不走运了。但是,要让TCP支持这么多上层协议,要求就太高了。
QUIC正在做很多工作,其定义跨越三个RFC,涵盖了基本协议(RFC 9000)、TLS的使用(9001[8])和拥塞控制机制(9002[9])。但其核心是互联网缺失的第三种范式: RPC的实现。如果需要真正的可靠字节流(例如下载几个G的操作系统更新时),那么TCP确实是为这项工作而设计的,但是HTTP(S)更像RPC而不是可靠字节流。可以这样理解QUIC,它最终将RPC范式交付给了互联网协议族,而这肯定会使运行在HTTP(S)上的应用程序受益,特别是包括gRPC以及大家广为依赖的RESTful API。
之前的文章[10]提到QUIC时,我们认为这是一个很好的案例研究,可以在需求变得更清晰时重新考虑系统分层,要点是TCP(可靠字节流)满足了一组需求,并且其拥塞控制算法[11]持续演进并为这些需求服务。QUIC实际上满足了一组不同的需求。由于HTTP在今天的互联网处于绝对中心地位(确实有人争论它是否正在成为新的"窄腰"),QUIC可能成为主要传输协议(不是因为取代TCP,而是因为满足了运行其上的主要应用程序的需求)。
你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。
微信公众号:DeepNoMind
参考资料
下一代TCP: https://www.mdnice.com/writing/6c05ab8e49954207a5f583268b6c4e58
[2]端到端协议: https://book.systemsapproach.org/e2e.html
[3]Remote Procedure Call: https://book.systemsapproach.org/e2e/rpc.html
[4]SunRPC: https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call
[5]x-kernel: https://dl.acm.org/doi/10.1145/74850.74860
[6]gRPC: https://grpc.io
[7]Implementing remote procedure calls: https://dl.acm.org/doi/10.1145/2080.357392
[8]RFC 9001: https://datatracker.ietf.org/doc/html/rfc9001
[9]RFC 9002: https://datatracker.ietf.org/doc/html/rfc9002
[10]The Importance of Thinking Across Layer Boundaries: https://systemsapproach.substack.com/p/the-importance-of-thinking-across
[11]TCP拥塞控制: https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU2MTgxODgwNA==&action=getalbum&album_id=2460055314927255553#wechat_redirect文章来源:https://www.uudwc.com/A/jrzmY/
本文由 mdnice 多平台发布文章来源地址https://www.uudwc.com/A/jrzmY/