科普文：详解HTTP3.0协议和QUIC协议

概叙

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

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

HTTP/3 From A To Z: Core Concepts — Smashing Magazine

HTTP/2 and HTTP/3 explained - AlexandreHTRB blog

HTTP协议的演变

我们介绍http协议最基本的2个特点：超文本传输、无状态，它还有许多特性，这些特性不是一蹴而就的，是通过很多年的使用和迭代不断发展而来的，我们一起来回顾一下HTTP协议的发展历程：

版本	推出年份	当前状态
HTTP/0.9	1991年	已过时
HTTP/1.0	1996年	已过时
HTTP/1.1	1997年	标准
HTTP/2.0	2015年	标准
HTTP/3.0	2022年	标准

经过多次优化和性能改进。大多数现代设备使用HTTP 1.1 / HTTP 2.0和HTTP 3.0。让我们回顾一下 HTTP 的历史，了解该协议经历的重大变化。

1. HTTP/0.9 (1991)

   • 最初的HTTP版本，仅支持简单的文本请求，没有HTTP头和持久连接。

2. HTTP/1.0 (1996)

   • 引入了HTTP头，支持请求和响应的多种类型。
   • 每个请求/响应都需要一个新的TCP连接，增加了连接建立和关闭的开销。

3. HTTP/1.1 (1999)

   • 持久连接（Persistent Connections） ：通过Connection: keep-alive头部，允许在一个TCP连接上发送多个请求和响应，减少了连接建立和关闭的频率。
   • 管道化（Pipelining） ：允许客户端在等待第一个响应之前发送多个请求，但服务器必须按顺序响应，这仍然可能导致队头阻塞。
   • 缓存控制：引入了更多的缓存控制机制，如ETags和Last-Modified。
   • 范围请求：支持请求资源的一部分，有助于实现断点续传。

什么是队头阻塞？如上图所示，您有三个文件 - 图像、文本和视频。视频文件较大，传输时间较长。由于视频文件需要更多时间，因此会阻止图像和文本文件的发送。

1. HTTP/2.0 (2015)

   • 二进制协议：采用二进制格式，提高了解析效率。
   • 多路复用：允许在单个TCP连接上并行交错发送多个请求和响应，解决了队头阻塞问题。
   • 头部压缩：减少了请求和响应头部的大小，提高了传输效率。
   • 服务器推送：服务器可以主动向客户端推送资源，减少了客户端请求的轮次。

HTTP 2.0通过多路复用解决了队头阻塞问题。借助多路复用，可以通过同一个TCP连接发送多个文件。

这带来了性能提升，并在应用层解决了队头阻塞问题。然而，在 TCP 层，如果出现数据包丢失，则必须等待数据包重新传输。

在数据包丢失的情况下，多路复用解决方案无法按预期发挥作用。事实上，如果数据包丢失率超过 5%，HTTP 1.1 的性能要优于 HTTP 2.0。线头阻塞问题从应用层转移到了传输层。

快速 UDP 网络连接（QUIC）是一种通用传输层协议，旨在通过其灵活性、内置的安全防护、较少的性能问题以及更快的采用率来取代传输控制协议（TCP）。QUIC 最初由谷歌开发，采用用户数据协议（UDP）作为在客户端和服务器之间移动数据包的低级别传输机制。另外值得注意的是，QUIC 集成了传输层安全防护（TLS），将其作为一个集成组件，而不是像 HTTP/1.1 和 HTTP/2 那样将其作为一个附加层。

​基于 QUIC 的 HTTP/3 是超文本传输协议（HTTP）的第三个主要版本，于 2022 年被采纳为 IETF 标准。创建 QUIC+HTTP/3 是为了解决 TCP 固有的性能限制和用户体验的问题。 ​

