快速读懂 HTTP/3 协议

在 深刻浅出：HTTP/2 一文中详细介绍了 HTTP/2 新的特性，好比头部压缩、二进制分帧、虚拟的“流”与多路复用，性能方面比 HTTP/1 有了很大的提高。与全部性能优化过程同样，去掉一个性能瓶颈，又会带来新的瓶颈。对HTTP 2.0而言，TCP 极可能就是下一个性能瓶颈。这也是为何服务器端TCP配置对HTTP 2.0相当重要的一个缘由。”

TCP 的限制

HTTP/3功能的核心是围绕着底层的QUIC协议来实现的。在讨论QUIC和UDP以前，咱们有必要先列出TCP的某些限制，这也是致使QUIC发展的缘由。

TCP可能会间歇性地挂起数据传输

若是一个序列号较低的数据段尚未接收到，即便其余序列号较高的段已经接收到，TCP的接收机滑动窗口也不会继续处理。这将致使TCP流瞬间挂起，在更糟糕的状况下，即便全部的段中有一个没有收到，也会致使关闭链接。这个问题被称为TCP流的行头阻塞（HoL）。

 

TCP不支持流级复用

虽然TCP确实容许在应用层之间创建多个逻辑链接，但它不容许在一个TCP流中复用数据包。使用HTTP/2时，浏览器只能与服务器打开一个TCP链接，并使用同一个链接来请求多个对象，如CSS、JavaScript等文件。在接收这些对象的同时，TCP会将全部对象序列化在同一个流中。所以，它不知道TCP段的对象级分区。

TCP会产生冗余通讯

TCP链接握手会有冗余的消息交换序列，即便是与已知主机创建的链接也是如此。

QUIC 协议

这里先贴一下 HTTP/3 的协议栈图，让你对它有个大概的了解。

QUIC协议在如下设计选择的基础上，经过引入一些底层传输机制的改变，解决了这些问题。

• 1）选择UDP做为底层传输层协议：在TCP之上创建新的传输机制，将继承TCP的上述全部缺点。所以，UDP是一个明智的选择。此外，QUIC是在用户层构建的，因此不须要每次协议升级时进行内核修改。

• 2）流复用和流控：QUIC引入了链接上的多路流复用的概念。QUIC经过设计实现了单独的、针对每一个流的流控，解决了整个链接的行头阻塞问题。

 

• 3）灵活的拥塞控制机制：TCP的拥塞控制机制是刚性的。该协议每次检测到拥塞时，都会将拥塞窗口大小减小一半。相比之下，QUIC的拥塞控制设计得更加灵活，能够更有效地利用可用的网络带宽，从而得到更好的吞吐量。

• 4）更好的错误处理能力：QUIC使用加强的丢失恢复机制和转发纠错功能，以更好地处理错误数据包。该功能对于那些只能经过缓慢的无线网络访问互联网的用户来讲是一个福音，由于这些网络用户在传输过程当中常常出现高错误率。

• 5）更快的握手：QUIC使用相同的TLS模块进行安全链接。然而，与TCP不一样的是，QUIC的握手机制通过优化，避免了每次两个已知的对等者之间创建通讯时的冗余协议交换。

经过在QUIC之上构建基于HTTP/3的应用层，您能够得到加强型传输机制的全部优点，同时保留HTTP/2的语法和语义。可是，你也必须注意到，HTTP/2不能直接与QUIC集成，由于从应用到传输的底层帧映射是不兼容的。所以，IETF的HTTP工做组建议将HTTP/3做为新的HTTP版本，并根据QUIC协议的帧格式要求修改了帧映射。

除此以外，HTTP/3还使用了一种新的HTTP头压缩机制，称为QPACK，是对HTTP/2中使用的HPACK的加强。在QPACK下，HTTP头能够在不一样的QUIC流中不按顺序到达。与HTTP/2中的TCP确保数据包的按顺序传递不一样，QUIC流是不按顺序传递的，在不一样的流中可能包含不一样的HTTP头。所以，QPACK使用查找表机制对报头进行编码和解码。

所以想要了解 HTTP/3，QUIC 是绕不过去的，下面主要经过几个重要的特性让你们对 QUIC 有更深的理解。

QUIC 的特色

零 RTT 创建链接

用一张图能够形象地看出 HTTP/2 和 HTTP/3 创建链接的差异。

HTTP/2 的链接须要 3 RTT，若是考虑会话复用，即把第一次握手算出来的对称密钥缓存起来，那么也须要 2 RTT，更进一步的，若是 TLS 升级到 1.3，那么 HTTP/2 链接须要 2 RTT，考虑会话复用则须要 1 RTT。有人会说 HTTP/2 不必定须要 HTTPS，握手过程还能够简化。这没毛病，HTTP/2 的标准的确不须要基于 HTTPS，但实际上全部浏览器的实现都要求 HTTP/2 必须基于 HTTPS，因此 HTTP/2 的加密链接必不可少。而 HTTP/3 首次链接只须要 1 RTT，后面的链接更是只需 0 RTT，意味着客户端发给服务端的第一个包就带有请求数据，这一点 HTTP/2 难以望其项背。那这背后是什么原理呢？咱们具体看下 QUIC 的链接过程。

• Step1：首次链接时，客户端发送 Inchoate Client Hello 给服务端，用于请求链接；

• Step2：服务端生成 g、p、a，根据 g、p 和 a 算出 A，而后将 g、p、A 放到 Server Config 中再发送 Rejection 消息给客户端；

• Step3：客户端接收到 g、p、A 后，本身再生成 b，根据 g、p、b 算出 B，根据 A、p、b 算出初始密钥 K。B 和 K 算好后，客户端会用 K 加密 HTTP 数据，连同 B 一块儿发送给服务端；

• Step4：服务端接收到 B 后，根据 a、p、B 生成与客户端一样的密钥，再用这密钥解密收到的 HTTP 数据。为了进一步的安全（前向安全性），服务端会更新本身的随机数 a 和公钥，再生成新的密钥 S，而后把公钥经过 Server Hello 发送给客户端。连同 Server Hello 消息，还有 HTTP 返回数据；

• Step5：客户端收到 Server Hello 后，生成与服务端一致的新密钥 S，后面的传输都使用 S 加密。

这样，QUIC 从请求链接到正式接发 HTTP 数据一共花了 1 RTT，这 1 个 RTT 主要是为了获取 Server Config，后面的链接若是客户端缓存了 Server Config，那么就能够直接发送 HTTP 数据，实现 0 RTT 创建链接。

这里使用的是 DH 密钥交换算法，DH 算法的核心就是服务端生成 a、g、p 3 个随机数，a 本身持有，g 和 p 要传输给客户端，而客户端会生成 b 这 1 个随机数，经过 DH 算法客户端和服务端能够算出一样的密钥。在这过程当中 a 和 b 并不参与网络传输，安全性大大提升。由于 p 和 g 是大数，因此即便在网络中传输的 p、g、A、B 都被劫持，那么靠如今的计算机算力也无法破解密钥。

链接迁移

TCP 链接基于四元组（源 IP、源端口、目的 IP、目的端口），切换网络时至少会有一个因素发生变化，致使链接发生变化。当链接发生变化时，若是还使用原来的 TCP 链接，则会致使链接失败，就得等原来的链接超时后从新创建链接，因此咱们有时候发现切换到一个新网络时，即便新网络情况良好，但内容仍是须要加载好久。若是实现得好，当检测到网络变化时马上创建新的 TCP 链接，即便这样，创建新的链接仍是须要几百毫秒的时间。

QUIC 的链接不受四元组的影响，当这四个元素发生变化时，原链接依然维持。那这是怎么作到的呢？道理很简单，QUIC 链接不以四元组做为标识，而是使用一个 64 位的随机数，这个随机数被称为 Connection ID，即便 IP 或者端口发生变化，只要 Connection ID 没有变化，那么链接依然能够维持。

队头阻塞/多路复用

HTTP/1.1 和 HTTP/2 都存在队头阻塞问题（Head of line blocking），那什么是队头阻塞呢？

TCP 是个面向链接的协议，即发送请求后须要收到 ACK 消息，以确认对方已接收到数据。若是每次请求都要在收到上次请求的 ACK 消息后再请求，那么效率无疑很低。后来 HTTP/1.1 提出了 Pipelining 技术，容许一个 TCP 链接同时发送多个请求，这样就大大提高了传输效率。

在这个背景下，下面就来谈 HTTP/1.1 的队头阻塞。下图中，一个 TCP 链接同时传输 10 个请求，其中第 一、二、3 个请求已被客户端接收，但第 4 个请求丢失，那么后面第 5 - 10 个请求都被阻塞，须要等第 4 个请求处理完毕才能被处理，这样就浪费了带宽资源。

所以，HTTP 通常又容许每一个主机创建 6 个 TCP 链接，这样能够更加充分地利用带宽资源，但每一个链接中队头阻塞的问题仍是存在。

HTTP/2 的多路复用解决了上述的队头阻塞问题。不像 HTTP/1.1 中只有上一个请求的全部数据包被传输完毕下一个请求的数据包才能够被传输，HTTP/2 中每一个请求都被拆分红多个 Frame 经过一条 TCP 链接同时被传输，这样即便一个请求被阻塞，也不会影响其余的请求。以下图所示，不一样颜色表明不一样的请求，相同颜色的色块表明请求被切分的 Frame。

事情还没完，HTTP/2 虽然能够解决“请求”这个粒度的阻塞，但 HTTP/2 的基础 TCP 协议自己却也存在着队头阻塞的问题。HTTP/2 的每一个请求都会被拆分红多个 Frame，不一样请求的 Frame 组合成 Stream，Stream 是 TCP 上的逻辑传输单元，这样 HTTP/2 就达到了一条链接同时发送多条请求的目标，这就是多路复用的原理。咱们看一个例子，在一条 TCP 链接上同时发送 4 个 Stream，其中 Stream1 已正确送达，Stream2 中的第 3 个 Frame 丢失，TCP 处理数据时有严格的先后顺序，先发送的 Frame 要先被处理，这样就会要求发送方从新发送第 3 个 Frame，Stream3 和 Stream4 虽然已到达但却不能被处理，那么这时整条链接都被阻塞。

不只如此，因为 HTTP/2 必须使用 HTTPS，而 HTTPS 使用的 TLS 协议也存在队头阻塞问题。TLS 基于 Record 组织数据，将一堆数据放在一块儿（即一个 Record）加密，加密完后又拆分红多个 TCP 包传输。通常每一个 Record 16K，包含 12 个 TCP 包，这样若是 12 个 TCP 包中有任何一个包丢失，那么整个 Record 都没法解密。

队头阻塞会致使 HTTP/2 在更容易丢包的弱网络环境下比 HTTP/1.1 更慢！

那 QUIC 是如何解决队头阻塞问题的呢？主要有两点。

• QUIC 的传输单元是 Packet，加密单元也是 Packet，整个加密、传输、解密都基于 Packet，这样就能避免 TLS 的队头阻塞问题；

• QUIC 基于 UDP，UDP 的数据包在接收端没有处理顺序，即便中间丢失一个包，也不会阻塞整条链接，其余的资源会被正常处理。

拥塞控制

拥塞控制的目的是避免过多的数据一会儿涌入网络，致使网络超出最大负荷。QUIC 的拥塞控制与 TCP 相似，并在此基础上作了改进。因此咱们先简单介绍下 TCP 的拥塞控制。

TCP 拥塞控制由 4 个核心算法组成：慢启动、拥塞避免、快速重传和快速恢复，理解了这 4 个算法，对 TCP 的拥塞控制也就有了大概了解。

• 慢启动：发送方向接收方发送 1 个单位的数据，收到对方确认后会发送 2 个单位的数据，而后依次是 4 个、8 个……呈指数级增加，这个过程就是在不断试探网络的拥塞程度，超出阈值则会致使网络拥塞；

• 拥塞避免：指数增加不多是无限的，到达某个限制（慢启动阈值）以后，指数增加变为线性增加；

• 快速重传：发送方每一次发送时都会设置一个超时计时器，超时后即认为丢失，须要重发；

• 快速恢复：在上面快速重传的基础上，发送方从新发送数据时，也会启动一个超时定时器，若是收到确认消息则进入拥塞避免阶段，若是仍然超时，则回到慢启动阶段。

QUIC 从新实现了 TCP 协议的 Cubic 算法进行拥塞控制，并在此基础上作了很多改进。下面介绍一些 QUIC 改进的拥塞控制的特性。

热插拔

TCP 中若是要修改拥塞控制策略，须要在系统层面进行操做。QUIC 修改拥塞控制策略只须要在应用层操做，而且 QUIC 会根据不一样的网络环境、用户来动态选择拥塞控制算法

 

前向纠错 FEC

QUIC 使用前向纠错(FEC，Forward Error Correction)技术增长协议的容错性。一段数据被切分为 10 个包后，依次对每一个包进行异或运算，运算结果会做为 FEC 包与数据包一块儿被传输，若是不幸在传输过程当中有一个数据包丢失，那么就能够根据剩余 9 个包以及 FEC 包推算出丢失的那个包的数据，这样就大大增长了协议的容错性。

这是符合现阶段网络技术的一种方案，现阶段带宽已经不是网络传输的瓶颈，往返时间才是，因此新的网络传输协议能够适当增长数据冗余，减小重传操做。

单调递增的 Packet Number

TCP 为了保证可靠性，使用 Sequence Number 和 ACK 来确认消息是否有序到达，但这样的设计存在缺陷。

超时发生后客户端发起重传，后来接收到了 ACK 确认消息，但由于原始请求和重传请求接收到的 ACK 消息同样，因此客户端就郁闷了，不知道这个 ACK 对应的是原始请求仍是重传请求。若是客户端认为是原始请求的 ACK，但其实是左图的情形，则计算的采样 RTT 偏大；若是客户端认为是重传请求的 ACK，但其实是右图的情形，又会致使采样 RTT 偏小。图中有几个术语，RTO 是指超时重传时间（Retransmission TimeOut），跟咱们熟悉的 RTT（Round Trip Time，往返时间）很长得很像。采样 RTT 会影响 RTO 计算，超时时间的准确把握很重要，长了短了都不合适。

QUIC 解决了上面的歧义问题。与 Sequence Number 不一样的是，Packet Number 严格单调递增，若是 Packet N 丢失了，那么重传时 Packet 的标识不会是 N，而是比 N 大的数字，好比 N + M，这样发送方接收到确认消息时就能方便地知道 ACK 对应的是原始请求仍是重传请求。

ACK Delay

TCP 计算 RTT 时没有考虑接收方接收到数据到发送确认消息之间的延迟，以下图所示，这段延迟即 ACK Delay。QUIC 考虑了这段延迟，使得 RTT 的计算更加准确。

更多的 ACK 块

通常来讲，接收方收到发送方的消息后都应该发送一个 ACK 回复，表示收到了数据。但每收到一个数据就返回一个 ACK 回复太麻烦，因此通常不会当即回复，而是接收到多个数据后再回复，TCP SACK 最多提供 3 个 ACK block。但有些场景下，好比下载，只须要服务器返回数据就好，但按照 TCP 的设计，每收到 3 个数据包就要“礼貌性”地返回一个 ACK。而 QUIC 最多能够捎带 256 个 ACK block。在丢包率比较严重的网络下，更多的 ACK block 能够减小重传量，提高网络效率。

流量控制

TCP 会对每一个 TCP 链接进行流量控制，流量控制的意思是让发送方不要发送太快，要让接收方来得及接收，否则会致使数据溢出而丢失，TCP 的流量控制主要经过滑动窗口来实现的。能够看出，拥塞控制主要是控制发送方的发送策略，但没有考虑到接收方的接收能力，流量控制是对这部分能力的补齐。

QUIC 只须要创建一条链接，在这条链接上同时传输多条 Stream，比如有一条道路，两头分别有一个仓库，道路中有不少车辆运送物资。QUIC 的流量控制有两个级别：链接级别（Connection Level）和 Stream 级别（Stream Level），比如既要控制这条路的总流量，不要一会儿不少车辆涌进来，货物来不及处理，也不能一个车辆一会儿运送不少货物，这样货物也来不及处理。

那 QUIC 是怎么实现流量控制的呢？咱们先看单条 Stream 的流量控制。Stream 还没传输数据时，接收窗口（flow control receive window）就是最大接收窗口（flow control receive window），随着接收方接收到数据后，接收窗口不断缩小。在接收到的数据中，有的数据已被处理，而有的数据还没来得及被处理。以下图所示，蓝色块表示已处理数据，黄色块表示未处理数据，这部分数据的到来，使得 Stream 的接收窗口缩小。

随着数据不断被处理，接收方就有能力处理更多数据。当知足 (flow control receive offset - consumed bytes) < (max receive window / 2) 时，接收方会发送 WINDOW_UPDATE frame 告诉发送方你能够再多发送些数据过来。这时 flow control receive offset 就会偏移，接收窗口增大，发送方能够发送更多数据到接收方。

Stream 级别对防止接收端接收过多数据做用有限，更须要借助 Connection 级别的流量控制。理解了 Stream 流量那么也很好理解 Connection 流控。Stream 中，接收窗口(flow control receive window) = 最大接收窗口(max receive window) - 已接收数据(highest received byte offset) ，而对 Connection 来讲：接收窗口 = Stream1 接收窗口 + Stream2 接收窗口 + ... + StreamN 接收窗口 。

为何HTTP/3很重要？

TCP已经有40多年的历史了。它在1981年经过RFC 793从而标准化。多年来，它经历了屡次更新，是一个很是强大的传输协议，能够支持互联网流量的增加。然而，因为设计上的缘由，TCP历来就不适合处理有损无线环境中的数据传输。在互联网的早期，有线网络将网络中的每一台计算机链接起来。

如今，随着智能手机和便携式设备的数量超过台式机和笔记本电脑的数量，超过50%的互联网流量已经经过无线传输。这种趋势给总体的网络浏览体验带来了问题，其中最重要的是在无线覆盖率不足的状况下，TCP中的行头阻塞（关于TCP在移动网络下的不足，请阅读《5G时代已经到来，TCP/IP老矣，尚能饭否？》）。

Google的一些初步实验证实，QUIC做为Google部分热门服务的底层传输协议，极大地提升了速度和用户体验。部署QUIC做为YouTube视频的底层传输协议，致使YouTube视频流的缓冲率降低了30%，这直接影响了用户的视频观看体验。在显示谷歌搜索结果时，也有相似的改善。

网络条件较差的状况下提高很是明显，这促使谷歌更加积极地完善该协议，并最终向IETF提出标准化。

因为这些早期的试验所带来的全部改进，QUIC已经成为带领万维网走向将来的重要因素。在QUIC的支持下，HTTP从HTTP/2到HTTP/3的改头换面，朝着这个方向合理地迈出了一步。

HTTP/3 的局限性

过渡到HTTP/3不只涉及到应用层的变化，还涉及到底层传输层的变化。所以，与它的前身HTTP/2相比，HTTP/3的采用更具挑战性，由于后者只须要改变应用层。传输层承受着网络中的大量中间层审查。这些中间层，如防火墙、代理、NAT设备等会进行大量的深度数据包检查，以知足其功能需求。所以，新的传输机制的引入对IT基础设施和运维团队来讲有一些影响。

然而，HTTP/3被普遍采用的另外一个问题是，它是基于QUIC的，在UDP上运行。大多数的Web流量，以及IETF定义的知名服务都是在TCP之上运行的。这也是为何长时间运行HTTP/3的UDP会话会被防火墙的默认数据包过滤策略所影响的缘由。

随着IETF正在进行的标准化工做，这些问题最终都会获得解决。此外，考虑到Google在早期QUIC实验所显示的积极结果，人们对HTTP/3的支持是压倒性的，这将最终迫使中间层厂商标准化。

针对受限的IoT设备，HTTP/3因为过于繁琐从而没法采用。许多IoT应用部署的设备的外形尺寸很是小。所以，它们的RAM和CPU功率都是有限的。为了使设备在电池功率、低比特率和有损链接等限制条件下高效运行，必须执行此要求。HTTP/3在现有的UDP之上，以QUIC的形式在传输层处理，增长了HTTP/3在整个协议栈中的占用空间。这使得HTTP/3较为笨重，不适合那些IoT设备。但这种状况不多出现，并且存在专门的协议，这就避免了直接在此类设备上支持HTTP的须要。此外，还有以物联网为核心的协议，如MQTT。 

 

关于 HTTP 系列文章：

• HTTP 概述

• TCP 三次握手和四次挥手图解（有限状态机）

• 从你输入网址，到看到网页——详解中间发生的过程

• 深刻浅出 HTTPS (详解版)

• 漫谈 HTTP 链接

• 漫谈 HTTP 性能优化

• HTTP 报文格式简介

• 深刻浅出：HTTP/2

 

参考文章

网络编程懒人入门(十二)：快速读懂Http/3协议，一篇就够！

透视HTTP协议

HTTP/3 原理实战