HTTP / 2流与HTTP / 1.1连接

Question

如果我们忽略HTTP / 1.1中新连接创建的开销，是否有任何连接比HTTP / 2流更好的情况？

我对页面加载时间进行了一些性能测试，我注意到对于响应较大的请求，HTTP / 1.1（https）的性能优于HTTP / 2。然后，当我开始增加并发级别时，HTTP / 2开始执行得更好。换句话说，HTTP / 2开始提供更好性能的并发级别随响应消息的大小而增加。

对我而言，很明显为什么HTTP / 2随着并发级别的增加而开始表现更好。但我无法弄清楚为什么返回较大响应的请求需要更高的并发性才能显示比返回小响应的请求更好的性能。

添加一些测试结果。

服务器：Jetty， 浏览器：Chrome， 延迟：100毫秒， 带宽：100 mbit

我从网页中检索了X个100KB图像，其中X从1到500不等。

此外，加载100个1MB图像导致HTTP / 2比HTTP / 1.1慢50％。

Answer 1

HTTP / 2使用流量控制来避免端点分配无限量的内存。

通常，浏览器发送WINDOW_UPDATE帧以扩大其会话接收流控制窗口（默认情况下仅为65535个八位字节），因此服务器会话发送流控制窗口。

关于HTTP / 1流量控制是比较HTTP / 1和HTTP / 2下载时要考虑的另一个变量。

服务器可能开始写入数据，耗尽其流或会话发送流控制窗口并停止写入，直到客户端使用了数据并将WINDOW_UPDATE帧发送到服务器。

使用HTTP / 2时，由于流量控制，流或会话可能会停止，这在HTTP / 1中不会发生。

在这种情况下，Jetty具有高度可配置性。

首先，您可以监控会话或流是否已停止。这是通过FlowControlStrategy实现（AbstractFlowControlStrategy.get[Session|Stream]StallTime()）中的JMX公开的。

如果您尝试使用Jetty的HTTP / 2客户端而不是浏览器执行测试，您还可以通过调整{{来 时发送WINDOW_UPDATE帧来调整 1}}参数。 越接近BufferingFlowControlStrategy.bufferRatio，0.0帧越早发送越近WINDOW_UPDATE，1.0帧的发送越晚。

测试还应该报告客户端和服务器之间的网络往返是什么，因为这会影响（通常占主导地位）WINDOW_UPDATE帧从客户端到服务器所花费的时间。

在完美下载中，您希望客户端尽早发送WINDOW_UPDATE帧，以便在WINDOW_UPDATE帧到达服务器时，服务器尚未使用流/会话发送流控制窗口，所以它总是打开发送流量控制窗口，永远不会停止。

当浏览器发送WINDOW_UPDATE帧时，我不知道的可配置性，但是，对于大量下载，这可能会损害下载速度。

您希望密切关注客户端重新配置其会话和流接收流控制窗口的大小，以及何时发送WINDOW_UPDATE帧。

最后，可能影响下载速度的另一个参数是使用的TLS密码。 可能会发生您的HTTP / 1连接协商比HTTP / 2协商的密码弱得多的密码（因为HTTP / 2只需要非常强的密码），因此即使非停滞的HTTP / 2下载也比HTTP / 1更慢因为加密速度慢了。