解密HTTP/2與HTTP/3 的新特性

阿新 • • 發佈：2020-11-24

前言

HTTP/2 相比於 HTTP/1.1，可以說是大幅度提高了網頁的效能，只需要升級到該協議就可以減少很多之前需要做的效能優化工作，當然相容問題以及如何優雅降級應該是國內還不普遍使用的原因之一。

雖然 HTTP/2 提高了網頁的效能，但是並不代表它已經是完美的了，HTTP/3 就是為了解決 HTTP/2 所存在的一些問題而被推出來的。

一、HTTP/1.1發明以來發生了哪些變化？

如果仔細觀察開啟那些最流行的網站首頁所需要下載的資源的話，會發現一個非常明顯的趨勢。近年來載入網站首頁需要的下載的資料量在逐漸增加，並已經超過了2100K。但在這裡我們更應該關心的是：平均每個頁面為了完成顯示與渲染所需要下載的資源數已經超過了100個。

正如下圖所示，從2011年以來,傳輸資料大小與平均請求資源數量不斷持續增長，並沒有減緩的跡象。該圖表中綠色直線展示了傳輸資料大小的增長，紅色直線展示了平均請求資源數量的增長。

HTTP/1.1自從1997年釋出以來，我們已經使用HTTP/1.x 相當長一段時間了，但是隨著近十年網際網路的爆炸式發展，從當初網頁內容以文字為主,到現在以富媒體（如圖片、聲音、視訊）為主,而且對頁面內容實時性高要求的應用越來越多(比如聊天、視訊直播),於是當時協議規定的某些特性，已經無法滿足現代網路的需求了。

二、HTTP/1.1的缺陷

1.高延遲--帶來頁面載入速度的降低

雖然近幾年來網路頻寬增長非常快，然而我們卻並沒有看到網路延遲有對應程度的降低。網路延遲問題主要由於隊頭阻塞(Head-Of-Line Blocking),導致頻寬無法被充分利用

。

隊頭阻塞是指當順序傳送的請求序列中的一個請求因為某種原因被阻塞時，在後面排隊的所有請求也一併被阻塞，會導致客戶端遲遲收不到資料。針對隊頭阻塞,人們嘗試過以下辦法來解決:

將同一頁面的資源分散到不同域名下，提升連線上限。Chrome有個機制，對於同一個域名，預設允許同時建立 6 個 TCP持久連線，使用持久連線時，雖然能公用一個TCP管道，但是在一個管道中同一時刻只能處理一個請求，在當前的請求沒有結束之前，其他的請求只能處於阻塞狀態。另外如果在同一個域名下同時有10個請求發生，那麼其中4個請求會進入排隊等待狀態，直至進行中的請求完成。
Spriting合併多張小圖為一張大圖,再用JavaScript或者css將小圖重新“切割”出來的技術。

內聯(Inlining)是另外一種防止傳送很多小圖請求的技巧，將圖片的原始資料嵌入在css檔案裡面的URL裡，減少網路請求次數。

.icon1 {
    background: url(data:image/png;base64,<data>) no-repeat;
  }
.icon2 {
    background: url(data:image/png;base64,<data>) no-repeat;
  }

拼接(Concatenation)將多個體積較小的JavaScript使用webpack等工具打包成1個體積更大的JavaScript檔案,但如果其中1個檔案的改動就會導致大量資料被重新下載多個檔案。

2.無狀態特性--帶來的巨大HTTP頭部

由於報文Header一般會攜帶"User Agent""Cookie""Accept""Server"等許多固定的頭欄位（如下圖），多達幾百位元組甚至上千位元組，但Body卻經常只有幾十位元組（比如GET請求、
204/301/304響應），成了不折不扣的“大頭兒子”。Header裡攜帶的內容過大，在一定程度上增加了傳輸的成本。更要命的是，成千上萬的請求響應報文裡有很多欄位值都是重複的，非常浪費。

3.明文傳輸--帶來的不安全性

