HTTP 2協議特性掃盲篇

隨著web技術的飛速發展，2023年制定的http 1.1已經無法滿足大家對效能的要求，google推出協議spdy，旨在解決http 1.1中廣為人知的效能問題。spdy得到了chrome、firefox和opera的支援，很多大型**（如谷歌、twitter、facebook、**）都對相容客戶端使用spdy。spdy在被行業採用並證明能夠大幅提公升效能之後，已經具備了成為乙個標準的條件。

http工作組採用了spdy v2草案作為制定http 2.0標準的起點，2023年12月將http/2標準提議遞交至iesg進行討論，於2023年2月17日被批准。http/2標準於2023年5月以rfc 7540正式發表。至此，spdy完成了歷史的使命，即將退出歷史的舞台，http/2粉墨登場。

在http的語義、http方法、狀態碼、uri和首部欄位等核心概念不變的情況下，http/2實現了效能優化，http/2具體有哪些變化呢？下面一一解答 o(∩_∩)o~

http1.x以換行符作為純文字的分隔符。

http/2將所有傳輸的資訊分割為更小的訊息和幀，並對它們採用二進位制格式的編碼，我們先了解幾個概念：

在http/2中，資料流以訊息的形式傳送，而訊息由乙個或多個幀組成，幀可以在資料流上亂序傳送，然後再根據每個幀首部的流識別符號重新組裝。二進位制分幀是http/2的基石，其他優化都是在這一基礎上來實現的。

這一特性，效能會有極大的提公升，因為：

在http/2中，每個請求都可以帶乙個31bit的優先值，0表示最高優先順序，數值越大優先順序越低。有了這個優先值，客戶端和伺服器就可以在處理不同的流時採取不同的策略，以最優的方式傳送流、訊息和幀。

server push是http/2中乙個很強大的功能：

有了這一特性，我們可以做什麼？

在http 1.x中，這些資訊都是以純文字協議傳送的，給每個請求增加了不小的負荷。

為了減少這塊的開銷並提公升效能， http/2會壓縮這些首部：

例如：下圖中的兩個請求，請求一傳送了所有的頭部字段，第二個請求則只需要傳送差異資料，這樣可以減少冗餘資料，降低開銷。

上圖是是訪問抓到的第乙個請求的頭部，可以看到頭部的內容，總共占用了437 bytes，我們選中頭部的cookie，可以看到cookie總共占用了118 bytes。接下來我們看看第二個請求的頭部：

客戶端、伺服器都需要公升級才能支援http 2.0，公升級過程中就存在http1.1、http 2.0並存的情況，然而他們都使用的80埠，那麼如何來選擇使用什麼協議通訊呢？

apln就是為了解決這個問題的，通過協商來選擇通訊的協議：

客戶端發起請求，如果支援http/2，則帶upgrade頭部:

伺服器不支援，則拒絕公升級，通過http1.1返回響應

伺服器支援，則接受公升級，切換到新分幀，使用http/2通訊。

使用協議協商，無論是哪一種情況，都不需要額外的往返，如果客戶端通過記錄或者其他方式，知道伺服器支援http/2，則直接使用http/2通訊，無需再協議協商。

最後，簡而概之，http/2的通過支援請求與響應的多路復用來減少延遲，通過壓縮http首部欄位將協議開銷降至最低，同時增加對請求優先順序和伺服器端推送的支援。

http/2效能得到了極大的提公升，我們在http 1.1時代做的有些優化反而成了雞肋，在公升級過程中，如何讓http/2 和 http 1.1的使用者都能得到最優的效能，這是對於我們的另外一大挑戰。

HTTP 2協議特性掃盲篇

HTTP 2協議特性掃盲篇

公升級HTTP 2協議

Nginx 支援Http2協議

HTTP 2協議 特性掃盲篇

HTTP 2協議 特性掃盲篇

公升級HTTP 2協議

Nginx 支援Http2協議

相關推薦

HTTP 2協議特性掃盲篇

HTTP 2協議特性掃盲篇