[[420793]]

Hey guys ，各位小伙伴們大家好，這里是程序員 cxuan，歡迎你收看我最新一期的文章。

這篇文章我們來聊一聊 HTTP 2.0，以及 HTTP 2.0 它在 HTTP 1.1 的基礎(chǔ)上做了哪些改變，以及 HTTP 2.0 都有哪些特征，那么廢話不多說，下面開始本篇文章。

最初的 HTTP

HTTP 剛剛誕生之初只用于 web 端的內(nèi)容獲取，一般就是用于頁面訪問，那個時候的頁面內(nèi)容還不如現(xiàn)在這樣豐富，交互場景也不是很多，也沒有龐大繁雜的 CSS、JS ，頁面加載速度非常快。但是隨著 web 2.0 的出現(xiàn)以及更多的內(nèi)容被展示、更精美的排版、更多的用戶交互場景一起出現(xiàn)，導(dǎo)致頁面的內(nèi)容越來越大，使得頁面加載速度越來越慢。

HTTP 的瓶頸

影響一個 HTTP 網(wǎng)絡(luò)請求的因素主要有兩個：帶寬和延遲。

首先來說一下帶寬，如果我們還停留在撥號上網(wǎng)階段的話，帶寬很容易出現(xiàn)瓶頸，因為單位時間內(nèi)傳輸?shù)臄?shù)據(jù)量很小。但是現(xiàn)在隨著光纖等通信技術(shù)的不斷發(fā)展，10Mbps、100Mbps、甚至 1000 Mbps 進入了每個家庭，我們不用再擔(dān)心帶寬成為網(wǎng)絡(luò)請求的瓶頸了。

那么剩下的就只剩下延遲了。

延遲主要有下面三個方面：

• 瀏覽器阻塞(HOL blocking)：瀏覽器會因為一些原因阻塞請求。瀏覽器對于同一個域名，同時只能有 4 個連接(這個根據(jù)瀏覽器內(nèi)核不同可能會有所差異)，超過瀏覽器最大連接數(shù)限制，后續(xù)請求就會被阻塞。
• DNS 查詢(DNS Lookup)：瀏覽器需要知道目標(biāo)服務(wù)器的 IP 才能建立連接。將域名解析為 IP 的這個系統(tǒng)就是 DNS。這個通?？梢岳?DNS 緩存結(jié)果來達到減少這個時間的目的。
• 建立連接(Initial connection)：HTTP 是基于 TCP 協(xié)議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的建立連接，但是這些連接無法復(fù)用會導(dǎo)致每次請求都經(jīng)歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。

HTTP 1.0 有一個被抱怨最多的是連接無法復(fù)用，當(dāng)每次有新的請求時都會重新經(jīng)歷一次三次握手和四次揮手過程，并且連接的建立和釋放需要耗費大量的服務(wù)器資源，在請求少的頁面還尚能應(yīng)對，不過隨著請求的不斷增多，HTTP 1.0 越來越難頂。

不過，HTTP 1.0 協(xié)議頭里可以設(shè)置 Connection:Keep-Alive。在 header 里設(shè)置 Keep-Alive 可以在一定時間內(nèi)復(fù)用連接，具體復(fù)用時間的長短可以由服務(wù)器控制，一般在 15s 左右。到 HTTP 1.1 之后 Connection 的默認值就是Keep-Alive，如果要關(guān)閉連接復(fù)用需要顯式的設(shè)置 Connection:Close。

HTTP 還有一個被抱怨最多的問題就是它的隊頭阻塞(head of blocking)，隊頭阻塞問題會導(dǎo)致帶寬無法充分利用，導(dǎo)致后續(xù)的請求被阻塞。

假如有五個請求被同時發(fā)出，如果第一個請求沒有處理完成，就會導(dǎo)致后續(xù)的請求也無法得到處理，如下圖所示

如果第一個請求沒有被處理，那么 2 3 4 5 這四個請求會直接阻塞在客戶端，等到請求 1 被處理完畢后，才能逐個發(fā)出。網(wǎng)絡(luò)通暢的時候性能影響不大，不過一旦請求 1 因為某些原因沒有抵達服務(wù)器，或者請求因為網(wǎng)絡(luò)阻塞沒有及時返回，影響的就是所有后續(xù)請求，導(dǎo)致后續(xù)請求無限阻塞下去，問題就變得比較嚴(yán)重了。

不過在 HTTP 1.1 中，也提出了**流水線(pipelining)**的設(shè)計，pipelining 就被用來解決隊頭阻塞的問題，如下圖所示

雖然這種流水線的設(shè)計乍一看像是能夠解決阻塞問題，因為右圖中這三個請求沒有等到響應(yīng)到達后再進行發(fā)送，而是直接依次發(fā)送，但是實際上，并不是那么回事。