HTTP/1.1在傳輸資料時，所有傳輸的內容都是明文，客戶端和伺服器端都無法驗證對方的身份，這在一定程度上無法保證資料的安全性。

你有沒有聽說過"免費WiFi陷阱”之類的新聞呢？
黑客就是利用了HTTP明文傳輸的缺點，在公共場所架設一個WiFi熱點開始“釣魚”，誘騙網民上網。一旦你連上了這個WiFi熱點，所有的流量都會被截獲儲存，裡面如果有銀行卡號、網站密碼等敏感資訊的話那就危險了，黑客拿到了這些資料就可以冒充你為所欲為。

4.不支援伺服器推送訊息

三、SPDY 協議與 HTTP/2 簡介

1.SPDY 協議

上面我們提到,由於HTTP/1.x的缺陷，我們會引入雪碧圖、將小圖內聯、使用多個域名等等的方式來提高效能。不過這些優化都繞開了協議，直到2009年，谷歌公開了自行研發的 SPDY 協議，主要解決HTTP/1.1效率不高的問題。谷歌推出SPDY，才算是正式改造HTTP協議本身。降低延遲，壓縮header等等，SPDY的實踐證明了這些優化的效果，也最終帶來HTTP/2的誕生。

HTTP/1.1有兩個主要的缺點：安全不足和效能不高，由於揹負著 HTTP/1.x 龐大的歷史包袱,所以協議的修改,相容性是首要考慮的目標，否則就會破壞網際網路上無數現有的資產。如上圖所示,
SPDY位於HTTP之下，TCP和SSL之上，這樣可以輕鬆相容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。

SPDY 協議在Chrome瀏覽器上證明可行以後，就被當作 HTTP/2 的基礎，主要特性都在 HTTP/2 之中得到繼承。

2.HTTP/2 簡介

2015年，HTTP/2 釋出。HTTP/2是現行HTTP協議（HTTP/1.x）的替代，但它不是重寫，HTTP方法/狀態碼/語義都與HTTP/1.x一樣。HTTP/2基於SPDY，專注於效能，最大的一個目標是在使用者和網站間只用一個連線（connection）。從目前的情況來看，國內外一些排名靠前的站點基本都實現了HTTP/2的部署，使用HTTP/2能帶來20%~60%的效率提升。

HTTP/2由兩個規範（Specification）組成：

Hypertext Transfer Protocol version 2 - RFC7540
HPACK - Header Compression for HTTP/2 - RFC7541

四、HTTP/2 新特性

1.二進位制傳輸

HTTP/2傳輸資料量的大幅減少,主要有兩個原因:以二進位制方式傳輸和Header 壓縮。我們先來介紹二進位制傳輸,HTTP/2 採用二進位制格式傳輸資料，而非HTTP/1.x 裡純文字形式的報文，二進位制協議解析起來更高效。HTTP/2 將請求和響應資料分割為更小的幀，並且它們採用二進位制編碼。

它把TCP協議的部分特性挪到了應用層，把原來的"Header+Body"的訊息"打散"為數個小片的二進位制"幀"(Frame),用"HEADERS"幀存放頭資料、"DATA"幀存放實體資料。HTP/2資料分幀後"Header+Body"的報文結構就完全消失了，協議看到的只是一個個的"碎片"。

HTTP/2 中，同域名下所有通訊都在單個連線上完成，該連線可以承載任意數量的雙向資料流。每個資料流都以訊息的形式傳送，而訊息又由一個或多個幀組成。多個幀之間可以亂序傳送，根據幀首部的流標識可以重新組裝。

2.Header 壓縮

HTTP/2並沒有使用傳統的壓縮演算法，而是開發了專門的"HPACK”演算法，在客戶端和伺服器兩端建立“字典”，用索引號表示重複的字串，還採用哈夫曼編碼來壓縮整數和字串，可以達到50%~90%的高壓縮率。

具體來說:

