浏览器原理 30 # HTTP/3

Posted 2021-07-10 凯小默

说明

浏览器工作原理与实践专栏学习笔记

HTTP/3 出现的背景

1999 年设计的 HTTP/1.1 已经不能满足需求，所以 Google 在 2009 年设计了基于 TCP 的 SPDY，后来 SPDY 的开发组推动 SPDY 成为正式标准，不过最终没能通过。不过 SPDY 的开发组全程参与了 HTTP/2 的制定过程，参考了 SPDY 的很多设计，所以我们一般认为 SPDY 就是 HTTP/2 的前身。无论 SPDY 还是 HTTP/2，都是基于 TCP 的，TCP 与 UDP 相比效率上存在天然的劣势，所以 2013 年 Google 开发了基于 UDP 的名为 QUIC 的传输层协议，QUIC 全称 Quick UDP Internet Connections，希望它能替代 TCP，使得网页传输更加高效。后经提议，互联网工程任务组正式将基于 QUIC 协议的 HTTP （HTTP over QUIC）重命名为 HTTP/3。

在 HTTP/1.1 时代，为了提升并行下载效率，浏览器为每个域名维护了 6 个 TCP 连接；

而采用 HTTP/2 之后，浏览器只需要为每个域名维护 1 个 TCP 持久连接，同时还解决了 HTTP/1.1 队头阻塞的问题。

那么 HTTP/2 到底有什么缺陷？

TCP 的队头阻塞

虽然 HTTP/2 解决了应用层面的队头阻塞问题，不过和 HTTP/1.1 一样，HTTP/2 依然是基于 TCP 协议的，而 TCP 最初就是为了单连接而设计的。

正常情况下的 TCP 传输数据过程

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

TCP 丢包状态

如果有一个数据因为网络故障或者其他原因而丢包了，那么整个 TCP 的连接就会处于暂停状态，需要等待丢失的数据包被重新传输过来。

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

HTTP/2 多路复用 vs HTTP/1.1

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

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

TCP 建立连接的延时

网络延迟又称为 RTT（Round Trip Time）：是反映网络性能的一个重要指标。

从浏览器发送一个数据包到服务器，再从服务器返回数据包到浏览器的整个往返时间称为 RTT。

建立 TCP 连接时，需要花费多少个 RTT 呢？

在传输数据之前，需要花掉 3～4 个 RTT。

浏览器和服务器的物理距离较近，那么 1 个 RTT 的时间可能在 10 毫秒以内，总共要消耗掉 30～40 毫秒。

1. 在建立 TCP 连接的时候，需要和服务器进行三次握手来确认连接成功，需要在消耗完 1.5 个 RTT 之后才能进行数据传输。
2. 如果使用 HTTPS 进行 TLS 连接，（TLS 有两个版本——TLS1.2 和 TLS1.3）每个版本建立连接所花的时间不同，大致是需要 1～2 个 RTT

TCP 协议僵化

能否通过改进 TCP 协议来解决TCP 协议存在队头阻塞和建立连接延迟等缺点？

非常困难。

原因有两个：

1. 中间设备的僵化

中间设备：比如路由器、防火墙、NAT、交换机等。

中间设备僵化：如果客户端升级了 TCP 协议，但是当新协议的数据包经过这些中间设备时，它们可能不理解包的内容，于是这些数据就会被丢弃掉。这就是中间设备僵化，它是阻碍 TCP 更新的一大障碍。

2. 操作系统

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

QUIC 协议

HTTP/3 基于 UDP 实现了类似于 TCP 的多路数据流、传输可靠性等功能，这套功能称为 QUIC 协议。

HTTP/2 和 HTTP/3 协议栈

HTTP/3 中的 QUIC 协议实现的功能：

1. 实现了类似 TCP 的流量控制、传输可靠性的功能
2. 集成了 TLS 加密功能
3. 实现了 HTTP/2 中的多路复用功能
4. 实现了快速握手功能：QUIC 是基于 UDP， 可以实现使用 0-RTT 或者 1-RTT 来建立连接

QUIC 协议的多路复用

和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数据流（如下图）。

HTTP/3 的挑战

1. 从目前的情况来看，服务器和浏览器端都没有对 HTTP/3 提供比较完整的支持。

2.部署 HTTP/3 也存在着非常大的问题。

因为系统内核对 UDP 的优化远远没有达到 TCP 的优化程度，这也是阻碍 QUIC 的一个重要原因。

3.中间设备僵化的问题。

这些设备对 UDP 的优化程度远远低于 TCP，据统计使用 QUIC 协议时，大约有 3%～7% 的丢包率。

拓展

腾讯AlloyTeam：HTTP/3原理与实践