早期的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 的局限性

  除了 QUIC 是基于 UDP 实现，HTTP1.1、HTTP2等几种协议都是基于 TCP。TCP 因其面向连接、可靠传输等特点而被广泛采用，但在如今带宽越来越大的网络环境下，TCP 的局限性也制约了 HTTP/2 的性能，主要表现为以下两点。

  (1) 数据传输前 TCP 先要进行“三次握手”，建立连接后才开始传输应用数据，这无疑增加了网络延时; 在采用 TLS 协议时需要交换密钥，这又增加了一次往返时延 (Round-Trip Time，RTT)。

(2) HOL (Head-of-line) blocking，头包阻塞。TCP 保证有序传输，所以当一个数据包丢失时，其他所有的包都要等它重传整理后才会交给应用层，对于多路复用共享一个 TCP 连接的 SPDY 和 HTTP/2 来说，这无疑影响更大。

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

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

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

HTTP3.0

虽然HTTP/2.0相较于HTTP1.x有了巨大的技术革新，自发布以后逐渐占据市场主流，足以证明其优秀；但是俗话说，世界上没有完美的东西，HTTP/2.0也有其不足

启用HTTP/2.0后性能会有较大地提升，解决了HTTP这一层面的队头阻塞问题，但是因为所有传输数据的压力并没有消失，而是转移到底层依赖的一个TCP连接之上，而TCP又是个面向连接、可靠的传输层协议，TCP建立连接时的三次握手还是耗时还是长的，其次TCP依旧存在"队头阻塞"问题

以谷歌为首的大型科技公司并不能满足HTTP/2.0的性能，HTTP/3.0于2022年正式发布！要想进一步提升HTTP的性能，必须要优化其依赖的底层协议。TCP很成熟意味着改造难度很大。谷歌相较于改进TCP协议，更倾向于基于UDP来开发全新一代HTTP协议，HTTP/3.0也叫QUIC协议(Quick UDP Internet Connections)

1. TCP面向连接，可靠，保证数据正确性，保证数据顺序，有队头阻塞问题，成本较高
2. UDP无连接，不可靠，不保证数据正确性(可能丢包)，不保证数据顺序，无队头阻塞问题，成本较低

解决队头阻塞问题

上面我们提到了，HTTP/2.0只解决HTTP这一层面的队头阻塞问题，但是TCP层依旧存在"队头阻塞"问题，这其实并不能怪TCP，它是无辜的，一切都是为了保证传输的可靠性；比如在传输过程中，一旦丢包，会触发TCP重传机制，这个时候一个TCP连接中的其他所有的请求都必须等待，直到丢的包被重传回来；这就会出现因为丢包而阻塞整个连接的请求

QUIC使用UDP来替换TCP，基本上算是重写了HTTP协议，而UDP没有"队头阻塞"问题，QUIC也实现了可靠传输，保证数据一定能够抵达目的地，还引入了类似HTTP/2.0的数据流和多路复用

QUIC协议可以同时运行多个数据流，每个数据流独立互不影响，并为每个流独立实现数据包丢失检测和重传，来保证数据的正确和有序性；当某个数据流丢包时，只会阻塞这个数据流，其他的数据流不会受到影响

缩短建立连接的时间

我们一般用来衡量网络建立连接性能的，常用指标是 RTT(Round-Trip Time)，往返时延，表示从发送端发送数据开始，到发送端收到来自接收端的确认，所经历的时延；通俗点讲就是数据包一来一回的消耗了多少时间

我们知道HTTPS要建立一个连接，需要进行TCP握手和TLS握手，需要3个RTT；如果把第一次握手计算出来的对称密钥缓存起来，那也需要2个RTT。但是QUIC协议，可以做到首次连接只需要1RTT, 后面的连接只需要0RTT

因为QUIC可以让客户端发送给服务端的第一个包就可以包含有效的业务数据，这里使用DH密钥交换算法，重新定义了TLS协议加密QUIC头部的方式，既提高了网络攻击成本，又降低了建立连接的速度

HTTP/3.0重新定义了TLS协议加密QUIC头部的方式，既提高了网络攻击成本，又降低了建立连接的速度。

HTTP3 是 HTTP2 的复用和压缩，协议从 TCP 更改为 UDP。然后，谷歌的那些人在协议中添加了他们做的层，以确保稳定性、数据包接收顺序及安全性。

