HTTP/2请求头压缩

Question

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

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

还有另一个问题：如果我想在负载下对HTTP/1.1和HTTP/2的性能进行基准测试，那么一个有用的测试设置会是什么样的，哪些参数会有所不同，哪些指标是有意义的（RTT、TTFB等等）

Answer 1

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

也可以在HTTP/1.1上启动第一个（或更多）请求，然后在稍后阶段升级到HTTP/2。这是由服务器通过发送升级：h2（用于HTTPS）或升级：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：//www.tunetheweb.com

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

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

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

希望有帮助。