在客戶端和伺服器端使用“首部表”來跟蹤和儲存之前傳送的鍵-值對，對於相同的資料，不再通過每次請求和響應傳送；
首部表在HTTP/2的連線存續期內始終存在，由客戶端和伺服器共同漸進地更新;
每個新的首部鍵-值對要麼被追加到當前表的末尾，要麼替換表中之前的值

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

3.多路複用

在 HTTP/2 中引入了多路複用的技術。多路複用很好的解決了瀏覽器限制同一個域名下的請求數量的問題，同時也接更容易實現全速傳輸，畢竟新開一個 TCP 連線都需要慢慢提升傳輸速度。

大家可以通過該連結直觀感受下 HTTP/2 比 HTTP/1 到底快了多少。在 HTTP/2 中，有了二進位制分幀之後，HTTP /2 不再依賴 TCP 連結去實現多流並行了，在 HTTP/2中,

同域名下所有通訊都在單個連線上完成。
單個連線可以承載任意數量的雙向資料流。
資料流以訊息的形式傳送，而訊息又由一個或多個幀組成，多個幀之間可以亂序傳送，因為根據幀首部的流標識可以重新組裝。

這一特性，使效能有了極大提升：

同個域名只需要佔用一個 TCP 連線，使用一個連線並行傳送多個請求和響應,這樣整個頁面資源的下載過程只需要一次慢啟動，同時也避免了多個TCP連線競爭頻寬所帶來的問題。
並行交錯地傳送多個請求/響應，請求/響應之間互不影響。
在HTTP/2中，每個請求都可以帶一個31bit的優先值，0表示最高優先順序，數值越大優先順序越低。有了這個優先值，客戶端和伺服器就可以在處理不同的流時採取不同的策略，以最優的方式傳送流、訊息和幀。

如上圖所示，多路複用的技術可以只通過一個 TCP 連線就可以傳輸所有的請求資料。

4.Server Push

HTTP2還在一定程度上改變了傳統的“請求-應答”工作模式，伺服器不再是完全被動地響應請求，也可以新建“流”主動向客戶端傳送訊息。比如，在瀏覽器剛請求html的時候就提前把可能會用到的js、CSS檔案發給客戶端，減少等待的延遲，這被稱為"伺服器推送"（ Server Push，也叫 Cache push）

例如下圖所示,服務端主動把js和CSS檔案推送給客戶端，而不需要客戶端解析html時再發送這些請求。

另外需要補充的是,服務端可以主動推送，客戶端也有權利選擇是否接收。如果服務端推送的資源已經被瀏覽器快取過，瀏覽器可以通過傳送RST_STREAM幀來拒收。主動推送也遵守同源策略，換句話說，伺服器不能隨便將第三方資源推送給客戶端，而必須是經過雙方確認才行。

5.提高安全性

出於相容的考慮，HTTP/2延續了HTTP/1的“明文”特點，可以像以前一樣使用明文傳輸資料，不強制使用加密通訊，不過格式還是二進位制，只是不需要解密。

但由於HTTPS已經是大勢所趨，而且主流的瀏覽器Chrome、Firefox等都公開宣佈只支援加密的HTTP/2，所以“事實上”的HTTP/2是加密的。也就是說，網際網路上通常所能見到的HTTP/2都是使用"https”協議名，跑在TLS上面。HTTP/2協議定義了兩個字串識別符號：“h2"表示加密的HTTP/2，“h2c”表示明文的HTTP/2。

PPT模板下載大全https://redbox.wode007.com

六、HTTP/3 新特性

1.HTTP/2 的缺點

雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，主要是底層支撐的 TCP 協議造成的。HTTP/2的缺點主要有以下幾點：

TCP 以及 TCP+TLS建立連線的延時

HTTP/2使用TCP協議來傳輸的，而如果使用HTTPS的話，還需要使用TLS協議進行安全傳輸，而使用TLS也需要一個握手過程，這樣就需要有兩個握手延遲過程：

