HTTP/2：让网络飞起来

陆业聪

发布于 2024-08-08 12:08:34

1180

发布于 2024-08-08 12:08:34

文章被收录于专栏：大前端修炼手册

今天我们来聊聊一个让网络飞起来的技术——HTTP/2。你可能已经听说过 HTTP/2，但是你知道它是什么吗？为什么我们需要它？它和我们正在使用的 HTTP/1.1 有什么区别？别急，接下来我们将一一揭晓。

一、HTTP/2 的基本概念和背景

HTTP/2，全名是 Hypertext Transfer Protocol Version 2，是 HTTP 协议的最新版本。它的起源可以追溯到 Google 的 SPDY 项目，该项目的目的是解决 HTTP/1.1 的一些性能问题。HTTP/2 继承了 SPDY 的许多优点，并在此基础上进行了进一步的改进。

那么，为什么我们需要 HTTP/2 呢？这是因为 HTTP/1.1 虽然经过了多年的使用和改进，但仍然存在一些问题，如头部冗余、无法并行处理请求等。HTTP/2 正是为了解决这些问题，提高网络性能而诞生的。

二、HTTP/2 的主要特性和优势

HTTP/2 引入了许多新的特性，如二进制帧、多路复用、头部压缩、服务器推送等，这些都让 HTTP/2 比 HTTP/1.1 更强大。

2.1 二进制帧

在 HTTP/2 中，所有的通信都是通过二进制帧进行的。每个帧都由一个小的固定大小的头部和一个可选的负载组成。头部包括帧的长度、类型、标志以及帧关联的流的标识符。每个帧的结构如下：

+-----------------+-----------------+-----------------+
| Frame Length    | Frame Type      | Flags           |
+-----------------+-----------------+-----------------+
| Stream Identifier (Associated Stream)              |
+-----------------+-----------------+-----------------+
| Optional Payload                                  
+---------------------------------------------------+

Frame Length：帧的长度。
Frame Type：帧的类型。
Flags：帧的标志。
Stream Identifier：帧关联的流的标识符。
Optional Payload：可选的负载。

这种二进制帧的结构使得协议的解析、实现和解耦变得更加容易。而且，由于帧的头部固定，可以减少不必要的网络开销。

2.2 多路复用

多路复用是 HTTP/2 中的一种关键特性。在 HTTP/1.1 中，如果要并行发送多个请求，需要创建多个 TCP 连接，这会消耗大量的资源。而在 HTTP/2 中，多个请求和响应可以在同一个连接上并行传输。这是通过将每个请求或响应分割成多个帧，然后在同一个连接上交错发送这些帧来实现的。每个帧都关联一个流，流的标识符用于区分不同的请求或响应。这种机制大大提高了网络的利用率。

以下是一个简单的示意图，描述了HTTP/2 中帧、流、流的标识符、请求或响应的关系：

+-------------------------------------------------+
| TCP Connection                                  |
|                                                 |
| +------------------+ +------------------+       |
| | Stream 1        | | Stream 2        |  ...  |
| | (Request/Response A) | (Request/Response B) |       |
| | +------+ +------+ | +------+ +------+ |       |
| | |Frame1| |Frame2| | |Frame1| |Frame2| |       |
| | +------+ +------+ | +------+ +------+ |       |
| +------------------+ +------------------+       |
+-------------------------------------------------+

在这个图中，每个 TCP 连接上可以有多个流（Stream 1，Stream 2，...），每个流对应一个请求或响应（Request/Response A，Request/Response B）。每个请求或响应又被分割成多个帧（Frame 1，Frame 2），这些帧交错在同一个连接上发送。

2.3 头部压缩

在 HTTP/1.1 中，每个请求和响应都会发送大量的头部信息，这会占用大量的带宽。HTTP/2 通过引入 HPACK 压缩格式，有效地解决了这个问题。HPACK 使用两个主要的技术来压缩头部：一是静态哈夫曼编码，用于压缩单个头部字段；二是动态表，用于在整个连接过程中缓存和复用之前发送的头部字段。这种机制大大减少了头部的大小，从而节省了带宽。

