QUIC协议的演进之路

当通过网络传输数据时，一种新的协议QUIC（Quick UDP Internet Connection，快速UDP互联网连接）正在成为FAANG的默认选择。本篇文章描述了QUIC协议是如何克服其他版本HTTP的限制脱颖而出的。

FAANG是美国市场上五大最受欢迎和表现最佳的科技股的首字母缩写，即Facebook、Apple、Amazon、Netflix和Google。

HTTP的演进

HTTP属于应用层传输协议，运行于TCP/IP之上。现在它已成为万维网中数据交换的基础。HTTP包括4个稳定版本：HTTP/0.9、HTTP/1.0、HTTP/1.1 和HTTP/2。HTTP/3于2018年首次提出，目前已获得全球2/3 web浏览器的支持。

HTTP/0.9（1991）

HTTP/0.9是HTTP的第一个版本，用作W3C的底层通信协议。它是一个非常简单的客户端-服务器、请求-响应、使用Telnet的协议，只支持GET命令（作为请求方法）和超文本协议（作为响应类型）。该协议不包含HTTP消息头，且发送响应后，连接会立即断开。

HTTP/1.0（1996）

HTTP/0.9极其简单，且使用非常受限。新的HTTP版本HTTP/1.0引入了很多新特性，使它更加通用。这些新的特性包括：

• 每次HTTP 请求/响应都会重新建立TCP连接
• 添加了对 POST 和 HEAD 方法的支持
• 协议头带有版本号、协议类型、状态码字段
• 响应类型：超文本、脚本、媒体、样式表
• 支持keep-alive连接，但默认情况下它是“关闭”的

HTTP/1.1（1997）

HTTP/1.0的主要缺陷是：它在每次请求响应时都要建立新的TCP连接。这种做法非常耗时，且影响客户端和服务器的性能。HTTP/1.1的出现解决了这一问题：

• 单个TCP连接上可以传送多个HTTP请求和响应
• 添加了对 PUT、DELETE、TRACE、OPTIONS 方法的支持
• 默认持久连接

HTTP/2（2015）

随着流媒体内容的增加，网站也开始变得越来越复杂。为了满足这种需求，HTTP/1.1的功能不断扩展：首次支持多个TCP连接，并试验性地引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。但扩展不可能无止境，最终需要采用一个新的协议，于是HTTP/2出现了，该协议包括如下重大改进：

• 多路复用：这是HTTP/2的一个特性，允许同时通过单个TCP连接发起多重请求-响应消息。每次HTTP请求-响应都被分割成二进制帧，客户端和服务器都以二进制帧为基本单位发送消息（请求和响应）。通过多路复用，客户端无需再等待上一个请求完成就可以发送多重请求。这样，HTTP/2便解决了HTTP队头阻塞（HoL）的问题。如图所示：

• 头部压缩：使用 HPACK 压缩消息头
• 非阻塞下载
• 支持服务器推送
• 采用二进制分帧，不再是纯文本
• 解决了队头阻塞问题

HTTP/3（2018）

通过多路复用，HTTP/2解决了队头阻塞问题。但如果TCP流中出现了丢包，根据TCP的拥塞控制机制，其他数据流就只能等待丢包被重新发送和接收。所以，TCP的队头阻塞问题在HTTP/2中依然存在。

HTTP/3通过使用基于UDP的传输协议QUIC解决了这一问题。

HTTP/3是自HTTP/2之后最新且最主要的HTTP版本。因为HTTP/3本身就是为QUIC协议设计的，所以也被描述为基于QUIC的HTTP/2。HTTP/3的目标是通过使用谷歌的QUIC协议提供快速、可靠安全的网络连接。HTTP/3包括以下特性：

• 使用基于UDP的QUIC作为传输协议
• 解决了TCP队头阻塞问题
• 使用QPACK头部压缩机制
• 提供更快页面加载时间

HTTP/2 VS HTTP/3

下图展示了HTTP/2和HTTP/3两者的对比：

相同点：

HTTP/2 和 HTTP/3 使用相同的语法和语义结构，并且适用于同一请求/响应方法、状态码和协议字段。此外，两者都使用设计相似的头部压缩算法（HPACK 和 QPACK）。

不同点：

QUIC是一种新的多路传输层网络协议标准，建立在 UDP 之上。QUIC的主要目标是通过减少页面加载时间提升用户体验，并提高HTTPS的传输性能。它在本质上是TCP TLS HTTP/2。

设计HTTP/3的目的就是要充分利用 QUIC 的优势。QUIC 协议本身可以处理数据流，所以排除了 TCP 队头阻塞问题。

QUIC 的一些关键特性包括：

• 基于UDP
• 使用没有队头阻塞的连接复用
• 重构TCP的关键机制（连接复用、连接建立、拥塞控制、可靠性），并成为可靠的传输协议

交换数据包

对于典型的QUIC协议，客户端和服务器之间交换了三种类型的数据包，如下图所示：

QUIC连接建立和安全的净荷包

1. 安全的首包

首先，客户端在一个CRYPTO 帧中传输包含TLS 1.3 Client Hello的首包。Client Hello包含不同类型的的扩展项，如目标服务器的SNI（Server Name Indication，服务器名称指示 ）、QUIC 传输参数、压缩证书等，以及客户端支持的压缩方法和不同的加密套件。

如果服务器接受QUIC和TLS 1.3参数，它也会在CRYPTO帧中发送包含对客户端首包确认信息和TLS 1.3 Server Hello的首包信息。Server Hello中包含被服务器接收的加密套件和不同的扩展（如密钥共享、支持的版本等）。在客户端接收到 Server Hello后，会向服务器发送一个ACK确认包。

这三个首包都可能包含一个填充帧，以根据需要增加数据包的大小。

2. 握手包

客户端和服务器之间的首包被交换以后，服务器会发送一个握手数据包，其中包含余下的服务器端消息，如证书、与服务器身份验证相关的加密扩展。客户端会验证这些证书，然后QUIC 握手以客户端发送的握手消息结束。

3. 安全的净荷包

一旦安全的QUIC连接建立，客户端与服务器之间的信息便可以安全传输。

QUIC 0-RTT

为了缩短建立新连接的时间，QUIC采用0-RTT。在这里，如果客户端之前使用1-RTT连接到服务器，则服务器必须存储与流量控制相关的传输参数的副本，如 initial_max_data、initial_max_stream_data_bidi_local 等。

下一次，在QUIC 0-RTT模式中，客户端立即开始与服务器的数据传输，不需要等待握手完成。

然而，0-RTT也有设计上的缺陷：允许重放攻击。

我们为什么要用QUIC？

传统的TCP协议是建立在操作系统层和中间路由模块之上实现的，它的握手阶段信息很容易被这些中间模块篡改而变得不安全。

但QUIC协议是在UDP之上的用户级（如浏览器）中实现的，因此它更加灵活、对用户更友好，并且能够在短时间内支持更多设备。

在 QUIC 中，传输相关的信息被不同的保护层加密，握手包在传输链路上不容易被识别和修改。因此它提供了更安全的网络数据传输。

延伸阅读：

QUIC Version 1 (RFC 9000) 作为标准化版本现已发布

一文看懂WebTransport

QUIC助力Snapchat提升用户体验

新一代直播传输协议SRT

三十年TCP与七年QUIC 谁才是未来？

翻译 / Alex

技术Review / 袁荣喜