[[398710]]

本文轉(zhuǎn)載自微信公眾號「三分鐘學(xué)前端」，作者sisterAn。轉(zhuǎn)載本文請聯(lián)系三分鐘學(xué)前端公眾號。

引言

本文主要通過以下四個方面介紹，循序漸進走進HTTP/2：

• HTTP/1.1發(fā)明以來發(fā)生了哪些變化?
• HTTP/1.1 協(xié)議的性能缺陷
• HTTP/2 新特性
• HTTP/2 遺留問題

HTTP/1.1發(fā)明以來發(fā)生了哪些變化?

近年來，如果你仔細(xì)觀察那些最流行的網(wǎng)站首頁所需要下載的資源的話，會發(fā)現(xiàn)一個非常明顯的趨勢：

• 消息變大 ：從幾 KB 大小的消息，到幾 MB 大小的消息;
• 頁面資源變多 ：從每個頁面不到 10 個的資源，到每頁超 100 多個資源;
• 內(nèi)容形式變多樣 ：從單純到文本內(nèi)容，到圖片、視頻、音頻等內(nèi)容;
• 實時性要求變高 ：對頁面的實時性要求的應(yīng)用越來越多;

正如下圖所示，從 2011 年以來, 傳輸數(shù)據(jù)大小與平均請求資源數(shù)量不斷持續(xù)增長，并沒有減緩的跡象(綠色：傳輸數(shù)據(jù)大小，紅色：平均請求資源數(shù)量)：

自從 1997 年 HTTP/1.1 發(fā)布以來，我們已經(jīng)使用 HTTP/1.x 相當(dāng)長一段時間了，但近幾年內(nèi)容的爆炸式成長使得 HTTP/1.1 越來越無法滿足現(xiàn)代網(wǎng)絡(luò)的需求了

HTTP/1.1 協(xié)議的性能缺陷

1. 高延遲：頁面訪問速度下降

雖然近幾年來網(wǎng)絡(luò)帶寬增長非常快，然而我們卻并沒有看到網(wǎng)絡(luò)延遲有對應(yīng)程度的降低，這主要是由于隊頭阻塞 (Head-Of-Line Blocking)問題導(dǎo)致

HTTP/1.1 版引入了管道機制(pipelining)，即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求，進一步改進了 HTTP 協(xié)議的效率

但這要求服務(wù)端必須按照請求發(fā)送的順序返回響應(yīng)，當(dāng)順序請求多個文件時，其中一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一并被阻塞，這就是隊頭阻塞 (Head-Of-Line Blocking)

隊頭阻塞導(dǎo)致再打的帶寬無法被充分利用

因此 人們嘗試過以下辦法來解決隊頭阻塞問題：

• 使用多個域名 ：將同一個頁面的資源分散到不同域名，提升并發(fā)連接上限，因為瀏覽器通常對同一域名的 HTTP 連接最大只能是 6 個
• 引入雪碧圖 ：將多張小圖合并成一張大圖供瀏覽器 JavaScript 來切割使用，這樣可以將多個請求合并成一個請求，但是帶來了新的問題，當(dāng)某張小圖片更新了，那么需要重新請求大圖片，浪費了大量的網(wǎng)絡(luò)帶寬;
• 將小圖內(nèi)聯(lián) ：將圖片的二進制數(shù)據(jù)通過 base64 編碼后，把編碼數(shù)據(jù)嵌入到 HTML 或 CSS 文件中，以此來減少網(wǎng)絡(luò)請求次數(shù);

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

使用 webpack 等工具打包 ：打包壓縮多個 JavaScript 文件到一個文件中，以一個請求替代了很多個請求，但是帶來的問題，當(dāng)某個 js 文件變化了，需要重新請求同一個包里的所有 js 文件;

按需加載 ：來減少第一時間的 HTTP 請求次數(shù)

2. 明文傳輸：不安全

HTTP/1.1 在傳輸數(shù)據(jù)時，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗證對方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性。

3. 無狀態(tài)：頭部巨大切重復(fù)

由于 HTTP 協(xié)議是無狀態(tài)的，每一個請求都得攜帶 HTTP 頭部，特別是對于有攜帶 cookie 的頭部，而 cookie 的大小通常很大，另外還有User Agent、Accept、Server等，通常多達幾百字節(jié)甚至上千字節(jié)，但 Body 卻經(jīng)常只有幾十字節(jié)

4. 不支持服務(wù)器推送

HTTP/1.1 不支持服務(wù)器推送消息，因此當(dāng)客戶端需要獲取通知時，只能通過定時器不斷地拉取消息，這無疑浪費大量了帶寬和服務(wù)器資源。

HTTP/2 新特性

在 HTTP/1.x 中，為了性能考慮，我們會引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個域名等等的方式，但還是有一些關(guān)鍵點無法優(yōu)化，例如HTTP頭部巨大且重復(fù)、明文傳輸不安全、服務(wù)器不能主動推送等，要改變這些必須重新設(shè)計 HTTP 協(xié)議，于是 HTTP/2 就出來了!

2015 年，HTTP/2 發(fā)布。HTTP/2 是現(xiàn)行 HTTP 協(xié)議(HTTP/1.x)的替代，但它不是重寫，HTTP 方法 / 狀態(tài)碼 / 語義都與 HTTP/1.x 一樣。HTTP/2 基于 SPDY，專注于性能，最大的目標(biāo)是在用戶和網(wǎng)站間只用一個連接(connec-tion)。

從目前的情況來看，國內(nèi)外一些排名靠前的站點基本都實現(xiàn)了 HTTP/2 的部署，使用 HTTP/2 能帶來 20%~60% 的效率提升。

