提高 HTTP/2 性能的 7 个技巧

有关 HTTP/2 的更多信息，请观看我们热门网络研讨会“HTTP/2 有什么新功能？”的录音。

历史悠久的超文本传输协议（ HTTP ）标准现已更新。 HTTP/2 标准于 2015 年 5 月获得批准，目前正在浏览器和 Web 服务器（包括NGINX Plus和NGINX Open Source ）中实施。 目前，近三分之二的网络浏览器都支持 HTTP/2，并且这一比例每月增长几个百分点。

HTTP/2 建立在 Google 的 SPDY 协议之上，在 2016 年初Google Chrome 浏览器对 SPDY 的支持结束之前，SPDY 仍然是一种选择。 NGINX 是 SPDY 的先驱支持者，现在在 HTTP/2 中扮演着同样的角色。 我们的综合白皮书《面向 Webapplication开发人员的 HTTP/2》 （PDF）描述了 HTTP/2，展示了它如何在 SPDY 上构建，并解释了如何实现它。

HTTP/2 的主要特性与 SPDY 相同：

• HTTP/2 是二进制协议（而非文本协议），因此更加紧凑、高效
• 它对每个域使用单个多路复用连接，而不是每个域使用多个连接承载一个文件
• 标头使用专门构建的 HPACK 协议进行压缩（而不是像 SPDY 那样使用 gzip）
• HTTP/2 具有复杂的优先级方案，可帮助浏览器首先请求最需要的文件，NGINX 完全支持该方案（SPDY 的方案更简单）

现在您需要决定是否继续使用 HTTP/2——其中一部分就是了解如何充分利用它。 这篇博文将指导您了解决策和实施过程中与绩效相关的方面。 查看有关 HTTP/2 性能的 7 个技巧：

1. 确定您是否需要 HTTP/2
2. 终止 HTTP/2 和 TLS
3. 考虑从 SPDY 开始
4. 识别代码中的 HTTP/1.x 优化
5. 实现 HTTP/2 或 SPDY
6. 修改 HTTP/1.x 优化
7. 实施智能分片

笔记： 严格来说，SPDY 和 HTTP/2 都不需要 TLS，但两者在与 SSL/TLS 一起使用时主要有益，并且只有在使用 SSL/TLS 时浏览器才支持 SPDY 或 HTTP/2。

提示 1——确定你现在是否需要 HTTP/2

实现 HTTP/2 很容易，正如我们在白皮书《面向 Web应用开发人员的 HTTP/2》 （PDF）中所讨论的那样。 然而，HTTP/2 并不是灵丹妙药；它对某些 Web应用有用，但对其他 Web 应用程序则没那么有用。

如果您使用 SSL/TLS（以下简称 TLS），使用 HTTP/2 可能会提高网站性能。 但如果您还没有，则需要先添加 TLS 支持才能使用 HTTP/2。 在这种情况下，预计使用 TLS 的性能损失将大致被使用 HTTP/2 的性能优势所抵消，但在做出实施决定之前，请测试这是否确实适用于您的网站。

以下是 HTTP/2 的五个主要潜在优势：

1. 每个服务器使用单个连接– HTTP/2 每个服务器使用一个连接，而不是每个文件请求一个连接。 这意味着需要更少的耗时连接设置，这对于 TLS 尤其有益，因为创建 TLS 连接特别耗时。
2. 提供更快的 TLS 性能– HTTP/2 只需要一次昂贵的 TLS 握手，多路复用可以最大限度地利用单个连接。 HTTP/2 还压缩标头数据，并避免文件连接等 HTTP/1.x 性能优化，从而使缓存工作更高效。
3. 简化您的 Web应用——使用 HTTP/2，您可以摆脱 HTTP/1.x“优化”，这些优化会让您（作为应用程序开发人员）和客户端设备更加辛苦地工作。
4. 非常适合混合网页- HTTP/2 在混合 HTML、CSS、JavaScript 代码、图像和有限多媒体的传统网页中大放异彩。 浏览器可以对文件请求进行优先排序，以使页面的关键部分首先快速出现。
5. 支持更高的安全性——通过减少 TLS 的性能损失，HTTP/2 允许更多 Web应用使用它，为用户提供更高的安全性。

