為什麼我們啟用HTTP/2時發生問題？ - Lucidchart

banq發表於2019-04-23
HTTP

HTTP 2是HTTP的一次重大飛躍。它透過對報頭使用二進位制壓縮格式來提高頻寬效率，透過在同一TCP連線上覆用請求來減少延遲，並允許客戶端指定請求的優先順序。在許多情況下，遷移到HTTP / 2是正確的做法，但對於某些應用程式，HTTP / 2可能會導致嚴重的問題。
去年，在Lucidchart，我們在部分服務的負載均衡器上啟用了HTTP / 2。此後不久，我們注意到HTTP / 2負載均衡器背後的伺服器比其他伺服器具有更高的CPU負載和更慢的響應時間。起初，原因尚不清楚，因為伺服器流量看似正常，問題似乎與任何程式碼更改無關。仔細觀察後，我們意識到請求的平均數量與通常相同，但實際請求流量變得更加集中：我們發現了大量請求的短暫爆發，而不是穩定的請求流。雖然我們根據以前的流量模式過度配置了容量，但僅僅處理這些新的請求峰值還是不夠，因此對請求的響應被延遲並超時。
這裡發生了什麼呢？好吧，大多數瀏覽器限制到指定源的併發連線數（方案，主機和埠的組合），並且必須在單個連線上序列處理HTTP / 1.1連線。這意味著HTTP / 1.1瀏覽器有效地限制了對該源的併發請求數，這意味著我們的使用者瀏覽器會限制對我們伺服器的請求並保持流量順暢。
還記得我說HTTP / 2如何新增多路複用？好吧，使用HTTP / 2，瀏覽器現在可以透過單個連線同時傳送所有HTTP請求。從Web客戶端的角度來看，這很棒。從理論上講，客戶端應該更快地獲得所需的所有資源，因為在發出其他請求之前，它不再需要等待來自伺服器的響應。但是，在實踐中，多路複用大大增加了我們伺服器的壓力。
首先，因為他們大批次地而不是更小，更分散批次的接受請求；其次，因為使用HTTP / 2，請求全部一起傳送 - 而不是像HTTP / 1.1那樣交錯傳送 - 因此它們的開始時間更接近，這意味著它們都可能超時。

如何解決它
幸運的是，可以在不增加計算能力的情況下解決此問題。實際上，有一些潛在的解決方案，儘管它們比在負載均衡器中啟用HTTP / 2需要更多的努力。

1. 負載平衡器上的節流閥
也許最明顯的解決方案是讓負載均衡器對應用程式伺服器進行節流請求，因此從應用程式伺服器的角度來看，流量模式與使用HTTP / 1.1時的流量模式類似。所需的難度取決於您的基礎設施。
即使使用像HAProxy和Nginx這樣的負載平衡器，獲得正確的節流也會非常棘手。如果負載均衡器不支援限制，您仍然可以在負載均衡器和應用程式伺服器之間放置反向代理，並在那裡進行限制。

2.重新構建應用程式以更好地處理尖鋒請求
另一個（也許更好）選項是更改應用程式，以便它可以處理來自接受HTTP / 2流量的負載均衡器的流量。根據應用程式的不同，這可能涉及嚮應用程式引入或調整排隊機制，以便它可以接受連線，但一次只處理有限數量的連線。當我們切換到HTTP / 2時，我們實際上已經有了一個排隊機制，但由於之前的一些程式碼決策，我們沒有正確地限制併發請求處理。如果您執行佇列請求，則應該注意不要在客戶端等待響應超時後處理請求 - 不需要浪費不必要的資源。
在開啟HTTP / 2之前，請確保您的應用程式可以處理兩者的差異：HTTP / 2具有與HTTP / 1.1不同的流量模式。
您的應用程式可能是專門為HTTP / 1.1模式設計的，無論是否有意。HTTP / 2有很多好處，但是如果你不小心的話，它也有一些差別可以咬你。

後記
需要注意的另一個“問題”是支援HTTP / 2的軟體尚未完全成熟。雖然它一直在變得越來越好，但HTTP / 2的軟體還沒有足夠的時間來變得像現有的HTTP / 1.1軟體一樣成熟和穩固。
特別是，HTTP優先順序的伺服器支援充其量只是參差不齊。許多CDN和負載均衡器根本不支援它，或者有錯誤的實現，即使它們這樣做，緩衝也會限制其有效性。
此外，多個應用程式僅透過HTTPS支援HTTP / 2。從安全形度來看，這很棒。但是，它使得在不同元件之間不需要或不需要TLS的安全網路內的開發和除錯變得複雜。這意味著您需要為localhost管理CA和證書以進行本地開發，記錄會話機密以便使用Wireshark或類似工具檢查HTTP / 2請求，並且可能需要額外的計算資源進行加密。

相關文章