因此，HTTP3 在保持 QUIC 稳定性的同时使用 UDP 来实现高速度，同时又不会牺牲 TLS 的安全性。是的，在 QUIC 中就有 TLS1.3，你可以用它发起优雅的 SSL。这些层的底层机制是下面这样：

 2018 年，QUIC 演变成为 HTTP3。互联网工程任务组（Internet Engineerring Task Force）的那帮制定互联网协议的哥们同意了这个提案。这是个好消息，因为对于我们这些急躁的人们来说，互联网的速度永远都不够快。

连接迁移

在我们现实生活中，网络的切换是很常见的情况，TCP连接基于四元组(源IP, 源端口, 目的IP, 目的端口), 切换网络时至少会有一个因素(一般是IP)发生变化，就会导致原本的连接异常，这时需要重新创建TCP连接，才能正常传输数据

而QUIC不受四元组的影响, 当这四个元素发生变化时, 原来的连接依旧能够维持稳定；因为使用64位的随机数作为连接的Connection ID，并使用该ID表示连接；举个例子，当我们用手机看视频，这个时候需要出门拿快递，手机的网络会从WIFI自动地切换到4G，全程都不会感觉到视频卡顿，体验感直接拉满

前向纠错

前向纠错FEC是一种在单向通信系统中控制传输错误的技术，通过连同数据发送额外的信息进行错误恢复，以降低比特误码率

因为UDP并不是个可靠协议，QUIC使用前向纠错来增加协议的容错性，一段数据会被拆成多个数据包，传输途中某个包丢失，接收方收到数据包后，可以"校验"发现有丢包情况并通过其他包和FEC，推算出丢失的那个包的数据来"纠错"

HTTP3还有许多有意思的特点，篇幅有限就不展开了，详情见Hypertext Transfer Protocol Version 3 (HTTP/3)

QUIC是如何工作的？

QUIC（Quick UDP Internet Connections）是由Google提出的一种基于UDP改进的低时延的互联网传输层（其实有疑义，QUIC基于UDP，其实更像应用层协议）协议。由Google公司开发，在2012年实现，2013年发布。2014年开始google部署，2015年提交草案至IETF。2018年0.8%的服务器支持QUIC,2018年QUIC在Internet上占据了7%左右的流量。IETF组织正式将QUIC协议命名为HTTP3，QUIC成为下一代HTTP协议标准。

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与TCP/UDP的比较

1. 与TCP的比较：

   • 连接建立：QUIC支持0-RTT握手，可以在单个往返中完成连接建立，而TCP需要三次握手，导致更高的延迟。
   • 队头阻塞：QUIC通过多路复用技术避免了TCP中的队头阻塞问题，允许并行传输多个数据流。
   • 连接迁移：QUIC支持在网络变化时的连接迁移，而TCP在这种情况下通常需要重新建立连接。
   • 拥塞控制和重传：QUIC实现了与TCP相似的拥塞控制和数据包重传机制，但进行了优化以适应QUIC的快速连接特性。

2. 与UDP的比较：

   • 可靠性：QUIC提供了类似于TCP的可靠性保证，包括数据包顺序、重传和流量控制，而UDP是无状态的，不保证数据包的顺序或可靠性。
   • 延迟：QUIC利用UDP的低延迟特性，同时通过0-RTT握手减少了连接建立的延迟。
   • 安全性：QUIC内置了加密和安全特性，类似于TLS，而UDP本身不提供安全性。
   • 多路复用：QUIC支持多路复用，允许在单个连接上并行发送多个数据流，而UDP不支持。

总的来说，QUIC结合了TCP的可靠性和UDP的低延迟特性，同时通过多路复用、快速连接建立和连接迁移等特性，提供了一种更适合现代网络应用的传输协议。QUIC的这些优势使其成为HTTP/3的基础，为Web通信提供了更快、更安全、更可靠的解决方案。

QUIC优点

QUIC复用和改进了HTTP2的典型特征，譬如二进制分帧，多路复用，header压缩等.

