一文讀懂 HTTP/2 特性

HTTP/2 是 HTTP 協議自 1999 年 HTTP 1.1 發佈後的首個更新,主要基於 SPDY 協議。由互聯網工程任務組(IETF)的 Hypertext Transfer Protocol Bis(httpbis)工做小組進行開發。該組織於2014年12月將HTTP/2標準提議遞交至IESG進行討論,於2015年2月17日被批准。HTTP/2標準於2015年5月以RFC 7540正式發表。html

那 HTTP/2 到底有哪些具體變化呢?git

二進制分幀

先來理解幾個概念:github

幀:HTTP/2 數據通訊的最小單位消息:指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應等,消息由一個或多個幀組成。瀏覽器

流:存在於鏈接中的一個虛擬通道。流能夠承載雙向消息,每一個流都有一個惟一的整數ID。緩存

HTTP/2 採用二進制格式傳輸數據,而非 HTTP 1.x 的文本格式,二進制協議解析起來更高效。 HTTP / 1 的請求和響應報文,都是由起始行,首部和實體正文(可選)組成,各部分之間以文本換行符分隔。HTTP/2 將請求和響應數據分割爲更小的幀,而且它們採用二進制編碼。服務器

HTTP/2 中,同域名下全部通訊都在單個鏈接上完成,該鏈接能夠承載任意數量的雙向數據流。每一個數據流都以消息的形式發送,而消息又由一個或多個幀組成。多個幀之間能夠亂序發送,根據幀首部的流標識能夠從新組裝。cookie

多路複用

多路複用,代替原來的序列和阻塞機制。全部就是請求的都是經過一個 TCP鏈接併發完成。 HTTP 1.x 中,若是想併發多個請求,必須使用多個 TCP 連接,且瀏覽器爲了控制資源,還會對單個域名有 6-8個的TCP連接請求限制,以下圖,紅色圈出來的請求就因域名連接數已超過限制,而被掛起等待了一段時間:網絡

在 HTTP/2 中,有了二進制分幀以後,HTTP /2 再也不依賴 TCP 連接去實現多流並行了,在 HTTP/2中:併發

  • 同域名下全部通訊都在單個鏈接上完成。
  • 單個鏈接能夠承載任意數量的雙向數據流。
  • 數據流以消息的形式發送,而消息又由一個或多個幀組成,多個幀之間能夠亂序發送,由於根據幀首部的流標識能夠從新組裝。

這一特性,使性能有了極大提高:性能

  • 同個域名只須要佔用一個 TCP 鏈接,消除了因多個 TCP 鏈接而帶來的延時和內存消耗。
  • 單個鏈接上能夠並行交錯的請求和響應,之間互不干擾。
  • 在HTTP/2中,每一個請求均可以帶一個31bit的優先值,0表示最高優先級, 數值越大優先級越低。有了這個優先值,客戶端和服務器就能夠在處理不一樣的流時採起不一樣的策略,以最優的方式發送流、消息和幀。

服務器推送

服務端能夠在發送頁面HTML時主動推送其它資源,而不用等到瀏覽器解析到相應位置,發起請求再響應。例如服務端能夠主動把JS和CSS文件推送給客戶端,而不須要客戶端解析HTML時再發送這些請求。

服務端能夠主動推送,客戶端也有權利選擇是否接收。若是服務端推送的資源已經被瀏覽器緩存過,瀏覽器能夠經過發送RST_STREAM幀來拒收。主動推送也遵照同源策略,服務器不會隨便推送第三方資源給客戶端。

頭部壓縮

HTTP 1.1請求的大小變得愈來愈大,有時甚至會大於TCP窗口的初始大小,由於它們須要等待帶着ACK的響應回來之後才能繼續被髮送。HTTP/2對消息頭採用HPACK(專爲http/2頭部設計的壓縮格式)進行壓縮傳輸,可以節省消息頭佔用的網絡的流量。而HTTP/1.x每次請求,都會攜帶大量冗餘頭信息,浪費了不少帶寬資源。

HTTP每一次通訊都會攜帶一組頭部,用於描述此次通訊的的資源、瀏覽器屬性、cookie等,例如

爲了減小這塊的資源消耗並提高性能, HTTP/2對這些首部採起了壓縮策略:

  • HTTP/2在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵-值對,對於相同的數據,再也不經過每次請求和響應發送;
  • 首部表在HTTP/2的鏈接存續期內始終存在,由客戶端和服務器共同漸進地更新;
  • 每一個新的首部鍵-值對要麼被追加到當前表的末尾,要麼替換表中以前的值。

例如:下圖中的兩個請求, 請求一發送了全部的頭部字段,第二個請求則只須要發送差別數據,這樣能夠減小冗餘數據,下降開銷。

咱們來看一個實際的例子,下面是用WireShark抓取的訪問google首頁的包: 

上圖是是訪問 抓到的第一個請求的頭部,能夠看到頭部的內容,總共佔用了437 bytes,咱們選中頭部的cookie,能夠看到cookie總共佔用了118 bytes。接下來咱們看看第二個請求的頭部:

從上圖能夠看到,得益於頭部壓縮,第二個請求中cookie只佔用了1個字節,咱們來看看變化了的Accept字段: 

因爲Accept字段與請求一中的內容不一樣,須要發送給服務器,因此佔用了29 bytes。

相關推薦

瀏覽器和網絡服務支持狀況:http2支持清單

如何快速啓用HTTP2: 又拍雲文檔中心

HTTP/2 和 HTTP/1 速度對比:HTTP/2: the Future of the Internet

結語

HTTP/2的經過支持請求與響應的多路複用來減小延遲,經過壓縮HTTP首部字段將協議開銷降至最低,同時增長對請求優先級和服務器端推送的支持。

參考資料:

    1. Jerry Qu blog 中的HTTP/2專題;
    2. 維基百科:HTTP/2
    3. RFC 7540 – 超文本傳輸協議第2版(HTTP / 2)
    4. FC 7541 – HPACK:HTTP / 2的頭壓縮
    5. http2講解
相關文章
相關標籤/搜索