HTTP/2技術解密：如何處理線端阻塞

最近，圍繞HTTP/2遷移的話題眾說紛紜。從該協議草案被批準時起，就聽到越來越多關於瀏覽器、web伺服器和網站支持添加HTTP/2的各種消息。網路安全專家倡議大家採取新的標準，提升網路訪問的速度。

HTTP/2是什麼

HTTP 2.0即超文本傳輸協議 2.0，是下一代HTTP協議。是由互聯網工程任務組（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小組進行開發。是自1999年http1.1發布後的首個更新。HTTP 2.0在2013年8月進行首次合作共事性測試。在開放互聯網上HTTP 2.0將只用於https://網址，而 http://網址將繼續使用HTTP/1，目的是在開放互聯網上增加使用加密技術，以提供強有力的保護去遏制主動攻擊。

「線端阻塞（HOLB）」是一個存在已久的網路問題，其問題程度可與車管所辦理相關業務相比，人們必須嚴格按照次序辦事。「線端」的人是當前正在辦理的那個人，可能會阻塞整個等待的隊伍。當一個需要按順序處理數據包的隊列，加上各種不同的處理時間、網路延遲或數據包丟失時，這種問題為HOLB。

HTTP/2是通過復用HTTP請求用來解決HOLB問題中的一種。如果仍然用車管所來模擬的話，就像是在為很多人同時辦理，車管所的員工不可能同時和所有人說話。但是，想像一下，他們說：「在計算機處理用戶請求的時候，請站在旁邊等候。請下一位辦理！」。在這個例子中，造成HOLB現象的原因是計算機的運行速度緩慢，從這個方面著手開展工作，通過重新配置計算機運行時間來解決問題，此外，當連接丟失的時候，就要開始處理一個新的請求。

HTTP在響應上一個請求之前往往無法接受新的請求。因此，網路延遲和請求的複雜性決定了其空閑程度。值得注意的是，HTTP/1.1支持流水線操作。但它確實沒有解決這類HOLB問題，因為一個需要大量伺服器處理時間的請求仍會阻塞隨後的響應。而有了HTTP/2多路復用技術，情況就與上面的車輛管理局的例子類似了，很多請求和響應可以同時處理。

那麼HTTP/2是否解決了HOLB問題呢？

答案是「是，也不是」。因為，HOLB有兩個問題：一個在HTTP層面，另一個在TCP層面。正像HTTP伺服器處理請求一樣，TCP協議也必須處理數據包，並確保按順序接收所有位元組，這樣HTTP才能使用這些數據。一個對應多個應用程序請求的數據包隊列，如果這個隊伍的開頭，一個數據包延遲或丟失，將會在TCP層面對HOLB問題，HTTP/2是在HTTP層面解決了這個問題。但是，它仍處於與HTTP/1.1相同的TCP協議的上層，所以它無法解決TCP的HOLB問題。甚至情況變得更糟糕，因為流水線操作/多路復用功能的存在，使用HTTP/2的應用程序可以通過一個單獨的TCP連接發送更多請求。網路延遲的令人超乎想像，巨大的變化範圍或影響TCP隊列頭部片段的連接丟失，使得HTTP/2更有可能解決HOLB。基本上，在頭部恢復之前，接收方會一直處於空閑狀態，而隨後的所有數據片段都由TCP協議來處理。這意味著，一張圖片可能已經下載成功，但由於HOLB的原因而仍然無法顯示。

TCP有一些從HOLB中恢復的方法，但成本很高——一般情況下，會花費幾秒鐘時間。在轉發「隊列頭部」片段的過程中至少會發生一次請求——響應往返過程。這些丟失的往返過程會對移動通信的性能產生巨大影響。

很可能是谷歌沒停留在SPDY（HTTP/2的前身），而繼續試驗QUIC的原因，他們聲稱這麼做的目標之一就是減少HOLB現象。還有一個IETF草案提出修改TCP來應對HOLB問題的方法。儘管這是一個公認的問題，但開發人員還一直沒有找到可以欣然採納的解決方案。

國外Salesforce的公司想了一個辦法，將一個HTTP請求和一個TCP連接分隔開來：把數據傳輸想像成由多個TCP連接（網路環境需要多少個連接就有多少個）組成。HTTP請求的任何一部分都可以對應任何一個TCP連接。所以，如果在一個連接中碰到了HOLB問題，這種方法不僅可以幫助減少受影響的請求，它還可以最大程度地降低那些使用健康連接的其他應用程序的請求所受的影響。結果就有了這樣一種能力，使發生HOLB的風險最小化，同時還能享受多路復用和流水線操作帶來的好處。

HTTP/2是HTTP協議的一個激動人心的修訂版本。它提供的性能提升是毫無疑問的。但與此同時，它也帶來了一個問題，那就是如何最好地使用這些來自現實世界部署中的新功能和經驗，來提供最好的指導！

稿源：Medium.com

文章轉載：https://www.trustauth.cn/wiki/18781.html

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！