QUIC是如何工作的？为什么HTTP/3要选择QUIC协议？

在 QUIC发布之前，HTTP 使用 TCP 作为传输数据的底层协议。随着移动互联网的不断发展，人们对实时交互和多样化网络场景的需求越来越大。然而，已经使用了40多年的传统TCP协议，在目前大规模远距离、移动网络差、网络切换频繁的背景下，存在着先天的性能瓶颈。

其实QUIC并不是一个新的协议，2012 年，Google 就设计出了QUIC协议，在浏览器以及服务器端服务上部署并实现。2021 年 5 月， IETF在RFC 9000中对 QUIC 进行了标准化。2022 年 6 月 7 日，HTTP/3 被标准化为 RFC 9114。

HTTP协议的演变

早期的HTTP/1

20 世纪 90 年代初的 HTTP/1.0 是基于 TCP 的严格使用：对于每个 TCP 连接，只有一个 HTTP对话、一个请求和一个响应。如果浏览器需要来自Web服务器的图片，则必须建立TCP连接，并且一旦图片传输完成，就要关闭TCP连接。

单次发送一个请求，收到响应后再发送下一次请求的方式是十分低效的，于是HTTP/1.1提出了管线化(pipelining)技术。把多个HTTP请求放到一个TCP 连接中一一发送，在发送过程中不需要等待服务器对前一个请求的响应。只不过，服务器还是要按照发送请求的顺序来处理请求，客户端也要按照发送请求的顺序来接收响应。与此同时，Netscape 创建了 HTTPS(HTTP Secure)，SSL 逐渐成为浏览 Internet 的标准。

服务器在顺序处理请求的过程中，如果前一个请求处理非常耗时，就会阻塞后面请求的处理，这就是队头阻塞。

| TCP 队头阻塞

HTTP/2 解决问题

2015 年，为了解决队头阻塞问题，HTTP/2 诞生了，这是一项由 Google 推动、基于 SPDY 的倡议。HTTP/2 引入了两个主要功能：多路复用和服务器推送。

多路复用允许通过单个 TCP 上连接同步发送/接收多个逻辑、优先的 HTTP 数据流，而不是添加并行的 TCP 连接。服务器推送(Server Push)使服务器能够预测资源，并在客户端发出请求之前“抢先”推送资源，客户端保留拒绝服务器推送的权限。在多数情况下，这些功能可以大大提高流程的效率。

| 服务器推送

从 HTTP/2 到基于 QUIC 的 HTTP/3

HTTP/2 被采用后，通过多路复用在应用层面解决了“队头阻塞”问题，但在传输层面 (TCP) 上还面临着同样的难题。

在 TCP 中，如果单个数据包被丢弃或丢失，整个 TCP 连接及其上运行的所有 HTTP 数据流都会停止，直到丢失的数据包重新传输并到达目的地。这是深深根植于 TCP 的基本特征，旨在保证无流且可靠的数据传输：面向连接、丢包恢复、重传、窗口缩放、拥塞控制。

QUIC选择 UDP 作为其传输协议，可以避免复杂的部署。大多数防火墙、NAT、路由器以及用户和服务器之间的其他中间设备仅支持 TCP 或 UDP协议。

QUIC是如何工作的？

QUIC 协议位于 UDP 和 HTTP 之间，是一种端到端传输协议的实现。从某方面来说，QUIC = HTTP/2 + TLS + UDP，而UDP + QUIC = 传输层。

| OSI 堆栈上的 QUIC

与 TCP 相比，UDP具有更低的延迟和更高的吞吐量，并且它还使 QUIC 能够绕过可能干扰 TCP 的网络中间件。QUIC 包含基于 TLS 1.3 的内置加密协议，可在端点之间提供安全通信，并使第三方更难拦截和操纵互联网流量。QUIC结合了 UDP 的速度和效率、TLS 的安全性，以及TCP 的流完整性和流量控制功能，增加了更灵活的多流处理版本，还增加了对地址敏捷性的更好支持，以支持各种NAT地址转换行为。

QUIC的主要改进

QUIC的出现解决了最后一公里的网络传输问题。以下是 QUIC 的主要改进：

快速握手和连接建立

无论是HTTP1.0/1.1还是HTTPS、HTTP2，都是使用TCP协议进行传输。HTTPS 和 HTTP2 也需要使用 TLS 协议进行安全传输。TCP 三次握手导致了建立 TCP 连接的延迟。

完整的 TLS 握手至少需要 2 个 RTT 才能建立，而简化的握手需要 1 个 RTT 握手延迟。

对于很多短连接场景，这种握手延迟影响很大，无法消除。

# QUIC协议在以下两个方面进行了优化

1.传输层使用UDP，减少了TCP三次握手中一个1-RTT的延迟。

