NGINX中的HTTP/2模块

Valentin Bartenev

本博文改编自演讲，该演讲由Valentin V. Bartenev于9月在旧金山举行的nginx.conf 2015大会上发表。

目录

几天前，我们发布了NGINX的HTTP/2模块。本次演讲将简要介绍这一新模块。

0:20 协议概述

首先，我想澄清一些关于新协议的误解。

许多人认为，HTTP/2是HTTP/1更先进、更出色的后继者。我并不认同这一观点，原因如下。实际上，HTTP/2只是HTTP/1的另一种传输层。这并非坏事，因为您无需更改应用程序即可使用HTTP/2，它使用相同的标头。只需在NGINX中启用HTTP/2，NGINX就会妥善处理所有协议相关事务。

但HTTP/2并非万能。它确实有优点，也有缺点。在某些用例中表现良好，但在另一些场景中表现不佳。

1:40 HTTP/2 的主要特性

可以将HTTP/2视为SPDY的新版本，因为它以SPDY为基础，两者的协议非常相似。SPDY是Google几年前开发的一种协议，旨在加快Web内容交付。

NGINX支持SPDY已有两年，因此可以使用SPDY模块来了解HTTP/2的优势。有人认为，HTTP/2只是SPDY 3.1的改进版。

如果您不熟悉SPDY，下面将介绍几个要点。这些要点也适用于HTTP/2，因为两者基本上是同一种协议，只是在细节上有所不同。

第一个要点是，该协议本身采用二进制格式。我喜欢二进制协议，因为它们更易于编码，而且设计良好的二进制协议在性能方面具有一定优势。不过，我也了解这种方式的缺点。

3:08 HTTP/2 内部机制：二进制

这是一个HTTP/2请求。看起来很酷，而且如您所见，调试起来非常容易。开个玩笑，其实它很难调试。这正是二进制协议的缺点之一。

您可能需要使用工具来解码请求。不过，有时工具可能会出故障，或者无法显示隐藏在各个位中的所有细节，因此可能需要手动调试二进制数据。

好在大多数情况下，只需在NGINX中使用HTTP/2，完全不必理会其二进制特性。另一个好消息是，大多数请求都将由机器处理，而机器读取二进制协议的能力远胜于人类。

4:26 深入了解HTTP/2：多路复用

HTTP/2的下一个要点是多路复用。HTTP/2不再通过多个连接，以独立数据流的形式发送和接收响应与请求，而是将它们复用到同一个字节流或数据流中。它会将不同请求和响应的数据分割成片段，每个片段都有自己的标识和大小字段，以便端点确定数据属于哪个请求。

这里的缺点是，每个数据块都有自己的标识和字段，因此除了实际数据外，还需要传输一些元数据，从而产生一定的额外开销。因此，如果只有一个数据流，例如观看电影时，HTTP/2就不是合适的协议，因为它只会增加额外开销。

多路复用有哪些优势？其主要优势在于，只需使用一个连接，就能省去使用HTTP/1.x创建新请求时握手所需的全部时间。

处理TLS时，此类延迟尤其令人头疼。因此，目前大多数客户端仅支持通过TLS使用HTTP/2。据我所知，目前没有计划支持通过纯TCP使用HTTP/2，因为这样做的收益不大。这是因为TCP握手的开销不如TLS握手高，所以避免建立多个连接并不能节省多少时间。

7:09 HTTP/2的主要功能：标头压缩

HTTP/2的下一个要点是标头压缩。如果Cookie很大，每个请求或响应可因此减少数百字节，但通常在大多数情况下，标头压缩带来的收益并不明显。因为即使单独考虑每个请求，最终仍需通过网络的数据包层传输。发送100字节还是150字节并没有太大区别，最终仍会形成一个数据包。

HTTP/2标头压缩的缺点是它具有状态［编者：指用于存储压缩和解压缩信息的表］。因此，对于每个连接，服务器和客户端都需要保留某种状态，这比保留HTTP/1连接的状态占用更多内存。因此，每个HTTP/2连接都会占用更多内存。

8:40 HTTP/2的主要功能：优先级

HTTP/2的最后一个要点是其优先级机制。该机制解决了多路复用带来的问题。当只有一个连接时，也就只有一条传输通道，因此需要谨慎决定接下来通过这条通道发送哪个响应。