pipelining 并不是救世主，它也存在不少缺陷：

因為只有冪等的請求比如 GET、HEAD 才能使用 pipelining ，非冪等請求比如 POST 則不能使用，因為請求之間可能存在先后依賴關(guān)系。

其實隊頭阻塞問題并沒有完全解決，因為服務(wù)器返回的響應(yīng)還是要依次返回，也就是返回的請求時 FIFO - 先發(fā)先回。

絕大多數(shù) HTTP 代理服務(wù)器不支持 pipelining。

和不支持 pipelining 的老服務(wù)器協(xié)商有問題。

正是因為有這么多的問題，各大瀏覽器廠商要么是根本就不支持 pipelining，要么就是默認關(guān)掉了 pipelining 機制，而且啟用的條件十分苛刻。

SPDY

雖然 HTTP1.0 和 HTTP 1.1 存在這么多問題，業(yè)界也是想出了各種優(yōu)化手段，但是這些手段怎么說呢，都是治標(biāo)不治本，直到 2020 年 Google 提出了 SPDY 的方案，大家才開始從正面看待和解決老版本 HTTP 協(xié)議本身的問題，這也直接加速了 HTTP 2.0 的誕生。

我們先來聊一下 SPDY 是什么，它都有哪些特點?

認識 SPDY

SPDY 的目標(biāo)在于解決 HTTP 的缺陷，即延遲和安全性。我們上面一直在討論延遲，至于安全性，雖然我們上面沒有具體聊，不過 HTTP 的明文傳輸確是個問題。如果以降低延遲為目標(biāo)，應(yīng)用層的 HTTP 和傳輸層的 TCP 都是都有調(diào)整的空間，不過 TCP 作為更底層協(xié)議存在已達數(shù)十年之久，其實現(xiàn)已深植全球的網(wǎng)絡(luò)基礎(chǔ)設(shè)施當(dāng)中，如果要動必然傷經(jīng)動骨，業(yè)界響應(yīng)度必然不高，所以 SPDY 的手術(shù)刀對準(zhǔn)的是 HTTP 。

降低延遲，客戶端的單連接單請求，服務(wù)端的 FIFO 響應(yīng)隊列都是延遲的大頭。

HTTP 最初設(shè)計都是客戶端發(fā)起請求，然后服務(wù)端進行響應(yīng)，服務(wù)端無法主動發(fā)送內(nèi)容到客戶端。

壓縮 HTTP header，HTTP 1.x 的 header 越來越膨脹，cookie 和 user agent 很容易讓 header 的 size 增至1kb 大小甚至更多。而且由于 HTTP 的無狀態(tài)特性，header 必須每次請求都重復(fù)攜帶，很浪費流量。

為了增加解決這些問題的可行性，聰明的 Google 一開始就避開了從傳輸層動手，而且打算利用開源社區(qū)的力量以提高擴散的力度，對于協(xié)議使用者來說，也只需要在請求的 header 里設(shè)置 user agent，然后在服務(wù)端做好支持即可，極大的降低了部署的難度。SPDY 的設(shè)計如下

可以看到，SPDY 位于 HTTP 之下，SSL 之上，這樣可以輕松的兼容老版本的 HTTP 協(xié)議，SPDY 的功能分為基礎(chǔ)功能和高級功能兩部分，基礎(chǔ)功能是默認啟用的，高級功能需要手動啟用。

SPDY 基礎(chǔ)功能

多路復(fù)用(multiplexing)，多路復(fù)用通過多個請求共用一個連接的方式，降低了 TCP 連接建立和釋放的開銷，同時提高了帶寬的利用率。

請求優(yōu)先級(request prioritization)，多路復(fù)用帶來的一個問題是，在共享連接的基礎(chǔ)上會存在一些關(guān)鍵請求被阻塞，SPDY 允許給每個請求設(shè)置優(yōu)先級，這樣重要的請求就會優(yōu)先得到響應(yīng)。

header 壓縮，前面提到的 HTTP 1.x 的 header 很多時候都是重復(fù)而且多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量。SPDY 對 header 的壓縮率可以達到 80% 以上。

SPDY 高級功能

服務(wù)端推送，HTTP 只能由客戶端發(fā)送，服務(wù)器只能被動發(fā)送響應(yīng)。不過在開啟服務(wù)端推送后，服務(wù)端通過 X-Associated-Content header 會告知服務(wù)器會有新的內(nèi)容被推送過來，

服務(wù)端暗示，和服務(wù)端推送所不同的是，服務(wù)端暗示不會推送內(nèi)容，只是告訴客戶端有新的內(nèi)容產(chǎn)生，，內(nèi)容的下載還是需要客戶端主動發(fā)起請求。服務(wù)端暗示通過 X-Subresources header 來通知，一般應(yīng)用場景是客戶端需要先查詢服務(wù)端狀態(tài)，然后再下載資源，可以節(jié)約一次查詢請求。

