[[398710]]

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

引言

本文主要通過以下四個(gè)方面介紹，循序漸進(jìn)走進(jìn)HTTP/2：

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

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

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

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

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

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

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

1. 高延遲：頁(yè)面訪問速度下降

雖然近幾年來網(wǎng)絡(luò)帶寬增長(zhǎng)非?？欤欢覀儏s并沒有看到網(wǎng)絡(luò)延遲有對(duì)應(yīng)程度的降低，這主要是由于隊(duì)頭阻塞 (Head-Of-Line Blocking)問題導(dǎo)致

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

但這要求服務(wù)端必須按照請(qǐng)求發(fā)送的順序返回響應(yīng)，當(dāng)順序請(qǐng)求多個(gè)文件時(shí)，其中一個(gè)請(qǐng)求因?yàn)槟撤N原因被阻塞時(shí)，在后面排隊(duì)的所有請(qǐng)求也一并被阻塞，這就是隊(duì)頭阻塞 (Head-Of-Line Blocking)

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

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

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

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

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

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

2. 明文傳輸：不安全

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

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

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

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

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

HTTP/2 新特性

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

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

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

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

1. 二進(jìn)制傳輸

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

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

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

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

2. Header 壓縮(HPACK)

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

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

3. 多路復(fù)用

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

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

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

多工

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

數(shù)據(jù)流

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

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

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

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

優(yōu)先級(jí)

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

4. 服務(wù)端 Push

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

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

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

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

5. 提高安全性

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

HTTP/2 遺留問題

HTTP/2 還會(huì)隊(duì)頭阻塞嗎?

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

如果造成隊(duì)頭阻塞，問題可能比http1.1還嚴(yán)重，因?yàn)橹挥幸粋€(gè)tcp連接，后續(xù)的傳輸都要等前面，http/1.1 多個(gè)tcp連接，阻塞一個(gè)，其他的還可以正常跑

HTTP/2下還會(huì)擁塞嗎?

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

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

參考

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