HTTP/2流与HTTP/1.1连接
如果我们忽略了HTTP/1.1中新连接创建的开销，那么在任何情况下连接的性能都比HTTP/2流更好吗?
If we disregard the overhead of new connection creation in HTTP/1.1, is there any cases where connections perform better than HTTP/2 streams?
我对页面加载时间进行了一些性能测试，并且发现对于响应较大的请求，HTTP/1.1(https)的性能优于HTTP/2.然后，当我开始提高并发级别时，HTTP/2开始表现更好.换句话说，HTTP/2开始提供更好性能的并发级别随响应消息的大小而增加.
I conducted some performance tests for page load times and I noticed that HTTP/1.1(https) performs better than HTTP/2 for requests with large responses. Then when I start to increase the concurrency level, HTTP/2 starts to perform better. In other words, concurrency level which HTTP/2 starts to give better performance goes up with the size of the response message.
对我来说，很清楚为什么HTTP/2随着并发级别的提高而开始表现更好.但是我无法弄清楚为什么返回较大响应的请求比返回较小响应的请求需要更高的并发性才能表现出更好的性能.
For me it is clear why HTTP/2 starts to perform better with the increase of concurrency level. But I can't figure out why requests returning larger responses need higher concurrency to show better performance than requests returning small responses.
添加一些测试结果.
服务器:码头， 浏览器:Chrome， 延迟时间:100ms， 带宽:100兆比特
Server: Jetty, Browser: Chrome, Latency : 100ms, Bandwidth :100 mbit
我从一个网页检索了X个100KB图像，其中X从1到500不等.
I retrieved X number of 100KB images from a web page, where X varies from 1 to 500.
此外，加载100张1MB图像导致HTTP/2比HTTP/1.1慢50％.
Further, loading 100 number of 1MB images resulted in HTTP/2 50% slower than HTTP/1.1.
HTTP/2使用流控制来避免端点分配无限制的内存量.
HTTP/2 uses flow control to avoid that endpoints allocate an unbounded amount of memory.
通常，浏览器发送WINDOW_UPDATE帧以扩大其会话接收流控制窗口(默认情况下仅65535个八位位组)，因此服务器会话发送流控制窗口.
Typically browsers send a WINDOW_UPDATE frame to enlarge their session receive flow control window (by default only 65535 octets), and therefore the server session send flow control window.
关于HTTP/1流控制是比较HTTP/1和HTTP/2下载时要考虑的另一个变量.
With respect to HTTP/1 flow control is an additional variable to consider when comparing HTTP/1 and HTTP/2 downloads.
服务器可以开始写入数据，耗尽其流或会话发送流控制窗口并停止写入，直到客户端使用完数据并向服务器发送WINDOW_UPDATE帧为止.
The server may start writing data, exhaust its stream or session send flow control window and stop writing until the client has consumed the data and sent to the server a WINDOW_UPDATE frame.
使用HTTP/2时，流或会话可能会由于流控制而停顿，而HTTP/1中不会发生这种情况.
With HTTP/2, the stream or the session may stall because of flow control, something that in HTTP/1 does not happen.
在这种情况下，Jetty是高度可配置的.
Jetty is highly configurable in this case.
首先，您可以监视会话或流是否已停止.这是通过FlowControlStrategy实现(AbstractFlowControlStrategy.get[Session|Stream]StallTime())中的JMX公开的.
First of all, you can monitor whether the session or the stream have stalled. This is exposed via JMX in the FlowControlStrategy implementation (AbstractFlowControlStrategy.get[Session|Stream]StallTime()).
如果尝试使用Jetty的HTTP/2客户端而不是浏览器执行测试，则还可以通过调整BufferingFlowControlStrategy.bufferRatio参数来调整何时发送WINDOW_UPDATE帧.
越接近0.0，越早发送WINDOW_UPDATE帧，越接近1.0，越晚发送WINDOW_UPDATE帧.
If you try to perform the test with Jetty's HTTP/2 client rather than the browser, you can also tune when to send WINDOW_UPDATE frames by tuning the BufferingFlowControlStrategy.bufferRatio parameter.
The closer to 0.0, the earlier the WINDOW_UPDATE frame is sent, the closer to 1.0, the later the WINDOW_UPDATE frame is sent.
该测试还应该报告什么是客户端和服务器之间的网络往返，因为这会影响(通常是支配)WINDOW_UPDATE帧从客户端到服务器所花费的时间.
The test should also report what is the network round-trip between client and server, because this affects (often dominates) the amount of time the WINDOW_UPDATE frame takes to go from client to server.
在理想的下载中，您希望客户端足够早地发送WINDOW_UPDATE帧，以便在WINDOW_UPDATE帧到达服务器时，服务器尚未消耗流/会话发送流控制窗口，并且因此它将始终保持打开发送流控制窗口且永不停止.
In a perfect download, you want the client to send the WINDOW_UPDATE frame early enough that by the time the WINDOW_UPDATE frame reaches the server, the server has not yet consumed the stream/session send flow control window, and so it will always have the send flow control window open and never stall.
我不知道浏览器发送WINDOW_UPDATE帧时 的可配置性如何，因此，对于较大的下载量，这可能会损害下载速度.
I don't know how configurable is when the browser sends the WINDOW_UPDATE frames, however, so for large downloads this may hurt the download speed.
您要留意客户端重新配置其会话和流接收流控制窗口的大小以及何时发送WINDOW_UPDATE帧.
You want to keep an eye on how big the client reconfigures its session and stream receive flow control windows, and when it sends WINDOW_UPDATE frames.
最后，另一个可能影响下载速度的参数是所使用的TLS密码. 您的HTTP/1连接所协商的密码可能比HTTP/2所协商的密码弱得多(因为HTTP/2仅需要非常强的密码)，因此即使是非停滞的HTTP/2下载也比HTTP/1的下载速度慢因为加密速度慢.
Lastly, another parameter that may influence download speed is the TLS cipher used. It may happen that your HTTP/1 connection negotiates a much weaker cipher than that negotiated for HTTP/2 (because HTTP/2 requires only very strong ciphers), therefore rendering even a non-stalled HTTP/2 download slower than HTTP/1 just because of encryption slow-down.