自動 SPDY 出現(xiàn)后，頁面加載時間相比于 HTTP 減少了 64%，而且各大瀏覽器廠商在 SPDY 誕生之后的 1 年多時間里也都陸續(xù)支持了 SPDY。但是，SPDY 的生存時間卻沒有人們想象中的那么長，SPDY 從 2012 年誕生到 2016 年停止維護，如果 HTTP 2.0 沒有誕生，我相信 Google 可能會收到更多的真實反饋和數(shù)據(jù)，但是 SPDY 在這段時間里也完成了自己的使命。

初探 HTTP 2.0

HTTP 2.0 也被寫作 HTTP/2 ，它是超文本傳輸協(xié)議的 2.0 版本，因為 SPDY 的流行讓 IETF 看到了優(yōu)化后的效果，以及可以通過修改協(xié)議層來優(yōu)化 HTTP，所以 IETF 開始決定正式考慮制定 HTTP 2.0 的計劃，而且，SPDY的部分設(shè)計人員也被邀請參與了 HTTP 2.0 的設(shè)計。

HTTP2.0 在設(shè)計之初就與 SPDY 的設(shè)計目的和出發(fā)點不同，SPDY 更像是 Google 自家的一個產(chǎn)品，相當(dāng)于自家的一個玩具，你怎么玩兒都行，而 HTTP 2.0 在設(shè)計之初就是為了普適性的這個目的，所以，一開始任何的設(shè)計都會關(guān)系到以后的維護問題，如果有什么瑕疵或者不足的地方可能會影響巨大，所以考慮的問題角度要非常嚴(yán)謹和慎重。

HTTP 2.0 在設(shè)計之初就有一些重要的前提：

客戶端向服務(wù)器發(fā)送請求的這種基本模型不會改變。

原有的協(xié)議頭不會改變，使用 http:// 和 https:// 的服務(wù)和應(yīng)用不會做任何修改，不會有 http2://。

使用 HTTP 1.x 的客戶端和服務(wù)器可以平滑升級到 HTTP 2.0 上。

不識別 HTTP 2.0 的代理服務(wù)器可以將請求降級到 HTTP 1.x。

客戶端在和服務(wù)器確定是使用 HTTP1.x 還是 HTTP 2.0 之前，需要先確定對方是否支持 HTTP 2.0，所以這里必須要先進行協(xié)商，也就是客戶端詢問服務(wù)器，這樣一來一回就多了一個 RTT 的延遲。我們對 HTTP 1.x 的修改就是為了降低延遲，現(xiàn)在又多了一個 RTT，這樣顯然是無法接受的。Google 制定 SPDY 協(xié)議的時候也遇到了這個問題，他們采取的做法是強制協(xié)商在 SSL 層完成，還因此制定了一個 TLS 的拓展，叫做 NPN(Next Protocol Negotiation)。雖然 HTTP 2.0 也采用了相同的方式，不過經(jīng)過討論后，最終 HTTP 2.0 沒有強制要走 SSL 層，HTTP 2.0 沒有使用 NPN，卻制定了一個 TLS 的拓展叫做 ALPN(Application Layer Protocol Negotiation)，現(xiàn)在，SPDY 也打算遷移到 ALPN 了。

HTTP 2.0 的主要變化

HTTP 2.0 自從設(shè)計到誕生以來，發(fā)生了很多變化，不過對于開發(fā)人員和廠商來說，影響比較大的就幾點：

二進制格式

HTTP 1.x 的誕生使用的是明文協(xié)議，它的格式主要由三部分構(gòu)成：請求行(request line) 、請求頭(header) 和報文體(body)，要識別這三部分必須要做協(xié)議解析，而協(xié)議解析是基于文本的，基于文本的解析存在多樣性的缺陷，而二進制格式只能識別 0 和 1 ，比較固定，基于這種考量，HTTP 2.0 決定采用二進制格式，實現(xiàn)方便而且健壯性強。

下面這幅圖很好的詮釋了 HTTP1.x 和 HTTP 2.0 使用的不同報文格式。

在 HTTP 2.0 報文中，length 定義了整個 frame 的開始到結(jié)束，type 定了 frame 的類型，一種有十種，flags 定義了一些重要的參數(shù)，stream id 用作流控制，剩下的 payload 就是 request 的正文。

雖然 HTTP 2.0 報文格式看上去和 HTTP 1.x 的完全不同，但是實際上 HTTP 2.0 并沒有改變 HTTP 1.x 的語義，它只是在 HTTP 1.x 的基礎(chǔ)上封裝了一層，如下圖所示

