最近有乙個圍繞http/2遷移的重要傳言。從該協議草案被批准時起，我們一直聽到越來越多關於瀏覽器、web伺服器和**新增http/2支援的訊息。網路效能專家鼓勵大家採用新的標準，可以享受到已被經驗證明的速度提公升效果。有很多帖子解釋了http/2是什麼，所以我們將會跳過這一環節，重點關注乙個還未被解決的關鍵問題。
這是乙個舊有的聯網問題，叫做「線端阻塞（holb）」。你可以把它看做車輛管理局辦公室門前排起的長隊，在那裡人們必須嚴格按照次序辦事。「線端」的人是當前正在辦理的那個人，這人可能會阻塞整個等待的隊伍。當乙個需要按順序處理的資料報的佇列，加上各種不同的處理時間、網路延遲或資料報丟失時，我們稱這種問題為holb。
http/2正在通過http請求的多路復用來解決holb問題中的一種。如果我們仍然用車輛管理局來模擬的話，這就像是在為很多人同時辦理。但這怎麼可能呢？車輛管理局的員工不可能同時和所有人說話，對嗎？但是，想象一下，他們說：「在計算機處理你的請求的時候，請站在旁邊等候。請下一位辦理！」。在這個例子中，造成holb現象的原因是計算機的執行速度緩慢，我們從這個方面著手開展工作，通過重新配置計算機執行時間來解決問題，此外，當連線丟失的時候，我們要開始處理乙個新的請求。
http在響應上乙個請求之前往往無法接受新的請求。因此，網路延遲和請求的複雜性決定了其空閒程度。值得注意的是，http/1.1支援流水線操作。但它確實沒有解決這類holb問題，因為乙個需要大量伺服器處理時間的請求仍會阻塞隨後的響應。而有了http/2多路復用技術，情況就與上面的車輛管理局的例子類似了，很多請求和響應可以同時處理。
tcp有一些從holb中恢復的方法，但成本很高——在較為糟糕的情況下，會花費幾秒鐘時間。在**「佇列頭部」片段的過程中至少會發生一次請求——響應往返過程。這些丟失的往返過程會對移動通訊的效能產生巨大影響。
這很可能是谷歌沒停留在spdy（http/2的前身），而繼續試驗quic的原因，他們聲稱這麼做的目標之一就是減少holb現象。還有乙個ietf草案提出修改tcp來應對holb問題的方法。儘管這是乙個公認的問題，但開發人員還一直沒有找到可以欣然採納的解決方案。
有乙個叫salesforce的公司想了個辦法，將乙個http請求和乙個tcp連線分隔開來：把資料傳輸想象成由多個tcp連線（網路環境需要多少個連線就有多少個）組成。http請求的任何一部分都可以對應任何乙個tcp連線。所以，如果你在乙個連線中碰到了holb問題，這種方法不僅可以幫助你減少受影響的請求，它還可以最大程度地降低那些使用健康連線的其他應用程式的請求所受的影響。結果就有了這樣一種能力，使發生holb的風險最小化，同時還能享受多路復用和流水線操作帶來的好處。
http/2是http協議的乙個激動人心的修訂版本。它提供的效能提公升是毫無疑問的。但與此同時，它也帶來了乙個問題，那就是如何最好地使用這些來自現實世界部署中的新功能和經驗，來為我們提供最好的指導！
新年新技術 HTTP 2
新的一年，專案也要帶著發展的眼光往前走，得跟上潮流，當然前提是自己真的用的上。用的上用不上都得先簡單了解下。2月下旬google發布了首個基於http 2的rpc框架grpc，它是基於http 2的，所以先了解下它，後續等深入研究了再回頭說說grpc。http 2基於二進位制而不是文字，二進位制協議...
伺服器如何處理http請求
了解服務端如何處理http請求，了解基本的處理流程 處理http請求分為7個步驟 建立一條tcp鏈結，若之前不存在持久鏈結keep alive 把客戶端的ip和port，服務端的ip和port資料放到web伺服器連線表中。伺服器隨時監聽鏈結表中的鏈結，看有沒有資料變化 一旦我們傳送http請求了，這...
伺服器如何處理http請求
了解服務端如何處理http請求，了解基本的處理流程 處理http請求分為7個步驟 建立一條tcp鏈結，若之前不存在持久鏈結keep alive 把客戶端的ip和port，服務端的ip和port資料放到web伺服器連線表中。伺服器隨時監聽鏈結表中的鏈結，看有沒有資料變化 一旦我們傳送http請求了，這...