以下是你会遇到的五个相应缺点：

1. 单个连接的开销更大– HPACK 数据压缩算法在两端更新查找表。 这使得连接具有状态并且单个连接需要额外的内存。
2. 您可能不需要加密——如果您的数据不需要保护，或者已经受到 DRM 或其他编码的保护，TLS 安全性可能对您没有太大帮助。
3. HTTP/1.x 优化会带来损害- HTTP/1.x 优化实际上会损害支持 HTTP/2 的浏览器的性能，而取消它们会给您带来额外的工作。
4. 大量下载没有好处——如果您的 Web应用主要提供大型可下载文件或媒体流，那么您可能不需要 TLS，而且当仅使用一个流时，多路复用不会带来任何好处。
5. 您的客户可能并不关心- 也许您认为您的客户并不关心他们在您的网站上分享的猫视频是否受到 TLS 和 HTTP/2 的保护 - 您可能是对的。

一切都取决于表现——在这方面，我们有好消息也有坏消息。

好消息是，我们在 NGINX 上运行的初步内部测试显示了理论预测的结果：对于通过具有典型互联网延迟的连接请求的混合内容网页，HTTP/2 的表现优于 HTTP/1.x 和 HTTPS。 根据连接的典型往返时间 (RTT)，结果分为三类：

• 非常低的 RTT（0-20 毫秒） ——HTTP/1.x、HTTP/2 和 HTTPS 之间几乎没有区别。
• 典型的互联网 RTT（30-250 毫秒） ——HTTP/2 比 HTTP/1.x 快，并且都比 HTTPS 快。 对于彼此邻近的美国城市，RTT 约为 30 毫秒，而从海岸到海岸（约 3000 英里）约为 70 毫秒。 在东京和伦敦之间的最短路线上，RTT 约为 240 毫秒。
• 高 RTT（300 毫秒及以上） – HTTP/1.x 比 HTTP/2 快，而 HTTP/2 又比 HTTPS 快。

该图显示了首次绘制的时间——即用户第一次看到网页内容出现在屏幕上的时间。 该测量通常被认为对于用户对网站响应能力的感知至关重要。

有关我们测试的详细信息，请观看我在 nginx.conf 2015 中的演示文稿《NGINX 中的 HTTP/2 模块》 。

然而，每个网页都是不同的，并且每个用户会话实际上也是不同的。 如果您有流媒体或大型可下载文件，或者您已经对 HTTP/1.x 优化进行了科学改良（向The Martian致歉），您的结果可能会有所不同，甚至是相反的。

底线是：您可能会发现成本效益权衡不明确。 如果是这样，请尽可能多地学习，对自己的内容进行性能测试，然后拨打电话。 （如需指导，请观看我们的网络研讨会“HTTP/2 有什么新功能？ ”。）

提示 2——终止 HTTP/2 和 TLS

终止协议意味着客户端使用所需的协议（例如 TLS 或 HTTP/2）连接到代理服务器。 然后，代理服务器连接到应用服务器、数据库服务器等，而不一定使用相同的协议，如图所示。

使用单独的服务器进行终止意味着转向多服务器架构。 这些服务器可能是独立的物理服务器、虚拟服务器或AWS等云环境中的虚拟服务器实例。 与单个服务器甚至应用服务器/数据库服务器组合相比，这在复杂性上有所提升。 但它确实带来了很多好处，而且实际上——这不是双关语——对于繁忙的站点来说，它是一种必需品。

一旦将服务器或虚拟服务器放置在现有设置前面，许多事情就皆有可能。 新的服务器卸载了其他服务器的客户端通信任务，并且可用于负载均衡、静态文件缓存和其他用途。 根据需要可以轻松添加和替换应用服务器和其他服务器。

NGINX 和 NGINX Plus 通常用于所有这些目的 - 终止 TLS 和 HTTP/2、负载均衡等。 现有环境根本不需要改变，除了使用 NGINX 服务器“前端”它之外。

提示 3——考虑从 SPDY 开始

编辑——自这篇博文发布以来，SPDY 已不再得到主流浏览器的支持。 从 SPDY 开始不再是一种广泛部署的选择。

SPDY是HTTP/2的前身协议，整体性能差不多。 因为它已经存在好几年了，所以支持 SPDY 的网络浏览器比支持 HTTP/2 的还多。 然而，在撰写本文时，差距正在缩小；大约三分之二的网络浏览器支持 HTTP/2，而大约五分之四的网络浏览器支持 SPDY。

如果您急于实施新式 Web 传输协议，并且想要支持尽可能多的用户，那么您可以先提供 SPDY。 然后，在 2016 年初，当 SPDY 支持开始被移除时，您可以切换到 HTTP/2——这是一个快速的变化，至少对于 NGINX 来说是这样。到那时，更多的用户将使用支持 HTTP/2 的浏览器，因此您将在这次过渡期间为最多的用户做最好的事情。

提示 4——确定您对 HTTP/1.x 优化的使用

在决定实施 HTTP/2 之前，您需要确定代码库中有多少针对 HTTP/1.x 进行了优化。 有四种类型的优化需要注意：

1. 域分片——您可能已经将文件放在不同的域中，以增加文件向 Web 浏览器传输的并行性；内容域网络 (CDN) 会自动执行此操作。 但它对 HTTP/2 下的性能没有帮助，甚至可能损害性能。 您可以使用 HTTP/2 智能域分片（请参阅技巧 7 ）仅为 HTTP/1.x 用户进行分片。
2. 图像精灵——图像精灵是下载到单个文件中的图像的集合；然后单独的代码会在需要时检索图像。 尽管你仍然会发现图像精灵很有用，但它的优势在 HTTP/2 下有所减弱。
3. 连接代码文件——与图像精灵类似，通常作为单独文件维护和传输的代码块被合并为一个。 然后，浏览器根据需要在连接的文件中找到并运行所需的代码。
4. 内联文件——CSS 代码、JavaScript 代码甚至图像都直接插入到 HTML 文件中。 这意味着更少的文件传输，但初始下载的 HTML 文件会变得臃肿。

最后三种优化都将小文件合并为大文件，以减少新连接和初始化握手，这对于 TLS 来说尤其昂贵。

第一个优化，域分片，则起到相反的作用——通过涉及更多域来强制打开更多连接。 总之，这些看似矛盾的技术可以相当有效地提高 HTTP/1.x 网站的性能。 然而，它们都需要时间、精力和资源来设计、实施、管理和运行。

在实施 HTTP/2 之前，请确定这些优化存在的位置以及它们当前如何影响组织中的应用设计和工作流程，以便您可以在迁移到 HTTP/2 之后修改或撤消它们。

提示 5——部署 HTTP/2 或 SPDY

实际上部署 HTTP/2 或 SPDY 并不难。 如果您是 NGINX 用户，您只需在 NGINX 配置中“打开”协议，正如我们在白皮书《面向 Webapplication开发人员的 HTTP/2》（PDF）中详细介绍的 HTTP/2 。 然后，浏览器和服务器将协商选择一种协议，如果浏览器也支持 HTTP/2（并且正在使用 TLS），则选择 HTTP/2。

一旦您在服务器级别实现 HTTP/2，使用支持 HTTP/2 的浏览器版本的用户将通过 HTTP/2 与您的 Web 应用进行会话。 使用旧版本浏览器的用户的会话将在 HTTP/1.x 上运行，如图所示。 如果您为繁忙的站点实施 HTTP/2 或 SPDY，您将需要制定流程来测量前后的性能，并在更改产生重大负面影响时撤销更改。

笔记： 随着 HTTP/2 及其单一连接的使用，NGINX 配置的某些细节变得更加重要。 检查您的 NGINX 配置，特别注意调整和测试诸如output_buffers 、 proxy_buffers和ssl_buffer_size等指令的设置。 有关一般配置说明，请参阅 NGINX Plus 管理指南中的NGINX SSL/TLS 终止。 您可以在我们的博客《使用 NGINX 进行 SSL 卸载、加密和证书》和《如何使用 HTTPS 和 NGINX 改善 SEO》中获取更多具体提示。我们的白皮书《NGINX SSL 性能》探讨了服务器密钥大小、服务器协议和批量密码的选择如何影响性能。

笔记： 使用 HTTP/2 的密码可能需要额外注意。 HTTP/2 的 RFC 中列出了需要避免的密码套件，您可能更愿意自己配置密码列表。 在 NGINX 和 NGINX Plus 中，考虑调整ssl_ciphers指令并启用ssl_prefer_server_ciphers ，并使用流行的浏览器版本测试配置。 Qualys SSL 服务器测试分析了 SSL 网络服务器的配置，但（截至 2015 年 11 月）它对于 HTTP/2 握手并不可靠。

提示 6——修改 HTTP/1.x 优化

令人惊讶的是，撤消或修改 HTTP/1.x 优化实际上是 HTTP/2 实现中最有创意的部分。 有几个问题需要考虑，而且对于做什么有很多自由度。

在开始进行更改之前，请考虑旧版浏览器的用户是否会受到影响。 考虑到这一点，有三种主要的策略可以撤消或修改 HTTP/1.x 优化：

• 大家，这里没什么可看的——如果您还没有针对 HTTP/1.x 优化您的应用，或者您做了一些您愿意保留的适度更改，那么您无需做任何工作来在您的应用程序中支持 HTTP/2。
• 混合方法——您可能决定减少文件和数据连接，但不能完全消除它们。 例如，一些用于将小图像聚合在一起的图像精灵可能会保留，而使用内联数据扩充初始 HTML 文件的功能可能会消失。
• 完全逆转 HTTP/1.x 优化（但请参阅技巧 7中的域分片说明）——您可能希望完全摆脱这些优化。

缓存有点像通配符。 理论上，当存在大量小文件时，缓存运行效果最佳。 然而，这需要大量的文件 I/O。 对于工作流程和应用性能来说，将一些密切相关的文件串联起来可能是有意义的。 仔细考虑您自己的经验以及其他开发人员在实施 HTTP/2 时分享的经验。

提示 7——实施智能分片

域名分片可能是最极端的，也可能是最成功的 HTTP/1.x 优化策略。 您可以使用某个版本的域分片，它仍然可以提高 HTTP/1.x 的性能，但对于 HTTP/2 来说基本上被忽略，并且是有益的。 （由于使用单个连接，因此通常不会从域分片中受益。）

对于 HTTP/2 友好的分片，需要做以下两件事：

• 使分片资源的域名解析为同一个IP地址。
• 确保您的证书具有通配符，使其对用于分片的所有域名有效，或者您拥有适当的多域证书。

有关详细信息，请参阅RFC 7540 ，超文本传输协议版本 2 (HTTP/2) 。

如果这些条件满足，HTTP/1.x 就会发生分片——域名足够不同，从而触发浏览器创建额外的连接集——而 HTTP/2 则不会；单独的域名将被视为一个域名，单个连接可以访问所有域名。

结论

HTTP/2 和 TLS 可能会提高您的网站性能，并让用户知道他们与您网站的交互是安全的。 无论您是第一个实现 HTTP/2 的人，还是正在追赶竞争对手，您都可以快速、良好地添加 HTTP/2 支持。

使用这些技巧可以帮助您以最少的持续努力实现最高的 HTTP/2 性能，这样您就可以专注于创建易于维护和运行的快速、有效、安全的应用。

资源

• 有关 HTTP/2 的详细信息，请参阅 NGINX 白皮书（ PDF ）。
• “我可以使用吗”网站展示了浏览器对各种前端 Web 技术的支持，包括SPDY和HTTP/2 。
• 截至 2016 年 1 月，超过 6% 的网站使用 HTTP/2。

 

• 有关我们测试的详细信息，请参阅 nginx.conf 2015 中的HTTP/2 介绍。
• NGINX 有一个网络研讨会， HTTP/2 有什么新功能？ ，其中描述了主要功能并提供了实施建议。
• 有关 NGINX 性能技巧的概述，请参阅我们的博客文章“提高 10 倍application性能的 10 个技巧” 。