NGINX 1.13.9 引入 HTTP/2 服务器推送

NGINX Plus R15还包含对 HTTP/2 服务器推送的支持。

我们很高兴地宣布， 2018 年 2 月 20 日发布的NGINX 1.13.9已支持 HTTP/2 服务器推送。 对于 NGINX Plus 用户，HTTP/2 服务器推送支持将包含在即将于 2018 年 4 月发布的NGINX Plus R15版本中。

服务器推送是在 HTTP/2 规范中定义的，它允许服务器预先将资源推送到远程客户端，预测客户端可能很快会请求这些资源。 通过这样做，您可以将页面加载操作中的 RTT（往返时间 - 请求和响应所需的时间）数量减少一个或多个，从而为用户提供更快的响应。

服务器推送可用于向客户端提供呈现网页所需的样式表、图像和其他资源。 您应该注意仅推送所需的资源；不要推送客户端可能已经缓存的资源。

在这篇博文中，我描述：

• HTTP/2 服务器推送的基本配置
• 如何验证 HTTP/2 服务器推送是否正常工作（使用浏览器工具或nghttp ）
• 使用链接标头自动推送内容
• 选择性推送内容
• 衡量 HTTP/2 服务器推送的效果

配置 HTTP/2 服务器推送

要在页面加载时推送资源，请使用http2_push指令，如下所示：

