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慢只是因爲加密速度變慢。