具有HTTP2的所有优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥赛控制，减少重新连接；相当于TLS加密。

    QUIC主要目标是减少连接延迟，客户端第一次连接服务器时，QUIC只需要1RTT的延迟就可以建立可靠安全的连接，相对于TCP+TLS的1～3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，再次与服务端建立连接时可以实现0RTT的连接建立延迟。

    QUIC同时复用了HTTP2.0的多路复用（Multiplexing）功能，但由于QUIC基于UDP，避免了HTTP/2的Head-of-Line Bolcking问题。

    QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速部署和更新。

    QUIC 协议非常复杂，因为它做了很多事情：

1）为了实现传输的可靠性，它基本上实现并且改进了整个 TCP 协议的功能，包括序列号，重传，拥塞控制，流量控制等；

2）为了实现传输的安全性，它又彻底重构了 TLS 协议，包括证书压缩，握手消息，0RTT 等。虽然后续可能会采用 TLS1.3 协议，但是事实上是 QUIC 推动了 TLS1.3 的发展；

3）为了实现传输的并发性，它又实现了 HTTP2 的大部分特性，包括多路复用，流量控制等。

1 重传与恢复

  与TCP类似，QUIC每发送一个包后，都会等待回复一个确认包。当丢包率超过协议的纠错阀值，会显示与隐式进行重传。

对于某些重要的数据包，在确认丢失前就会进行重传。这样在网络中会有若干个相同包同时传输，任何一个成功抵达就完成了连接，通过这样降低丢包率。接收方对于关键数据包的多次发送和普通数据包的超时重传，都采用相同的重复包处理机制。

    QUIC在拥塞避免算法上还加入了心跳机包，用于减少丢包率。

    QUIC使用FEC（前向纠错）来恢复数据。

2 安全性

    QUIC对每个散装的UDP包都进行了加密和认证的保护，并且避免使用前向依赖（如CBC模式）的方法，这样每个UDP包可以独立地根据IV进行加密或者认证处理。

    QUIC使用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后再马上协商会话密钥，这样可以保证密钥的前向安全性，之后通信过程还可以实现密钥的更新。接收方收到密钥更新时，需要用新旧两种密钥对数据进行解密，直到成功才会正式使用新密钥。

QUIC采用的加密算法仅需要一个RTT就能实现密钥交换，并且该算法也被用于的TLS1.3协议。这就是Diffie-Hellman密钥交换算法。

 可以看到，客户端和服务端各自保留了自己的私钥a和b，通过交换各自的公钥B和A，以及基底G和很大的质数P，双方就能计算出相等的私钥，这个就是加密传输的对称密钥。

  另外，根据离散对数的不可逆，即使拿到G,P,和质数B，也很难推导出私钥b（同理私钥a），也就保证了计算密钥的安全。

3 0RTT握手过程

    QUIC握手过程需要一次数据交互，0RTT即可以完成握手过程的密钥协商，比TLS相比效率提供了5倍。

    QUIC在握手过程使用Diffie-Hellman算法协商初始密钥，初始化密钥依赖于服务器存储的一组配置参数，该参数会周期性更新。初始密钥协商成果后，服务端会提供一个临时随机数，双方根据这个随机数再生成会话密钥。

1、客户端发起Inchoate client hello

2、服务器返回Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到server config中传给客户端

3、客户端发起client hello，包括客户端公钥信息

此时，双方各自计算出了对称密钥。QUIC的1RTT建连过程结束，平均只耗时100ms以内。

后续发起连接的过程中，一旦客户端缓存或持久化了server config，就可以复用并结合本地生成的私钥进行加密数据传输了，不需要再次握手，从而实现0RTT建立连接。

 4 双级别流量控制

    QUIC是多路复用的，多条stream可以建立在一条connection上，所以QUIC的流量控制不仅基于单个stream，还基于connection。

stream级别的流控能够控制单stream的数据发送情况。另外，接收窗口的收缩取决于最大接收字节的偏移而不是所有已接受字节的总和，它不像tcp流控，不会受到丢失数据的影响。

    connection级别流控算法和stream一致，各项数值是所有stream的总和。