可以通過該鏈接直觀感受下 HTTP/2 比 HTTP/1 到底快了多少: https://http2.akamai.com/demo

1. 二進制傳輸

在不改動 HTTP/1.x 的語義、方法、狀態(tài)碼、URI 以及首部字段….. 的情況下，HTTP/2 是如何做到「突破 HTTP1.1 的性能限制，改進傳輸性能，實現(xiàn)低延遲和高吞吐量」的 ?

關(guān)鍵之一就是在應(yīng)用層(HTTP/2)和傳輸層(TCP or UDP)之間增加一個二進制分幀層。

在二進制分幀層中， HTTP/2 會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶?frame)，并對它們采用二進制格式的編碼，其中 HTTP1.x 的首部信息會被封裝到 HEADERS 幀，而相應(yīng)的 Request Body 則封裝到 DATA 幀里面，HTTP/2 數(shù)據(jù)分幀后，“Header+Body"的報文結(jié)構(gòu)就完全消失了，協(xié)議看到的只是一個個"碎片”。

HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個或多個幀組成。多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流標(biāo)識可以重新組裝

2. Header 壓縮(HPACK)

HTTP 協(xié)議不帶有狀態(tài)，每次請求都必須附上所有信息。所以，請求的很多字段都是重復(fù)的，比如Cookie和User Agent，一模一樣的內(nèi)容，每次請求都必須附帶，這會浪費很多帶寬，也影響速度。

HTTP/2 對這一點做了優(yōu)化，引入了頭信息壓縮機制(header compression)。一方面，頭信息使用gzip或compress壓縮后再發(fā)送;另一方面，客戶端和服務(wù)器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發(fā)送同樣字段了，只發(fā)送索引號，這樣就提高速度了。

3. 多路復(fù)用

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

多路復(fù)用，就是在一個 TCP 連接中可以存在多條流。換句話說，也就是可以發(fā)送多個請求，對端可以通過幀中的標(biāo)識知道屬于哪個請求。

這一特性使得 HTTP 傳輸性能得到極大提升，主要體現(xiàn)在以下三個方面：

多工

HTTP/2 復(fù)用 TCP 連接，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應(yīng)，而且不用按照順序一一對應(yīng)，這樣就避免了"隊頭堵塞"

數(shù)據(jù)流

HTTP/2 并行交錯地發(fā)送多個請求 / 響應(yīng)，請求 / 響應(yīng)之間互不影響

因此，必須要對數(shù)據(jù)包做標(biāo)記，指出它屬于哪個請求 / 響應(yīng)。

HTTP/2 將每個請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個數(shù)據(jù)流(stream)。每個數(shù)據(jù)流都有一個獨一無二的編號。數(shù)據(jù)包發(fā)送的時候，都必須標(biāo)記數(shù)據(jù)流ID，用來區(qū)分它屬于哪個數(shù)據(jù)流。另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)出的，ID為偶數(shù)。

數(shù)據(jù)流發(fā)送到一半的時候，客戶端和服務(wù)器都可以發(fā)送信號(RST_STREAM幀)，取消這個數(shù)據(jù)流。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接。這就是說，HTTP/2 可以取消某一次請求，同時保證TCP連接還打開著，可以被其他請求使用。

優(yōu)先級

在 HTTP/2 中，每個請求都可以帶一個 31bit 的優(yōu)先值，0 表示最高優(yōu)先級， 數(shù)值越大優(yōu)先級越低。有了這個優(yōu)先值，客戶端和服務(wù)器就可以在處理不同的流時采取不同的策略，以最優(yōu)的方式發(fā)送流、消息和幀。

4. 服務(wù)端 Push

HTTP/2 允許服務(wù)器未經(jīng)請求，主動向客戶端發(fā)送資源，這叫做服務(wù)器推送(server push)。

常見場景是客戶端請求一個網(wǎng)頁，這個網(wǎng)頁里面包含很多靜態(tài)資源。正常情況下，客戶端必須收到網(wǎng)頁后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)出靜態(tài)資源請求。其實，服務(wù)器可以預(yù)期到客戶端請求網(wǎng)頁后，很可能會再請求靜態(tài)資源，所以就主動把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了。

這樣就可以相對減少一點延遲時間。當(dāng)然在瀏覽器兼容的情況下你也可以使用 prefetch 。

注意： 服務(wù)端可以主動推送，客戶端也可以主動選擇是否接收，如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送 RST_STREAM 幀來拒收，另外，主動推送也遵守同源策略

5. 提高安全性

出于兼容的考慮，HTTP/2 延續(xù)了 HTTP/1 的“明文”特點，可以像以前一樣使用明文傳輸數(shù)據(jù)，不強制使用加密通信，但 HTTPS 已經(jīng)是大勢所趨，各大主流瀏覽器都公開宣布只支持加密的 HTTP/2，所以，真實應(yīng)用中的 HTTP/2 是還是加密的：

HTTP/2 遺留問題

HTTP/2 還會隊頭阻塞嗎?

HTTP/2 也存在隊頭阻塞問題，比如丟包。

如果造成隊頭阻塞，問題可能比http1.1還嚴(yán)重，因為只有一個tcp連接，后續(xù)的傳輸都要等前面，http/1.1 多個tcp連接，阻塞一個，其他的還可以正常跑

HTTP/2下還會擁塞嗎?

由于 TCP 連接減少而使網(wǎng)絡(luò)擁塞狀況得以改觀;

慢啟動時間減少，擁塞和丟包恢復(fù)速度更快。

參考

解密 HTTP/2 與 HTTP/3 的新特性：https://www.infoq.cn/article/ku4okqr8vh123a8dlccj