静态哈夫曼编码：哈夫曼编码是一种无损压缩算法，基于字符出现的概率为每个字符分配一个变长的二进制编码。出现频率较高的字符分配较短的编码，而出现频率较低的字符分配较长的编码。在 HPACK 中，静态哈夫曼编码用于压缩单个头部字段。HTTP/2 规定了一个预先计算好的哈夫曼编码表，该表基于对许多 HTTP 消息头部的统计分析而生成。在压缩过程中，对于每个头部字段的字符，查找哈夫曼编码表并替换为对应的编码。在解压缩过程中，使用相同的哈夫曼编码表将编码还原为原始字符。
动态表：动态表是一种在整个连接过程中缓存和复用之前发送的头部字段的机制。动态表在客户端和服务器之间维护，初始为空。当发送一个头部字段时，首先检查该字段是否已经存在于动态表中。如果存在，则发送一个索引值，表示在动态表中的位置；如果不存在，则将此字段添加到动态表中，并发送原始字段。动态表的大小有限，当表满时，最早添加的字段将被删除以腾出空间。通过动态表，HPACK 可以避免发送重复的头部字段，从而减少带宽消耗。

结合静态哈夫曼编码和动态表，HPACK 可以有效地压缩 HTTP/2 头部数据。静态哈夫曼编码负责压缩单个头部字段，而动态表负责在整个连接过程中复用已发送的头部字段，共同实现了高效的头部压缩。

2.4 服务器推送

服务器推送允许服务器未经客户端请求就发送资源。这是通过服务器发送一个 PUSH_PROMISE 帧来实现的，该帧包含了服务器将要发送的资源的头部字段。然后，服务器可以开始发送这个资源的数据帧，就好像这个资源是由客户端请求的一样。这种机制可以使得客户端更早地获取到资源，从而提高页面的加载速度。

这个时序图描述了服务器推送的过程：

服务器发送一个包含资源头部字段的 PUSH_PROMISE 帧给客户端。
服务器开始发送该资源的数据帧给客户端，就像这个资源是由客户端请求的一样。
客户端接收并处理服务器推送的资源数据。

通过这个机制，客户端可以更早地获取到资源，从而提高页面的加载速度。

三、HTTP/2 的实现和部署

那么，如何在服务器和客户端实现 HTTP/2 呢？其实大多数现代的 web 服务器和浏览器都已经支持 HTTP/2。你只需要更新你的 web 服务器和浏览器到最新版本，就可以使用 HTTP/2 了。

部署 HTTP/2 也很简单。由于 HTTP/2 完全兼容 HTTP/1.1，你不需要修改任何应用代码，只需要在你的 web 服务器上启用 HTTP/2 即可。

四、HTTP/2 与现有技术的比较

当我们谈论 HTTP/2 时，我们经常会把它和 HTTP/1.1、SPDY、QUIC 等其他网络传输协议进行比较。

相比 HTTP/1.1，HTTP/2 的性能有了显著的提升，如我们前面所说的二进制帧、多路复用、头部压缩、服务器推送等。

相比 SPDY，HTTP/2 在其基础上进行了进一步的改进，如引入了二进制帧，改进了头部压缩算法等。

相比 QUIC，HTTP/2 更加稳定和成熟，而 QUIC 还在实验阶段，但 QUIC 有一些更先进的特性，如基于 UDP 的传输，我们可以期待其未来的发展。

五、HTTP/2 与 Web 性能优化

最后，我们来谈谈 HTTP/2 如何影响现有的 Web 性能优化策略。

在 HTTP/1.1 的时代，我们有很多优化策略，如文件合并、图片雪碧图、域名分片等，这些都是为了解决 HTTP/1.1 的限制。但在 HTTP/2 中，这些优化策略可能就不再需要了，甚至可能会适得其反。

文件合并：在 HTTP/2 中，由于支持多路复用，我们不再需要将多个文件合并为一个文件，以减少请求次数。反而，保持文件的独立，可以让浏览器更好地进行缓存和并行处理。
图片雪碧图：在 HTTP/2 中，由于支持多路复用，我们不再需要将多个图片合并为一个雪碧图，以减少请求次数。反而，保持图片的独立，可以让浏览器更好地进行缓存和并行处理。
域名分片：在 HTTP/2 中，由于支持多路复用，我们不再需要将资源分散到多个域名，以增加并行连接数。反而，使用一个域名，可以让浏览器更好地进行连接复用。

因此，我们在 HTTP/2 下，需要重新思考我们的 Web 性能优化策略，以充分利用 HTTP/2 的特性。