我正在尝试迁移到 http/2。我已经建立了一个 Wordpress 网站并配置 NGINX 以使用 http/2（使用 SSL/TLS）为其提供服务。
我对 http/2 的理解是，默认情况下它使用一个连接来传输多个文件 - 而不是打开新连接并为每个文件重复 SSL 握手。
为了在 http/1.x 中实现类似的效果，NGINX 提供了 keepalive 指令。
那么当只使用 http/2 时，使用 keepalive 指令有意义吗？当我包含它时，使用“nginx -t”检查我的配置文件不会报告任何错误。但它有什么作用吗？基准测试显示没有差异。
【问题讨论】：
您误解了它的工作原理。
在请求之间保持 Alive 的工作。
当您下载一个网页时，它会下载 HTML 页面并发现它需要另外 20 个资源，例如（CSS 文件、javascript 文件、图像、字体...等）。
在 HTTP/1.1 下，您一次只能请求其中一个资源，因此通常网络浏览器会启动另外 5 个连接（总共提供 6 个）并请求这 20 个资源中的 6 个。然后它会在这些连接释放时请求剩余的 14 个资源。是的，keep-alives 在这些请求之间有帮助，但这并不是我们将在下面讨论的唯一用途。设置这些连接的开销很小但很明显，并且一次只能请求这 20 个资源中的 6 个资源存在延迟。这就是为什么 HTTP/1.1 对于当今网络使用效率低下的原因，因为典型的网页由 100 个资源组成。
在 HTTP/2 下，我们可以在同一个连接上一次触发所有 20 个请求，因此在那里获得了一些不错的收益。是的，从技术上讲，您并没有真正受益于它们之间的保持连接，因为连接仍在使用中，直到它们全部到达 - 尽管仍然受益于第一个 HTML 请求和其他 20 个请求之间的小延迟。
但是，在初始加载之后，可能会有更多请求。要么是因为您正在浏览站点，要么是因为您与页面交互并且它会进行额外的 XHR api 调用。无论是在 HTTP/1.1 还是 HTTP/2 上，这些都将受益于 keep-alive。
所以 HTTP/2 并不否定保活的需要。它不需要多个连接（除其他外）。
所以答案是始终使用 keep-alives，除非您有充分的理由不这样做。你用什么类型的基准测试来说明它没有区别？
【讨论】：
curl -I --http1.1 和 keep-alive 时，回复包括 Connection: keep-alive。但是使用curl -I --http2 显示没有这样的条目。
keep-live: close 来关闭。在 HTTP/2 下，它们无法在 HTTP 级别关闭，因此始终处于开启状态。