「知識拾遺」 http2/http3總結

  • 2019 年 12 月 20 日
  • 筆記

HTTP2的主要特性

  1. H2是一個二進制協議,H1是超文本協議.傳輸的內容都不是一樣的。
  2. H2遵循多路復用即,代替同一host下的內容,只建立一次連接. H1不是。
  3. H2可以使用HPACK進行頭部的壓縮,H1則不論什麼請求都會發送。
  4. H2允許服務器,預先將網頁所需要的資源PUSH到瀏覽器的內存當中。

HTTP2的多路復用

在HTTP1.1的協議中，我們傳輸的request和response都是基本於文本的，這樣就會引發一個問題：所有的數據必須按順序傳輸，比如需要傳輸：hello world，只能從h到d一個一個的傳輸，不能並行傳輸，因為接收端並不知道這些字符的順序，所以並行傳輸在HTTP1.1是不能實現的。

HTTP/2引入二進制數據幀和流的概念，其中幀對數據進行順序標識，這樣瀏覽器收到數據之後，就可以按照序列對數據進行合併，而不會出現合併後數據錯亂的情況。同樣是因為有了序列，服務器就可以並行的傳輸數據，這就是流所做的事情。

HTTP/2對同一域名下所有請求都是基於流，也就是說同一域名不管訪問多少文件，也只建立一路連接。

HTTP2的新特性

  • 新的二進制格式 （Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。
  • 多路復用 （MultiPlexing） 即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裏面。
  • header壓縮 HTTP1.x的header帶有大量信息，而且每次都要重複發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重複header的傳輸，又減小了需要傳輸的大小。
  • 服務端推送 （server push） 同SPDY一樣，HTTP2.0也具有server push功能。目前，有大多數網站已經啟用HTTP2.0，例如 YouTuBe，淘寶網等網站，可以利用chrome控制台可以查看是否啟用H2

SPDY

2012年google如一聲驚雷提出了SPDY的方案，大家才開始從正面看待和解決老版本HTTP協議本身的問題，SPDY可以說是綜合了HTTPS和HTTP兩者優點於一體的傳輸協議，主要解決：

  1. 降低延遲 針對HTTP高延遲的問題，SPDY優雅的採取了多路復用（multiplexing）。多路復用通過多個請求stream共享一個tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時提高了帶寬的利用率。
  2. 請求優先級（request prioritization） 多路復用帶來一個新的問題是，在連接共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先級，這樣重要的請求就會優先得到響應。比如瀏覽器加載首頁，首頁的html內容應該優先展示，之後才是各種靜態資源文件，腳本文件等加載，這樣可以保證用戶能第一時間看到網頁內容。
  3. header壓縮 前面提到HTTP1.x的header很多時候都是重複多餘的。選擇合適的壓縮算法可以減小包的大小和數量。
  4. 基於HTTPS的加密協議傳輸 這大大提高了傳輸數據的可靠性。
  5. 服務端推送（server push） 採用了SPDY的網頁，例如我的網頁有一個sytle.css的請求，在客戶端收到sytle.css數據的同時，服務端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到，不用再發請求了。

SPDY位於HTTP之下，TCP和SSL之上，這樣可以輕鬆兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。

SPDY與HTTP2的區別

  • 頭部壓縮算法，SPDY，通用的deflate算法[注1]；HTTP2，專門為壓縮頭部設計的HPACK算法
  • SPDY必須在TLS上運行，HTTP2可在TCP上直接使用，因為增加了HTTP1.1的Upgrade機制
  • 更加完善的協議商討和確認流程
  • 更加完善的Server Push流程
  • 增加控制幀的種類，並對幀的格式考慮的更細緻

HTTP2的缺點

  1. TCP 以及 TCP+TLS建立連接的延時,HTTP/2使用TCP協議來傳輸的，而如果使用HTTPS的話，還需要使用TLS協議進行安全傳輸，而使用TLS也需要一個握手過程,在傳輸數據之前，導致我們需要花掉 3～4 個 RTT。
  2. TCP的隊頭阻塞並沒有徹底解決。在HTTP/2中，多個請求是跑在一個TCP管道中的。但當HTTP/2出現丟包時，整個 TCP 都要開始等待重傳，那麼就會阻塞該TCP連接中的所有請求。

HTTP3

Google 在推SPDY的時候就已經意識到了這些問題，於是就另起爐灶搞了一個基於 UDP 協議的「QUIC」協議，讓HTTP跑在QUIC上而不是TCP上。主要特性如下：

  • 實現了類似TCP的流量控制、傳輸可靠性的功能。雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎之上增加了一層來保證數據可靠性傳輸。它提供了數據包重傳、擁塞控制以及其他一些TCP中存在的特性
  • 實現了快速握手功能。由於QUIC是基於UDP的，所以QUIC可以實現使用0-RTT或者1-RTT來建立連接，這意味着QUIC可以用最快的速度來發送和接收數據。
  • 集成了TLS加密功能。目前QUIC使用的是TLS1.3，相較於早期版本TLS1.3有更多的優點，其中最重要的一點是減少了握手所花費的RTT個數。
  • 多路復用，徹底解決TCP中隊頭阻塞的問題。

參考資料

  • https://juejin.im/post/5d9abde7e51d4578110dc77f

相關資料

  • https://juejin.im/post/5d9abde7e51d4578110dc77f

VirMach 便宜 VPS

QNews

QNews