HTTP/2 请求头压缩答案

【问题标题】：HTTP/2 request header compressionHTTP/2 请求头压缩
【发布时间】：2017-01-03 07:21:02
【问题描述】：

由于我不是专家，所以我有一个关于 HTTP/2 的一般性问题。

众所周知，HTTP2 压缩标头以减小消息大小。这仅适用于响应还是也适用于请求？如果做一个小实验并运行两台小型 HTTP 服务器，一台使用 1.1 版，另一台使用 2 版，让它们发送完全相同的内容，然后在 Firefox 中请求这两个页面，我可以看到响应头的大小要小得多HTTP/2 版本。但是，请求标头大小几乎相同。据我了解，这是有道理的，因为浏览器事先并不知道服务器是否支持 HTTP/2，因此无法预先压缩标头。我对吗？如果是这样，有没有办法“强制”客户端使用 HTTP/2（对于客户端，我不是指浏览器，而是程序化的）并压缩请求标头？

还有一个问题：如果我想在负载下对 HTTP/1.1 和 HTTP/2 性能进行基准测试，那么有用的测试设置应该是什么样的，哪些参数会变化，哪些指标可以测量（RTT， TTFB，...？）

【问题讨论】：

它适用于请求和响应标头。你是如何测量标题大小的？
客户端如何提前知道可以发送压缩头？这是通过ALPN 完成的吗？出于测试目的，我只是为此使用了 Firefox 开发工具（网络分析），它在单击请求时打印“请求标头（427 kb）”。实际上，我不知道该大小是否与实际通过网络传输的标头的大小或最终缩小的标头的大小有关。我正在寻找一种查看 HTTP 包大小（Node.js http）的好方法，有什么建议吗？

标签： http2 spdy

【解决方案1】：

在启动连接时，您协商协议。客户端需要知道它是在说 HTTP/1.1、HTTP/2 还是其他东西，然后才能知道要发送的格式。对于 HTTPS 连接，这由使用 ALPN 的 TLS 连接协商处理。

也可以针对第一个（或更多）请求从 HTTP/1.1 开始，然后在稍后阶段升级到 HTTP/2。这由服务器通过 HTTP/1.1 连接通过在响应中发送Upgrade: h2（对于 HTTPS）或Upgrade: h2c（对于 HTTP）HTTP 标头来处理，然后客户端可以选择升级。这对于最初没有 TLS 协商的 HTTP 连接更有用，因此客户端可能会采用 HTTP/1.1。然而，所有的 Web 浏览器都表示它们不会支持 HTTP/2 over HTTP (h2c)，只会支持 HTTPS (h2)。老实说，我想不出为什么 HTTPS 连接会从 HTTP/1.1 开始，然后升级到 HTTP/2——而不是从一开始就以 HTTP/2 开始，但理论上这是可能的。

您可以通过单击此链接查看升级标头的示例： https://securityheaders.io/?q=https%3A%2F%2Fwww.tunetheweb.com&followRedirects=on 注意我只使用 securityheaders.io 网站作为显示 HTTP 标头的快速方法。从理论上讲，您可以通过使用浏览器直接访问https://www.tunetheweb.com 并查看响应标头来看到相同的结果，但这很可能是通过 HTTP/2 完成的，因此不会有标头。另请注意，这是一个可选标头，并非所有 HTTP/2 服务器都发送它（例如 Apache 发送，NGINX 不发送）——可能是因为它在 HTTPS 上没有那么有用，如上所述。

了解压缩在 HTTP/2 上的工作原理很重要。首先，您会受益于它是二进制协议而不是基于文本的协议，因此可以节省一些费用。然而，主要的节省是通过创建一个标题表来避免重复。这意味着第一个请求将是完整大小，只有后续请求会更小，因为它们会用对表的引用替换实际的标头。和响应头类似（压缩用于两者）。虽然这并不完全正确，因为有一个预定义的、静态的常见 HTTP 标头和值表（例如 GET 和 /），所以第一个请求仍然可以节省一些费用，但后续请求的时间越长就越节省标头（例如用户代理）被引用替换。

我很确定（尽管不是 100%）浏览器显示完整大小而不考虑 HTTP/2 HPACK 压缩，因为这是在较低级别完成的（尽管大多数显示两个数字 - 有和没有 gzip 正文压缩但这是不同的）。要查看实际的 HTTP/2 详细信息和大小，您需要使用 Wireshark 或 Chrome 的 net-internals 页面等工具。有关一些建议的工具，请参阅此页面：https://community.akamai.com/community/web-performance/blog/2015/06/05/useful-tools-for-http2-debugging。需要注意的另一点是，与大多数正文相比，标头大小通常很小（至少对于响应而言）。

至于性能基准测试工具，这是一个超出 Stack Overflow 范围的庞大话题，因为有很多变量会影响这一点（例如网络位置、类型 - 影响延迟和带宽 - HTTP/2 在浏览器和客户端上的软件实现）边...等）。我能建议的最好的方法是尽可能多地复制您的用户典型设置并尽可能多地重复测试，或者在分析软件中使用 RUM（真实用户监控）指标。 HTTP/2 应该使大多数网站更快，但它不是给定的。这个网页是一个很好的例子，一个非常受带宽限制的网站，实际上在没有调整的情况下通过 HTTP/2 连接速度较慢：https://99designs.ie/tech-blog/blog/2016/07/14/real-world-http-2-400gb-of-images-per-day/

希望对您有所帮助。

【讨论】：