[[420793]]

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

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

最初的 HTTP

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

HTTP 的瓶頸

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

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

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

延遲主要有下面三個(gè)方面：

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

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

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

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

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

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

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

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

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

因?yàn)橹挥袃绲鹊恼?qǐng)求比如 GET、HEAD 才能使用 pipelining ，非冪等請(qǐng)求比如 POST 則不能使用，因?yàn)檎?qǐng)求之間可能存在先后依賴關(guān)系。

其實(shí)隊(duì)頭阻塞問題并沒有完全解決，因?yàn)榉?wù)器返回的響應(yīng)還是要依次返回，也就是返回的請(qǐng)求時(shí) FIFO - 先發(fā)先回。

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

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

正是因?yàn)橛羞@么多的問題，各大瀏覽器廠商要么是根本就不支持 pipelining，要么就是默認(rèn)關(guān)掉了 pipelining 機(jī)制，而且啟用的條件十分苛刻。

SPDY

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

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

認(rèn)識(shí) SPDY

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

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

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

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

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

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

SPDY 基礎(chǔ)功能

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

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

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

SPDY 高級(jí)功能

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

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

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

初探 HTTP 2.0

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

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

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

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

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

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

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

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

HTTP 2.0 的主要變化

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

二進(jìn)制格式

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

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

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

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

從上圖可以看到，HTTP 1.x 中的請(qǐng)求行、請(qǐng)求頭被 HTTP 2.0 封裝成為了 HEADERS Frame，而 HTTP 1.x 中的報(bào)文體被 HTTP 2.0 封裝成為了 Data Frame。調(diào)試的時(shí)候?yàn)g覽器會(huì)把 HTTP 2.0 的 frame 自動(dòng)還原成 HTTP 1.x的格式。

連接共享

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

什么是 stream?

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

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

頭部壓縮

上面還聊到了 HTTP1.x 中的 header 由于 cookie 和 user agent 不存在記憶性，這樣導(dǎo)致每次都要帶著這些頭重新發(fā)送請(qǐng)求，HTTP 2.0 使用 encoder 來減少傳輸?shù)?header 大小，通信雙方會(huì)各自緩存一份 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ā)送出去，正因?yàn)闆]有發(fā)起請(qǐng)求，建立連接等操作，所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度。服務(wù)端推送還有一個(gè)更大的優(yōu)勢(shì)：緩存，緩存也能夠在不同頁面之間共享緩存資源。

需要注意下面幾個(gè)點(diǎn)：

1、推送遵循同源策略;

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

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

HTTP 2.0 的缺陷

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

還有一點(diǎn)，使用 HTTP 2.0 會(huì)增加一次 TLS 握手過程，增加 RTT，這個(gè)我們上面也說到了。

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

總結(jié)

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

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