QUIC 不是 TCP 的替代品

QUIC 取代了 TCP 成为 HTTP3 的基础传输协议，不是因为 QUIC 能够取代 TCP 的所有应用场景，而是因为 QUIC 更适合 HTTP 的请求/响应业务模型。原文: QUIC Is Not a TCP Replacement

TCP 新规范(RFC 9293)的发布是网络界的一件大事，值得围绕这一主题发表第二篇文章(第一篇: 下一代TCP)，本文我们将围绕 QUIC 和 TCP 的比较展开。

我们在上一篇关于 TCP 的过去和未来的文章中，谈到了 QUIC 可能取代 TCP 的可能性。本文我们想说的是，实际上 QUIC 解决的问题与 TCP 解决的问题有所不同，因此不应该被视为 TCP 的替代品。对于某些(甚至大多数)应用来说，QUIC 很可能成为默认传输方式，但这是因为 TCP 被用到了原本就不适合的场景。接下来看看为什么这么说。

早在 1995 年 Larry 和我编写《计算机网络: 一种系统方法》第一版的时候，当我们编写传输协议那一章时，将其命名为"端到端协议"。那时候，互联网上只有两种值得注意的传输协议，UDP 和 TCP，所以我们分别给它们写了独立的章节。由于那本书旨在教授网络原理而不仅仅是 RFC 的内容，因此我们将这两个部分框定为两种不同的通信范式: 一个是简单的多路复用服务(以 UDP 为例)，一个是可靠字节流(TCP)。但还有第三种范式，即远程过程调用(Remote Procedure Call, RPC)，Larry 认为有必要介绍这种范式，但并没有真正知名的互联网协议示例实现了该范式。当时我们用来说明 RPC 的例子现在看来很奇怪，是SunRPC以及 Larry 当时研究x-kernel时自己写的一个例子。不过现在有许多基于 IP 的 RPC 实现，gRPC就是最著名的例子之一。

当大多数网络书籍只涉及 TCP 和 UDP 时，为什么我们觉得需要完整的章节来讨论 RPC 呢？首先，RPC 在当时是分布式系统社区的关键研究领域之一，1984年Nelson和Birrell的论文刺激了一代与 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)和拥塞控制机制(9002)。但其核心是互联网缺失的第三种范式: RPC 的实现。如果需要真正的可靠字节流(例如下载几个 G 的操作系统更新时)，那么 TCP 确实是为这项工作而设计的，但是 HTTP(S)更像 RPC 而不是可靠字节流。可以这样理解 QUIC，它最终将 RPC 范式交付给了互联网协议族，而这肯定会使运行在 HTTP(S)上的应用程序受益，特别是包括 gRPC 以及大家广为依赖的RESTful API。

之前的文章提到 QUIC 时，我们认为这是一个很好的案例研究，可以在需求变得更清晰时重新考虑系统分层，要点是 TCP(可靠字节流)满足了一组需求，并且其拥塞控制算法持续演进并为这些需求服务。QUIC 实际上满足了一组不同的需求。由于 HTTP 在今天的互联网处于绝对中心地位(确实有人争论它是否正在成为新的"窄腰")，QUIC 可能成为主要传输协议(不是因为取代 TCP，而是因为满足了运行其上的主要应用程序的需求)。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind