面试：老生常谈的http，面向未来的 HTTP/3

前记

续接上文，HTTP/2 的大规模应用，HTTP/1 中存在的一大堆缺陷得到了解决，HTTP/2 的一个核心特性是使用了 多路复用 的技术，通过一个 TCP 连接来发送多个 URL 请求。

多路复用 能充分利用宽带，最大限度规避了TCP的慢启动带来的问题，同时还实现了头部压缩、服务器推送等功能，使得页面资源的传输速度得到了大幅提升。在 HTTP/1.1 的时代，为了提升并行下载效率，浏览器为每个域名维护了6个TCP连接；而采用 HTTP/2 之后，浏览器只需要为每个域名维护1个TCP持久连接，同时还解决了 HTTP/1.1 队头堵塞的问题。

到现在看来，HTTP/2.0 的应用似乎可以完美取代 HTTP/1 了，不过 HTTP/2 依然存在着一些缺陷，于是 HTTP/3 应时代而生。接下来先来看一下 HTTP/2 到底有着怎样的缺陷？

TCP 的队头阻塞

HTTP/1.1 中的TCP队头阻塞

虽然 HTTP/2 解决了应用层面的队头阻塞问题，不过和 HTTP/1.1 一样，HTTP/2依然是基于 TCP协议的，而 TCP 最初就是为了单连接而设计的。接下来，来分析下 HTTP/1.1 协议栈中 TCP 是如何传输数据的，参考如下图：

通过上图你会发现，从一端发送给另外一端的数据会被拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。

不过，如果在数据传输的过程中，有一个数据因为网络故障或者其他原因而丢包了，那么整个 TCP 的连接就会处于暂停状态，需要等待丢失的数据包被重新传输过来。 你可以把 TCP 连接看成是一个按照顺序传输数据的管道，管道中的任意一个数据丢失了，那之后的数据都需要等待该数据的重新传输。为了直观理解，你可以参考下图：

综上所述，我们把 在TCP传输过程中，由于单个数据包的丢失而造成的阻塞称为TCP上的队头阻塞。

HTTP2 中的队头阻塞

我们先来看一下正常情况下 HTTP/2 是怎么传输多路请求的，看下图：

通过该图，我们知道了在 HTTP/2 中，多个请求是跑在一个TCP管道中的，如果其中任意一路数据流出现了丢包的情况，那么就会阻塞该TCP连接中的所有请求。 这不同于HTTP/1.1，使用 HTTP/1.1 时，浏览器为每个域名开启了6个TCP连接，如果其中的1个TCP连接发生了队头阻塞，那么其他的5个连接依然可以继续传输数据。

补充：随着丢包率的增加，HTTP/2 的传输效率也会越来越差。有测试数据表明，当系统达到了 2% 的丢包率时，HTTP/1.1 的传输效率反而比 HTTP/2 表现得更好。

TCP 建立连接的延时

除了 TCP 队头阻塞之外，TCP 的握手过程也是影响传输效率的一个重要因素。

为了搞清楚 TCP 协议建立连接的延迟问题，我们还是先来回顾下网络延迟的概念，这会有助于你对后面内容的理解。网络延迟又称为 RTT（Round Trip Time）。我们把从浏览器发送一个数据包到服务器，再从服务器返回数据包到浏览器的整个往返时间称为 RTT（如下图）。 RTT 是反映网络性能的一个重要指标。

HTTP/1 和 HTTP/2 都是使用 TCP 协议来传输的，而如果使用 HTTPS 的话，还需要使用 TLS 协议进行安全传输，而使用 TLS 也需要一个握手过程，这样就需要有两个握手延迟过程。

总之，在传输数据之前，我们需要花掉 3～4 个 RTT。如果浏览器和服务器的物理距离较近，那么 1 个 RTT 的时间可能在 10 毫秒以内，也就是说总共要消耗掉 30～40 毫秒。这个时间也许用户还可以接受，但如果服务器相隔较远，那么 1 个 RTT 就可能需要 100 毫秒以上了，这种情况下整个握手过程需要 300～400 毫秒，这时用户就能明显地感受到"慢"了。

TCP 协议僵化

既然 TCP协议存在着上面的一系列的问题，那我们可以不可以从根源上解决问题：改进 TCP协议？

答案：非常的困难：
- 中间设备的僵化
- TCP 协议都是通过操作系统内核来实现的，应用程序只能使用不能修改。通常操作系统的更新都滞后于软件的更新，因此要想自由地更新内核中的 TCP 协议也是非常困难的。

HTTP/3 的诞生 ------ QUIC协议

HTTP/3 选择了一个折中的方法------UDP 协议，基于 UDP 实现了类似于 TCP 的多路数据流、传输可靠性等功能，我们把这套功能称为 QUIC 协议。关于 HTTP/2 和 HTTP/3 协议栈的比较，你可以参考下图：

HTTP/3 中的 QUIC 协议集合了以下几点功能：

实现了类似 TCP 的流量控制、传输可靠性的功能。 虽然 UDP 不提供可靠性的传输，但 QUIC 在 UDP 的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些 TCP 中存在的特性。
集成了 TLS 加密功能。 目前 QUIC 使用的是 TLS1.3，相较于早期版本 TLS1.3 有更多的优点，其中最重要的一点是减少了握手所花费的 RTT 个数。
实现了 HTTP/2 中的多路复用功能。 和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数据流（如下图）。实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。

实现了快速握手功能。 由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现使用 0-RTT 或者 1-RTT 来建立连接，这意味着 QUIC 可以用最快的速度来发送和接收数据，这样可以大大提升首次打开页面的速度。

总结

HTTP/3 正是基于 QUIC 协议的，你可以把 QUIC 看成是集成了"TCP+HTTP/2 的多路复用 +TLS 等功能"的一套协议。这是集众家所长的一个协议，从协议最底层对 Web 的文件传输做了比较彻底的优化，所以等生态相对成熟时，可以用来打造比现在的 HTTP/2 还更加高效的网络。

参考文章 ： HTTP/3：甩掉TCP、TLS 的包袱，构建高效网络