优先级机制在HTTP/2中是可选的，但如果不使用，性能提升会很有限。NGINX中的HTTP/2模块全面支持优先级机制，包括基于权重和基于依赖关系的优先级。根据目前的观察，我们当前的HTTP/2实现速度表现出色。以上就是HTTP/2的要点。

10:06 HTTP/2的发展历程

这张简单的幻灯片回顾了HTTP/2的发展历程，内容比较直观。接下来，我们来看看HTTP/2在实践中如何运作。

10:16 测试页面

为了了解HTTP/2在不同网络条件下的运行情况，我对一个典型网页进行了一些基准测试。这只是我在Github上找到的一个HTTP/2页面。可以看到其中包含的资源数量以及每项资源的大小。我认为它相当具有典型网站的代表性。

10:52 测试环境

以下是我的测试环境，供您复现测试时参考。

11:02 DOM 加载

以下是我得到的结果。可以看到，X轴表示模拟的不同网络延迟，以往返时间（RTT）计，单位为毫秒；Y轴表示测得的下载时间，单位同样为毫秒。本测试以页面所有资源完全加载所需的时间来衡量页面加载时间。

从图中可以看出一个明显趋势：在低延迟情况下，HTTP、HTTPS和HTTP/2之间没有显著差异。在较高延迟情况下，普通HTTP/1.x速度较快，其次是HTTP/2，HTTPS则较慢。

11:48 首次绘制

那么，“首次绘制”时间呢？在许多情况下，从用户的角度来看，这是非常重要的指标，因为此时用户才真正开始在屏幕上看到内容。相比页面完全加载所需的时间，用户需要等待多久才能看到内容往往重要得多。

这里呈现出相同的趋势，但测试中值得注意的是，当延迟处于30 ms至250 ms的中间范围时，HTTP/2比普通HTTP略快，不过差异很小。

12:45 配置

以上就是我们的基准测试结果。现在来看看如何配置HTTP/2和NGINX。

其实很简单，只需将http2参数添加到listen指令中。这里最复杂的步骤可能是获取最新版本的OpenSSL，因为HTTP/2需要ALPN［应用层协议协商］扩展，而只有OpenSSL 1.0.2支持ALPN扩展。

我们还为HTTP/2实现了NPN［下一协议协商］。目前，它适用于大多数客户端，但随着SPDY于2016年初被弃用，这些客户端将取消对NPN的支持。这意味着，目前可以使用许多Linux发行版自带的OpenSSL版本来运行HTTP/2，但需要注意，这种方式不久后将无法继续使用。

以上就是配置NGINX以支持HTTP/2的全部内容，我的演示到此结束。谢谢。

［参考文档：HTTP/2 模块］

问答

问： 是否也会在上游端支持HTTP/2，还是仅在客户端支持HTTP/2？

答：目前，我们仅在客户端支持HTTP/2。无法使用proxy_pass配置HTTP/2。［编者注：在本文的原始版本中，这句话被错误地转录为“可以使用 proxy_pass配置HTTP/2”。对于由此可能造成的任何困惑，我们深表歉意。］

但在后端使用HTTP/2有什么意义呢？从基准测试可以看出，对于上游连接等低延迟网络，HTTP/2带来的优势并不明显。

此外，NGINX还提供keepalive模块，可用于配置keepalive缓存。HTTP/2的主要性能优势是避免额外的握手，但如果已通过keepalive缓存实现这一点，上游侧就不需要使用HTTP/2。

更多HTTP/2资源

• 面向Web应用开发人员的HTTP/2：全面介绍HTTP/2相关知识的白皮书（PDF）
• 高性能浏览器网络，Google 的 Ilya Grigorik 所著电子书特别版
• HTTP/2 有哪些新特性？，NGINX 网络研讨会，介绍主要特性并提供实施建议
• 提升HTTP/2性能的7个技巧，博客文章
• 列表：支持HTTP/2的浏览器，来源：Can I Use?网站

准备好在您的环境中试用NGINX Plus的HTTP/2功能了吗？立即开始30天免费试用，或联系我们，讨论您的使用场景。

关于作者

Valentin Bartenev

Valentin Bartenev 的更多博客文章