2.采用最新版本的 TLS 协议——TLS 1.3，允许客户端在 TLS 握手完成之前发送应用数据，同时支持 1-RTT 和 0-RTT。使用 QUIC 协议，第一次握手协商需要 1-RTT，但之前连接的客户端可以使用缓存信息恢复 TLS 连接，只需 0-1 RTT。

| 0-RTT连接建立

经过身份验证和加密的数据包

传统的TCP协议数据包头没有加密和认证，容易被中间人篡改、注入和窃听。相比之下，除了 PUBLIC_RESET 和 CHLO 等少数消息外，QUIC 所有的数据包头都经过身份验证，所有消息体都经过加密。这样数据包的任何修改都能被接收端及时发现，可有效降低安全风险。

如下图，紫色部分为Stream Frame包的认证头，黄色部分为加密后的内容：

| QUIC协议的加密

改进多路复用以避免 HoL 阻塞

QUIC 引入了在连接上复用多个流的概念，通过为每个流设计和实现单独的流量控制，解决了影响整个连接的队头阻塞问题。

QUIC 的多路复用类似于 HTTP/2，可以在单个 QUIC 连接上同时发送多个 HTTP 请求（流）。但是，与HTTP/2 多路复用不同的是，QUIC的流与流之间完全隔离的，互相没有顺序依赖。这意味着如果流 2 丢失了一个 UDP 数据包，它只会影响流 2 的处理，不会阻塞流 1 和 3 的数据传输。因此，该解决方案不会导致队头阻塞问题。

| QUIC 的多路复用

此外，QPACK 作为 QUIC 的一项新功能，旨在减少通过网络传输的冗余数据量，从而有助于缓解队头阻塞。这样QUIC在弱网场景下可以接收到比TCP更多的数据。

可插拔拥塞控制

QUIC支持可插拔的Cubic、BBR、Reno等拥塞控制算法，也可以根据具体场景定制私有算法。“可插拔”意味着它可以灵活地生效、更改和停止，可体现在以下几个方面：

不同的拥塞控制算法可以在应用层实现，不需要操作系统或内核的支持，而传统的TCP拥塞控制需要端到端的网络协议栈才能达到控制效果。

允许单个应用程序的不同连接支持不同的拥塞控制配置。

应用程序无需停机或升级即可更改拥塞控制，唯一要做的就是修改配置并在服务器端重新加载它。

连接迁移

TCP 连接基于 4 元组：源 IP、源端口、目标 IP 和目标端口。如果其中任何一个发生变化，则必须重新建立连接。但是QUIC连接是基于一个64位的Connection ID，只要Connection ID不变就可以保持连接，不会断线重连。

| QUIC 连接

例如，如果客户端使用IP1发送数据包1和2，然后切换网络，更改为IP2并发送数据包3和4，服务器可以根据数据包中的Connection ID字段识别所有四个数据包来自同一个客户端标头。QUIC能够实现连接迁移的根本原因是底层UDP协议是无连接的。

前向纠错

QUIC还支持前向纠错（FEC），弱网丢包环境下，动态的增加一些FEC数据包，可以减少重传次数，提升传输效率。

HTTP/3和QUIC的更多应用

实时应用

HTTP/3 和 QUIC 非常适合需要低延迟、高吞吐量连接的实时应用程序。这包括视频会议、在线游戏和实时流媒体等应用程序。基于QUIC更强的抗不良网络能力和连接迁移能力，可以有效改善视频启动时间，降低视频卡顿率和请求失败率。

物联网

物联网场景下，终端设备使用场景复杂、混乱，如高速移动、海上、山区等环境，设备可用的网络资源非常有限。基于 TCP 的MQTT物联网通信协议经常会在重连过程中出现频繁的连接中断和较大的服务器/客户端开销，而QUIC的0RTT重连/1RTT建立能力和复用特性的优势在恶劣和不稳定的网络中得到体现，可以提高内容传输效率，提升用户体验。

电子商务与金融支付

在电子商务中，QUIC 提供的可靠性和速度有助于确保客户即使在流量高峰期也能获得无缝顺畅的购物体验。此外，QUIC 还提供必要的性能和安全功能来支持电子商务应用程序，例如快速页面加载时间和安全支付交易。

QUIC 协议下一步是什么？

由于 QUIC 是基于 UDP 而不是 TCP，因此将 HTTP/2 升级到 HTTP/3-QUIC 不像从 HTTP/1.1 升级到 HTTP/2 那样简单。HTTP/3 可能会通过外部服务提供商提供给大多数用户，而不是由用户自己在其服务器上实现。

目前，QUIC 的部署正在全球范围内加速推进。随着QUIC IETF-v1协议标准的出现，越来越多的网站开始使用QUIC流量。据W3Techs统计，目前约有25.5%的网站使用HTTP/3。随着技术的不断发展和成熟，我们可以期待看到关于QUIC 更加多样化和创新的用例出现，从而推动新应用程序和服务的开发。






审核编辑：刘清