5  拥塞控制

  我们知道TCP有多种拥塞控制算法，当遇到网络拥塞会通过减包等方式来避免网络环境恶化。但是，UDP本身是没有拥塞控制的，一旦不加约束的使用会导致侵占其他“守规矩”的网络协议的带宽。

  所以，为了避免上述情况，基于UDP的QUIC协议借鉴了TCP的一些优秀的拥塞控制算法，如默认使用Cubic，同时，为了避免AIMD机制带来的带宽利用率低，采用了packet pacing来探测网络带宽。

  思路是，QUIC会通过追踪包的到达时间来预测当前带宽的使用情况，以决定是否提高，保持或者减少发送包的速率来避免网络拥塞。

6 丢包恢复

  类似拥塞控制，除了基于TCP的一些丢包恢复机制，如：TLP，FACK。QUIC的丢包恢复也在一些方面做了改进。

  比如：通过引入严格递增的sequence number使得计算RTT更加精确。更精确的RTT也意味更精确的RTO和超时重传机制。

  还比如我们知道TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。

  早期的QUIC版本还有一个丢包恢复机制，就是FEC（Forward Error Correction），这个特性虽然目前处于正在改造阶段（可能会浪费带宽并且作用不是很明显），但是依然是一个有意思的解决方案。

7 更多特性

除了上述的主要特性，QUIC还有一些其他特性，如：

● 通过header stream保证流顺序

● 底层保证连接持久

● 源地址令牌防止地址欺骗

● 握手时压缩证书避免放大攻击

在此不深入研究，大家有兴趣可以翻阅Google相关的文档查阅。

8 业界应用情况

● Google超过50%的请求来自QUIC

● 目前Youtube有20%的流量来自QUIC

● 微博移动端全面支持QUIC协议

 QUIC 网络的基本结构

如图所示，包含 HTTP/3 请求、响应以及所有应用数据的逻辑对象是 QUIC 流。在不同的网络端点之间进行传输时，QUIC 流被封装在多个逻辑层中。

从外向内看，这些逻辑层和对象包括：

• UDP 数据报 – 包含一个指定了源端口和目标端口（以及长度与校验数据）的请求头，后跟一个或多个 QUIC 数据包。数据报是通过网络从客户端向服务器传输的信息的单位。 
• QUIC 数据包 – 包含一个 QUIC 请求头和一个或多个 QUIC 数据帧。
• QUIC 请求头 – 包含关于数据包的元数据。QUIC 请求头有两种： 
  • 长请求头：在建立连接时使用。
  • 短请求头：在连接建立后使用。它包含连接 ID（connection ID）、数据包编号（Package Number）和 key phase（用于跟踪哪些密钥被用于加密数据包，以支持密钥轮换），以及其他数据。对于一个特定的连接和 key phase 来说，其数据包编号是独一无二（并且不断增加）的。
• 数据帧 – 包含类型（type）、数据流 ID（stream ID）、偏移量（offset）和流式数据。流式数据分散在多个数据帧中，但可以使用连接 ID（connection ID）、数据流 ID（stream ID）和偏移量（offset）进行组合，从而以正确的顺序呈现数据块。 
• 数据流 – 单个 QUIC 连接内的单向或双向数据流。每个 QUIC 连接均可支持多个独立的数据流，每个数据流都有自己的数据流 ID（stream ID）。如果某个包含一些数据流的 QUIC 数据包丢失，不在所丢数据包之中的数据流的进度不受影响（这是避免 HTTP/2 队头阻塞问题的关键。）数据流可以是双向的并可以由任意端点创建。 

QUIC与TLS握手的工作原理

TLS 握手提供了客户端和服务器之间的安全连接。QUIC 所提供的加密功能需要使用 TLS v1.3 版本。如下图所示，QUIC 保留了 TLS“内容层（Content Layer）”，它可提供加密密钥；同时，QUIC 用自己的传输机制取代了“记录层（Record Layer）”。