從上圖可以看到，HTTP 1.x 中的請求行、請求頭被 HTTP 2.0 封裝成為了 HEADERS Frame，而 HTTP 1.x 中的報文體被 HTTP 2.0 封裝成為了 Data Frame。調(diào)試的時候瀏覽器會把 HTTP 2.0 的 frame 自動還原成 HTTP 1.x的格式。

連接共享

我們上面聊到，HTTP 1.x 并沒有真正意義上的解決連接復(fù)用問題，所以 HTTP 2.0 要解決的一大難題就是連接共享(MultiPlexing)，連接共享意味著客戶端與服務(wù)器之間也只需要一個連接即可，這樣即使來自很多流的數(shù)據(jù)包也能夠混合在一起通過同樣連接傳輸，再根據(jù)不同幀首部的 stream id 標(biāo)識符重新連接將不同的數(shù)據(jù)流進行組裝。

什么是 stream?

stream 是連接中的一個虛擬信道，可以承載雙向消息傳輸。每個流有唯一整數(shù)標(biāo)識符。為了防止兩端 streaam id 沖突，客戶端發(fā)起的流具有奇數(shù) id，服務(wù)器端發(fā)起的流具有偶數(shù) id。

我們上面提到 HTTP 1.x 沒有真正解決連接共享還有一個主要的因素就是無法對不同的請求設(shè)置優(yōu)先級，這樣會導(dǎo)致關(guān)鍵請求被阻塞。而 HTTP 2.0 你可以對不同的 stream 設(shè)置不同的優(yōu)先級，stream 之間也可以設(shè)置依賴，依賴和優(yōu)先級都可以動態(tài)調(diào)整，這樣就會解決關(guān)鍵請求被阻塞的問題。

頭部壓縮

上面還聊到了 HTTP1.x 中的 header 由于 cookie 和 user agent 不存在記憶性，這樣導(dǎo)致每次都要帶著這些頭重新發(fā)送請求，HTTP 2.0 使用 encoder 來減少傳輸?shù)?header 大小，通信雙方會各自緩存一份 header 字段表，這樣能夠避免重復(fù)傳輸 header ，也能夠減小傳輸?shù)拇笮?。HTTP 2.0 采用的是 HPACK 壓縮算法。

這種壓縮算法的主要思想可以參考官方文檔 https://httpwg.org/specs/rfc7541.html

服務(wù)端推送

服務(wù)端推送(Server Push) 我們上面也已經(jīng)聊過，HTTP 2.0 能夠以推的方式將客戶端的內(nèi)容預(yù)先發(fā)送出去，正因為沒有發(fā)起請求，建立連接等操作，所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度。服務(wù)端推送還有一個更大的優(yōu)勢：緩存，緩存也能夠在不同頁面之間共享緩存資源。

需要注意下面幾個點：

1、推送遵循同源策略;

2、這種服務(wù)端的推送是基于客戶端的請求響應(yīng)來確定的。

當(dāng)服務(wù)端需要主動推送某個資源時，便會發(fā)送一個 Frame Type 為 PUSH_PROMISE 的 frame ，里面帶了 PUSH 需要新建的 stream id。意思是告訴客戶端：接下來我要用這個 id 向你發(fā)送東西，客戶端準(zhǔn)備好接著?？蛻舳私馕?frame 時，發(fā)現(xiàn)它是一個 PUSH_PROMISE 類型，便會準(zhǔn)備接收服務(wù)端要推送的流。

HTTP 2.0 的缺陷

HTTP 2.0 帶給我們最驚艷的莫過于多路復(fù)用了，雖然多路復(fù)用有種種好處，但是大家可以想一下，多路復(fù)用雖然好，但是它是建立在 TCP 連接的基礎(chǔ)上，在連接頻繁的情況下，是不是會對 TCP 連接造成壓力，這個角度來講，TCP 很容易成為性能瓶頸。

還有一點，使用 HTTP 2.0 會增加一次 TLS 握手過程，增加 RTT，這個我們上面也說到了。

在 HTTP 2.0 中，多個請求是在同一個 TCP 管道中，這樣當(dāng) HTTP 2.0 出現(xiàn)丟包時，整個 TCP 都要開始等待重傳，那么就會阻塞該 TCP。連接中的所有請求。

總結(jié)

這篇文章我們主要聊了一下 HTTP從1.x 到 SPDY，再到 HTTP 2.0 的協(xié)議變遷以及 HTTP 1.0、1.1 的痛點和弊端，SPDY 的出現(xiàn)背景以及發(fā)現(xiàn)情況，然后 HTTP 2.0 的主要特征、HTTP 2.0 相對于 HTTP 1.x 有了哪些改變，它的缺點有哪些。

本文轉(zhuǎn)載自微信公眾號「程序員cxuan」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系程序員cxuan公眾號。