HTTP/2流vs HTTP/1.1连接

Question

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

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

对我来说，很明显为什么HTTP/2随着并发级别的增加开始表现更好。但我不明白为什么返回更大响应的请求需要更高的并发性来显示比返回小响应的请求更好的性能。

添加一些测试结果。

服务器：码头， 浏览器：铬， 延迟：100毫秒， 带宽：100兆位

我检索从网页，其中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下载时需要考虑的附加变量。

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

对于HTTP/2，流或会话可能会因流量控制而停顿，HTTP/1中没有发生。

Jetty在这种情况下是高度可配置的。

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

如果您尝试执行与Jetty的HTTP/2客户端而不是浏览器的测试，还可以调整当通过调整BufferingFlowControlStrategy.bufferRatio参数发送WINDOW_UPDATE帧。 越接近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慢只是因为加密速度变慢。