服务器 { # 确保服务器启用了 HTTP/2 监听 443 ssl http2 ; ssl_certificate ssl/certificate.pem; ssl_certificate_key ssl/key.pem; root /var/www/html; # 每当客户端请求 demo.html 时，也会推送 # /style.css、/image1.jpg 和 /image2.jpg location = /demo.html { http2_push /style.css; http2_push /image1.jpg; http2_push /image2.jpg; } }

验证 HTTP/2 服务器推送

您可以使用以下两种方法之一轻松验证服务器推送是否有效：

• 网络浏览器中的开发人员工具
• 命令行 HTTP/2 客户端，例如nghttp

使用开发者工具验证 (Google Chrome)

下面以 Google Chrome 为例，介绍如何使用 Web 浏览器中的开发人员工具来验证服务器推送是否有效。 图中，Chrome 开发者工具的网络选项卡上的启动器列表明，作为/demo.html请求的一部分，多个资源被推送到客户端。

使用命令行客户端进行验证（ nghttp ）

除了 Web 浏览器工具之外，您还可以使用nghttp2.org项目中的nghttp命令行客户端来验证服务器推送是否有效。 您可以从GitHub下载nghttp命令行客户端，或者在可用的情况下安装适当的操作系统包。 对于 Ubuntu，使用nghttp2-client包。

在输出中，星号（*）标记了服务器推送的资源。

$ nghttp -ans https://example.com/demo.html id 响应结束请求开始进程代码大小请求路径 13 +84.25ms +136us 84.11ms 200 492 /demo.html 2 +84.33ms * +84.09ms 246us 200 266 /style.css 4 +261.94ms * +84.12ms 177.83ms 200 40K /image2.jpg 6 +685.95ms * +84.12ms 601.82ms 200 173K /image1.jpg

自动推送资源给客户端

在许多情况下，在 NGINX 配置文件中列出您希望推送的资源是不方便的，甚至是不可能的。 为此，NGINX 还支持拦截Link预加载标头的约定，然后推送这些标头中标识的资源。 要启用预加载，请在配置中包含http2_push_preload指令：

服务器 { # 确保服务器启用了 HTTP/2 监听 443 ssl http2 ; ssl_certificate ssl/certificate.pem; ssl_certificate_key ssl/key.pem; root /var/www/html; # 拦截链接标头并发起请求的推送 location = /myapp { proxy_pass http://upstream; http2_push_preload on; } }

例如，当 NGINX 作为代理运行时（对于 HTTP、FastCGI 或其他流量类型），上游服务器可以在其响应中添加如下Link标头：

链接：</style.css>; as=style; rel=preload

NGINX 拦截该标头并开始/style.css的服务器推送。 链接标头中的路径必须是绝对路径 - 不支持像./style.css这样的相对路径。 该路径可以选择包含查询字符串。

要推送多个对象，您可以提供多个Link标头，或者更好的是，将所有对象包含在逗号分隔的列表中：

链接：</style.css>; as=style; rel=preload，</favicon.ico>; as=image; rel=preload

如果你不想让 NGINX 推送预加载的资源，请在标头中添加nopush参数：

# 资源未推送Link: </nginx.png>; as=image; rel=preload; nopush

当http2_push_preload启用时，您还可以通过在 NGINX 配置中设置响应标头来启动预加载服务器推送：

add_header 链接 "</style.css>; as=style; rel=preload";

选择性地向客户推送资源

HTTP/2 规范并未解决确定是否推送资源的难题。 显然，如果您知道客户端可能需要该资源并且不太可能已经缓存该资源，那么最好只将资源推送给客户端。

一种可能的方法是仅在客户第一次访问网站时向其推送资源。 例如，您可以测试会话 cookie 是否存在，并有条件地设置Link标头，这样仅当不存在会话 cookie 时才会预加载资源。

假设客户端行为良好并在后续请求中包含 cookie，则通过以下配置，NGINX 在每个浏览器会话中仅将资源推送到客户端一次：

服务器 {
listen 443 ssl http2 default_server;

ssl_certificate ssl/certificate.pem;
ssl_certificate_key ssl/key.pem;

root /var/www/html;
http2_push_preload on;

location = /demo.html {
add_header Set-Cookie "session=1";
add_header Link $resources;
}
}

map $http_cookie $resources {
"~*session=1" "";
default "</style.css>; as=style; rel=preload, </image1.jpg>; as=image; rel=preload, </image2.jpg>; as=image; rel=preload";
}

衡量 HTTP/2 服务器推送的效果

为了衡量服务器推送的效果，我们创建了一个简单的测试页面/demo.html ，它引用了一个单独的样式表/style.css 。 样式表进一步引用了两幅图像。 我们使用三种不同的配置测试了页面加载时间：

• 顺序GET （无优化）——浏览器在发现需要资源时才加载资源
• 预加载提示——预加载提示（链接标头）包含在第一个响应中，以告知浏览器加载依赖项
• 服务器推送（仅限 HTTP/2）——依赖项被预先推送到浏览器

我们使用 HTTP、HTTPS 或 HTTP/2 对每种配置进行了多次测试运行。 前两个配置适用于所有三种协议，服务器推送仅适用于 HTTP/2。

该行为是使用 Chrome 开发者工具来测量的。 对每种配置的最常见行为进行了评估和平均，并将时间与链路的 RTT（使用ping测量）相关联，以说明每种方法的机械效果。

一些基本观察

• DOM 加载是启动新连接并检索demo.html页面的时候。 样式表是检索 CSS 资源的时候。
• 通过 HTTP 建立连接需要 1 RTT；对于 HTTPS 和 HTTP/2，则需要 2 RTT。
• HTML 和 CSS 资源的有效负载小于最大传输单元 (MTU) 大小，因此GET操作大约在 1 RTT 内完成。

解释结果： 预加载提示

• 预加载提示对于 CSS 资源的影响很小，因为它直接在 HTML 资源中引用，并且 HTML 资源交付很快。 HTML 页面一传送，浏览器就会发起 CSS 请求。
• 预加载提示确实具有快速启动 CSS 资源中声明的资源下载的效果（此处为两张图片）。 使用预加载提示时，下载可以更快地开始 1 RTT。
• 预加载提示带来的净节省可以是 1 RTT 或更多。 当并行下载资源时，浏览器必须打开一个或多个额外的连接。 性能取决于是否首先安排慢速请求（较大的响应），或者在打开新连接时延迟。 这种不可预测的请求顺序导致了 HTTP 和 HTTP/2 的 1-RTT 加速以及 HTTPS 的 2-RTT 加速。

解释结果： 服务器推送

• 服务器推送将预加载提示时间进一步缩短了 1 RTT。 推送“响应”与对第一个请求的响应同时发起，而预加载提示响应产生 1 RTT 延迟 - 对第一个请求的响应为 0.5 RTT 加上预加载GET请求的 0.5 RTT。

测试说明

• 每种配置都有多次测试运行。 每次运行都以空的浏览器缓存开始，并且没有与 NGINX 服务器建立保持连接。 NGINX 指令keepalive_timeout和http2_idle_timeout用于快速关闭保持连接。
• 目前似乎无法将字体资源推送到 Chrome，这可能是由于已知的复杂情况。 即使字体资源已经被推送，Chrome 也会明确请求该字体资源。
• 每次测试之前都要小心地明确清除浏览器缓存，并且所有内容都带有过期的缓存控制标头。
• Chrome 缓存预加载的资源。 当您禁用缓存时，这些缓存资源不会被一致忽略，也不会通过明确的“清除浏览器缓存”操作被一致清除。 （在 Chrome 中，禁用缓存的一种方法是选中开发人员工具网络选项卡上的禁用缓存复选框。 要清除浏览器缓存，您可以打开开发人员工具，右键单击浏览器刷新按钮，然后选择“清空缓存并硬重新加载”。
• 一些预加载内容的尝试导致 Chrome 重新验证缓存副本失败，然后正常下载资源。 这些尝试不计入测量中。
• Chrome 会为所有使用先前接受的自签名证书的新 SSL 连接添加不必要的 2-RTT 延迟。 测试使用 CA 签名的 Let’s Encrypt 证书进行，以避免此 2-RTT 延迟。
• 通过编辑本地/etc/hosts文件解决了 DNS 延迟问题。
• 当客户端已经拥有资源的缓存副本时，这些简单的测试并未尝试测量服务器推送的效果。 在测试中，每次测试前都会清除所有缓存，并且大多数推送都太快而无法取消。

结论

这次测试刻意做得简单，是为了突出预加载提示和服务器推送的机制。 在简单情况下，服务器推送比预加载提示提供了 1-RTT 的改进，与未优化的顺序GET请求和依赖资源的发现相比，改进更大。

更现实的用例有更多的变量：多个依赖资源，多个来源，甚至通过推送已经缓存或不立即需要的资源而浪费带宽的可能性。 浏览器不一致也会影响性能。 您的里程肯定会与这个简单的测试有所不同。

例如，Chrome 团队发布了一些关于何时部署服务器推送的详细建议，并在更复杂的网站上进行了测量，以比较无优化、预加载提示和通过 HTTP/2 进行服务器推送的效果。 对于任何考虑在生产中部署 HTTP/2 服务器推送的人来说，他们的《HTTP/2 推送经验规则》报告都值得一读。

务实的结论是，如果您可以提前确定需要哪些资源，那么让上游服务器发送预加载提示会带来真正的好处。 推送这些资源的额外好处虽小但可以衡量，但可能会导致带宽浪费和所需资源的延迟。 您应该仔细测试和监控任何服务器推送配置。

附录： HTTP/2 推送如何工作？

以下信息部分基于 Jake Archibald 的非常详细的“HTTP/2 推动比我想象的更艰难”博客文章中的研究。

HTTP/2 服务器推送通常用于在客户端请求资源时预先发送依赖资源。 例如，如果客户端请求网页，服务器可能会将相关的样式表、字体和图像推送给客户端。

当客户端建立 HTTP/2 连接时，服务器可以选择通过该连接启动一个或多个服务器推送响应。 这些推送发送客户端未明确请求的资源。

客户端可以拒绝推送（通过发送RST_STREAM帧）或接受推送。 客户端将推送的内容存储在与 HTTP/2 连接相关联的本地“推送缓存”中。

稍后，当客户端使用已建立的 HTTP/2 连接请求资源时，它会检查连接的推送缓存中是否有对该请求的已完成或正在传输的响应。 它优先使用缓存的资源，而不是对该资源发出新的 HTTP/2 请求。

任何推送的资源都会保留在每个连接的推送缓存中，直到 (a) 被使用或 (b) HTTP/2 连接关闭：

1. 如果资源被使用，客户端就会复制一份并删除推送缓存中的条目。 如果资源可缓存，客户端就可以将其副本缓存在其 HTTP 页面缓存中。
2. 如果 HTTP/2 连接由于任何原因关闭，其本地推送缓存将被删除。

这有几个含义：

• 浏览器中的 HTTP 页面缓存中的内容优先于推送缓存中的内容，即使推送的内容更新鲜。
• HTTP/2 连接可以在不同的页面加载之间共享。 在一个页面加载时推送的资源可以在不同的页面加载时被请求使用。
• 带有凭证的请求使用与不带有凭证的请求不同的 HTTP/2 连接；例如，如果浏览器对资源发出非凭证请求，则可能无法找到使用跨域请求（凭证）推送的资源。

您可以在 Jake Archibald 的“HTTP/2 推送比我想象的还要艰难”博客文章中查看更详细的问题列表。

HTTP/2 服务器推送是一项有趣的功能。 确保彻底测试您的 HTTP/2 服务器推送配置，并准备在提供更可预测的缓存感知行为的情况下回退到预加载提示。