针对那些对安全和性能至关重要的参数，QUIC 还基于 TLS 对其进行身份验证和协商。这两种协议不是严格地分层的，而是互相合作的：QUIC 借助 TLS 握手来建立安全连接，而 TLS 则使用 QUIC 提供的可靠性、有序交付以及记录层。

从较高的层面来说，TLS 和 QUIC 组件之间主要有两种类型的交互：

• TLS 组件通过 QUIC 组件发送和接收消息，QUIC 为 TLS 提供可靠的抽象流。
• TLS 组件为 QUIC 组件提供了一系列更新，包括（a）要安装的新数据包保护密钥和（b）状态更改，如握手完成、服务器证书等。

QUIC TLS 的 HTTP/3 支持选项

QUIC TLS 是专为 QUIC 协议设计的 TLS 变体。目前，对于在 QUIC TLS 中寻求 HTTP/3 支持的用户，​ 有两个选项：

1. OpenSSL 的 QUIC 实现 – OpenSSL目前正在自行实现一个完整的 QUIC 堆栈。这个实现的开发将封装所有 QUIC 功能，使 HTTP/3 用户可以更容易使用 OpenSSL TLS API，而无需担心与 QUIC 特定相关的功能。
2. 支持 BoringSSL QUIC API 的各种库 — 各种 SSL 库，如 BoringSSL、quicTLS 和 LibreSSL（最初是 OpenSSL 的分支），现在已经可以通过实现 BoringSSL 的 QUIC API 来提供 QUIC TLS 功能。这是目前想要使用 HTTP/3 的用户的唯一选择，因为 OpenSSL QUIC TLS 实现还未完善。 ​

QUIC+HTTP/3 的优点

通过减少延迟以及改进不可靠的网络上的数据传输，QUIC+HTTP/3旨在提高 web 应用的性能。它们的优势包括：

• 降低延迟 – 由于连接建立的过程，TCP 等传统协议存在延迟。QUIC+HTTP/3 的多路复用功能使它们能够更有效率地建立连接，从而降低建立连接和传输数据的延迟。
• 更快地连接建立 – QUIC+HTTP/3 将 TLS 握手和加密的建立过程整合到一个步骤中，减少了建立安全连接所需的通信往返次数。
• 多路复用 – 通过在单个连接中处理多个数据流，QUIC+HTTP/3 可以更有效地使用网络资源，并有助于避免队头阻塞问题。然而在传统 TCP 连接中，一个慢速数据流可能会导致其他数据流的延迟。
• 纠错功能改进 – QUIC 结合了前向纠错技术，可以帮助恢复丢失的数据包而无需重新传输，降低了数据包丢失对性能的影响。
• 降低数据包丢失的影响 – UDP 是无连接的，无需像 TCP 那样进行严格的错误检查，借此 UDP 可实现更快的数据传输。这在网络条件不太稳定的情况下尤其有利。
• 自适应的拥塞控制 – QUIC+HTTP/3 的设计比 TCP 的拥塞控制更高效、响应更灵敏，从而可以在各种不同的网络环境中获得更好的性能。
• 迁移支持 – QUIC+HTTP/3 可以在不同的网络连接之间无缝转换（例如，从 Wi-Fi 切换到蜂窝），且不会造成应用性能的波动。
• 增强安全防护 – QUIC+HTTP/3 默认集成了加密功能，增强了数据传输的安全性和隐私性。这种加密可以防止传输中的数据被窃听和篡改。
• NAT 穿透 – QUIC+HTTP/3 对 UDP 的使用有助于网络地址转换（NAT）穿透，使其在传统 TCP 连接可能面临问题的情况下能够更直接地建立连接。
• 持续迭代 – 由于 QUIC+HTTP/3 的设计是其可通过软件来实现和更新，而不需要更改底层网络基础架构，因此它们可以被更快地更新和改进，以适应不断变化的网络条件和安全防护需求。

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 更加多样化和创新的用例出现，从而推动新应用程序和服务的开发。