①在建立TCP連線的時候，需要和伺服器進行三次握手來確認連線成功，也就是說需要在消耗完1.5個RTT之後才能進行資料傳輸。

②進行TLS連線，TLS有兩個版本——TLS1.2和TLS1.3，每個版本建立連線所花的時間不同，大致是需要1~2個RTT。

總之，在傳輸資料之前，我們需要花掉 3～4 個 RTT。

TCP的隊頭阻塞並沒有徹底解決

上文我們提到在HTTP/2中，多個請求是跑在一個TCP管道中的。但當出現了丟包時，HTTP/2 的表現反倒不如 HTTP/1 了。因為TCP為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認，HTTP/2出現丟包時，整個 TCP 都要開始等待重傳，那麼就會阻塞該TCP連線中的所有請求（如下圖）。而對於 HTTP/1.1 來說，可以開啟多個 TCP 連線，出現這種情況反到只會影響其中一個連線，剩餘的 TCP 連線還可以正常傳輸資料。

讀到這裡，可能就會有人考慮為什麼不直接去修改 TCP 協議？其實這已經是一件不可能完成的任務了。因為 TCP 存在的時間實在太長，已經充斥在各種裝置中，並且這個協議是由作業系統實現的，更新起來不大現實。

2.HTTP/3簡介

Google 在推SPDY的時候就已經意識到了這些問題，於是就另起爐灶搞了一個基於 UDP 協議的“QUIC”協議，讓HTTP跑在QUIC上而不是TCP上。
而這個“HTTP over QUIC”就是HTTP協議的下一個大版本，HTTP/3。它在HTTP/2的基礎上又實現了質的飛躍，真正“完美”地解決了“隊頭阻塞”問題。

QUIC 雖然基於 UDP，但是在原本的基礎上新增了很多功能，接下來我們重點介紹幾個QUIC新功能。不過HTTP/3目前還處於草案階段，正式釋出前可能會有變動，所以本文儘量不涉及那些不穩定的細節。

3.QUIC新功能

上面我們提到QUIC基於UDP，而UDP是“無連線”的，根本就不需要“握手”和“揮手”，所以就比TCP來得快。此外QUIC也實現了可靠傳輸，保證資料一定能夠抵達目的地。它還引入了類似HTTP/2的“流”和“多路複用”，單個“流"是有序的，可能會因為丟包而阻塞，但其他“流”不會受到影響。具體來說QUIC協議有以下特點：

實現了類似TCP的流量控制、傳輸可靠性的功能。

雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎之上增加了一層來保證資料可靠性傳輸。它提供了資料包重傳、擁塞控制以及其他一些TCP中存在的特性。

實現了快速握手功能。

由於QUIC是基於UDP的，所以QUIC可以實現使用0-RTT或者1-RTT來建立連線，這意味著QUIC可以用最快的速度來發送和接收資料，這樣可以大大提升首次開啟頁面的速度。0RTT 建連可以說是 QUIC 相比 HTTP2 最大的效能優勢。

集成了TLS加密功能。

目前QUIC使用的是TLS1.3，相較於早期版本TLS1.3有更多的優點，其中最重要的一點是減少了握手所花費的RTT個數。

多路複用，徹底解決TCP中隊頭阻塞的問題

和TCP不同，QUIC實現了在同一物理連線上可以有多個獨立的邏輯資料流（如下圖）。實現了資料流的單獨傳輸，就解決了TCP中隊頭阻塞的問題。

七、總結

HTTP/1.1有兩個主要的缺點：安全不足和效能不高。
HTTP/2完全相容HTTP/1，是“更安全的HTTP、更快的HTTPS"，頭部壓縮、多路複用等技術可以充分利用頻寬，降低延遲，從而大幅度提高上網體驗；
QUIC 基於 UDP 實現，是 HTTP/3 中的底層支撐協議，該協議基於 UDP，又取了 TCP 中的精華，實現了即快又可靠的協議