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
本文由 mdnice 多平台发布
