以下文章來源于前端工匠 ，作者浪里行舟君
HTTP/2 相比于 HTTP/1.1，可以說是大幅度提高了網(wǎng)頁(yè)的性能，只需要升級(jí)到該協(xié)議就可以減少很多之前需要做的性能優(yōu)化工作，當(dāng)然兼容問題以及如何優(yōu)雅降級(jí)應(yīng)該是國(guó)內(nèi)還不普遍使用的原因之一。
雖然 HTTP/2 提高了網(wǎng)頁(yè)的性能，但是并不代表它已經(jīng)是完美的了，HTTP/3 就是為了解決 HTTP/2 所存在的一些問題而被推出來的。
如果仔細(xì)觀察打開那些最流行的網(wǎng)站首頁(yè)所需要下載的資源的話，會(huì)發(fā)現(xiàn)一個(gè)非常明顯的趨勢(shì)。近年來加載網(wǎng)站首頁(yè)需要的下載的數(shù)據(jù)量在逐漸增加，并已經(jīng)超過了2100K。但在這里我們更應(yīng)該關(guān)心的是：平均每個(gè)頁(yè)面為了完成顯示與渲染所需要下載的資源數(shù)已經(jīng)超過了100個(gè)。
正如下圖所示，從2011年以來,傳輸數(shù)據(jù)大小與平均請(qǐng)求資源數(shù)量不斷持續(xù)增長(zhǎng)，并沒有減緩的跡象。該圖表中綠色直線展示了傳輸數(shù)據(jù)大小的增長(zhǎng)，紅色直線展示了平均請(qǐng)求資源數(shù)量的增長(zhǎng)。
HTTP/1.1自從1997年發(fā)布以來，我們已經(jīng)使用HTTP/1.x 相當(dāng)長(zhǎng)一段時(shí)間了，但是隨著近十年互聯(lián)網(wǎng)的爆炸式發(fā)展，從當(dāng)初網(wǎng)頁(yè)內(nèi)容以文本為主,到現(xiàn)在以富媒體（如圖片、聲音、視頻）為主,而且對(duì)頁(yè)面內(nèi)容實(shí)時(shí)性高要求的應(yīng)用越來越多(比如聊天、視頻直播),于是當(dāng)時(shí)協(xié)議規(guī)定的某些特性，已經(jīng)無法滿足現(xiàn)代網(wǎng)絡(luò)的需求了。
雖然近幾年來網(wǎng)絡(luò)帶寬增長(zhǎng)非?？欤欢覀儏s并沒有看到網(wǎng)絡(luò)延遲有對(duì)應(yīng)程度的降低。網(wǎng)絡(luò)延遲問題主要由于隊(duì)頭阻塞(Head-Of-Line Blocking),導(dǎo)致帶寬無法被充分利用。
隊(duì)頭阻塞是指當(dāng)順序發(fā)送的請(qǐng)求序列中的一個(gè)請(qǐng)求因?yàn)槟撤N原因被阻塞時(shí)，在后面排隊(duì)的所有請(qǐng)求也一并被阻塞，會(huì)導(dǎo)致客戶端遲遲收不到數(shù)據(jù)。針對(duì)隊(duì)頭阻塞,人們嘗試過以下辦法來解決:
將同一頁(yè)面的資源分散到不同域名下，提升連接上限。 Chrome有個(gè)機(jī)制，對(duì)于同一個(gè)域名，默認(rèn)允許同時(shí)建立 6 個(gè) TCP持久連接，使用持久連接時(shí)，雖然能公用一個(gè)TCP管道，但是在一個(gè)管道中同一時(shí)刻只能處理一個(gè)請(qǐng)求，在當(dāng)前的請(qǐng)求沒有結(jié)束之前，其他的請(qǐng)求只能處于阻塞狀態(tài)。另外如果在同一個(gè)域名下同時(shí)有10個(gè)請(qǐng)求發(fā)生，那么其中4個(gè)請(qǐng)求會(huì)進(jìn)入排隊(duì)等待狀態(tài)，直至進(jìn)行中的請(qǐng)求完成。
Spriting合并多張小圖為一張大圖,再用JavaScript或者CSS將小圖重新“切割”出來的技術(shù)。
內(nèi)聯(lián)(Inlining)是另外一種防止發(fā)送很多小圖請(qǐng)求的技巧，將圖片的原始數(shù)據(jù)嵌入在CSS文件里面的URL里，減少網(wǎng)絡(luò)請(qǐng)求次數(shù)。
.icon1 { background: url(data:image/png;base64,<data>) no-repeat; }.icon2 { background: url(data:image/png;base64,<data>) no-repeat; }拼接(Concatenation)將多個(gè)體積較小的JavaScript使用webpack等工具打包成1個(gè)體積更大的JavaScript文件,但如果其中1個(gè)文件的改動(dòng)就會(huì)導(dǎo)致大量數(shù)據(jù)被重新下載多個(gè)文件。
由于報(bào)文Header一般會(huì)攜帶"User Agent""Cookie""Accept""Server"等許多固定的頭字段（如下圖），多達(dá)幾百字節(jié)甚至上千字節(jié)，但Body卻經(jīng)常只有幾十字節(jié)（比如GET請(qǐng)求、 204/301/304響應(yīng)），成了不折不扣的“大頭兒子”。Header里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀?。更要命的是，成千上萬(wàn)的請(qǐng)求響應(yīng)報(bào)文里有很多字段值都是重復(fù)的，非常浪費(fèi)。
HTTP/1.1在傳輸數(shù)據(jù)時(shí)，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對(duì)方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性。
你有沒有聽說過"免費(fèi)WiFi陷阱”之類的新聞呢？黑客就是利用了HTTP明文傳輸?shù)娜秉c(diǎn)，在公共場(chǎng)所架設(shè)一個(gè)WiFi熱點(diǎn)開始“釣魚”，誘騙網(wǎng)民上網(wǎng)。一旦你連上了這個(gè)WiFi熱點(diǎn)，所有的流量都會(huì)被截獲保存，里面如果有銀行卡號(hào)、網(wǎng)站密碼等敏感信息的話那就危險(xiǎn)了，黑客拿到了這些數(shù)據(jù)就可以冒充你為所欲為。
上面我們提到,由于HTTP/1.x的缺陷，我們會(huì)引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個(gè)域名等等的方式來提高性能。不過這些優(yōu)化都繞開了協(xié)議，直到2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決HTTP/1.1效率不高的問題。谷歌推出SPDY，才算是正式改造HTTP協(xié)議本身。降低延遲，壓縮header等等，SPDY的實(shí)踐證明了這些優(yōu)化的效果，也最終帶來HTTP/2的誕生。
HTTP/1.1有兩個(gè)主要的缺點(diǎn)：安全不足和性能不高，由于背負(fù)著 HTTP/1.x 龐大的歷史包袱,所以協(xié)議的修改,兼容性是首要考慮的目標(biāo)，否則就會(huì)破壞互聯(lián)網(wǎng)上無數(shù)現(xiàn)有的資產(chǎn)。如上圖所示, SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時(shí)可以使用已有的SSL功能。
SPDY 協(xié)議在Chrome瀏覽器上證明可行以后，就被當(dāng)作 HTTP/2 的基礎(chǔ)，主要特性都在 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，專注于性能，最大的一個(gè)目標(biāo)是在用戶和網(wǎng)站間只用一個(gè)連接（connection）。從目前的情況來看，國(guó)內(nèi)外一些排名靠前的站點(diǎn)基本都實(shí)現(xiàn)了HTTP/2的部署，使用HTTP/2能帶來20%~60%的效率提升。
HTTP/2由兩個(gè)規(guī)范（Specification）組成：
Hypertext Transfer Protocol version 2 - RFC7540
HPACK - Header Compression for HTTP/2 - RFC7541
HTTP/2傳輸數(shù)據(jù)量的大幅減少,主要有兩個(gè)原因:以二進(jìn)制方式傳輸和Header 壓縮。我們先來介紹二進(jìn)制傳輸,HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非HTTP/1.x 里純文本形式的報(bào)文 ，二進(jìn)制協(xié)議解析起來更高效。HTTP/2 將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼。
它把TCP協(xié)議的部分特性挪到了應(yīng)用層，把原來的"Header+Body"的消息"打散"為數(shù)個(gè)小片的二進(jìn)制"幀"(Frame),用"HEADERS"幀存放頭數(shù)據(jù)、"DATA"幀存放實(shí)體數(shù)據(jù)。HTP/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í)可以重新組裝。
HTTP/2并沒有使用傳統(tǒng)的壓縮算法，而是開發(fā)了專門的"HPACK”算法，在客戶端和服務(wù)器兩端建立“字典”，用索引號(hào)表示重復(fù)的字符串，還采用哈夫曼編碼來壓縮整數(shù)和字符串，可以達(dá)到50%~90%的高壓縮率。
具體來說:
在客戶端和服務(wù)器端使用“首部表”來跟蹤和存儲(chǔ)之前發(fā)送的鍵-值對(duì)，對(duì)于相同的數(shù)據(jù)，不再通過每次請(qǐng)求和響應(yīng)發(fā)送；
首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進(jìn)地更新;
每個(gè)新的首部鍵-值對(duì)要么被追加到當(dāng)前表的末尾，要么替換表中之前的值
例如下圖中的兩個(gè)請(qǐng)求， 請(qǐng)求一發(fā)送了所有的頭部字段，第二個(gè)請(qǐng)求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷
在 HTTP/2 中引入了多路復(fù)用的技術(shù)。多路復(fù)用很好的解決了瀏覽器限制同一個(gè)域名下的請(qǐng)求數(shù)量的問題，同時(shí)也接更容易實(shí)現(xiàn)全速傳輸，畢竟新開一個(gè) TCP 連接都需要慢慢提升傳輸速度。
大家可以通過 該鏈接 直觀感受下 HTTP/2 比 HTTP/1 到底快了多少。
同域名下所有通信都在單個(gè)連接上完成。
單個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。
數(shù)據(jù)流以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成，多個(gè)幀之間可以亂序發(fā)送，因?yàn)楦鶕?jù)幀首部的流標(biāo)識(shí)可以重新組裝。
這一特性，使性能有了極大提升：
同個(gè)域名只需要占用一個(gè) TCP 連接，使用一個(gè)連接并行發(fā)送多個(gè)請(qǐng)求和響應(yīng),這樣整個(gè)頁(yè)面資源的下載過程只需要一次慢啟動(dòng)，同時(shí)也避免了多個(gè)TCP連接競(jìng)爭(zhēng)帶寬所帶來的問題。
并行交錯(cuò)地發(fā)送多個(gè)請(qǐng)求/響應(yīng)，請(qǐng)求/響應(yīng)之間互不影響。
在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ā)送流、消息和幀。
HTTP2還在一定程度上改變了傳統(tǒng)的“請(qǐng)求-應(yīng)答”工作模式，服務(wù)器不再是完全被動(dòng)地響應(yīng)請(qǐng)求，也可以新建“流”主動(dòng)向客戶端發(fā)送消息。比如，在瀏覽器剛請(qǐng)求HTML的時(shí)候就提前把可能會(huì)用到的JS、CSS文件發(fā)給客戶端，減少等待的延遲，這被稱為"服務(wù)器推送"（ Server Push，也叫 Cache push）
例如下圖所示,服務(wù)端主動(dòng)把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時(shí)再發(fā)送這些請(qǐng)求。
另外需要補(bǔ)充的是,服務(wù)端可以主動(dòng)推送，客戶端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。主動(dòng)推送也遵守同源策略，換句話說，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方確認(rèn)才行。
出于兼容的考慮，HTTP/2延續(xù)了HTTP/1的“明文”特點(diǎn)，可以像以前一樣使用明文傳輸數(shù)據(jù)，不強(qiáng)制使用加密通信，不過格式還是二進(jìn)制，只是不需要解密。
但由于HTTPS已經(jīng)是大勢(shì)所趨，而且主流的瀏覽器Chrome、Firefox等都公開宣布只支持加密的HTTP/2，所以“事實(shí)上”的HTTP/2是加密的。也就是說，互聯(lián)網(wǎng)上通常所能見到的HTTP/2都是使用"https”協(xié)議名，跑在TLS上面。HTTP/2協(xié)議定義了兩個(gè)字符串標(biāo)識(shí)符：“h2"表示加密的HTTP/2，“h2c”表示明文的HTTP/2。
雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個(gè)巨大的問題，主要是底層支撐的 TCP 協(xié)議造成的。HTTP/2的缺點(diǎn)主要有以下幾點(diǎn)：
TCP 以及 TCP+TLS建立連接的延時(shí)
HTTP/2都是使用TCP協(xié)議來傳輸?shù)模绻褂肏TTPS的話，還需要使用TLS協(xié)議進(jìn)行安全傳輸，而使用TLS也需要一個(gè)握手過程，這樣就需要有兩個(gè)握手延遲過程：
①在建立TCP連接的時(shí)候，需要和服務(wù)器進(jìn)行三次握手來確認(rèn)連接成功，也就是說需要在消耗完1.5個(gè)RTT之后才能進(jìn)行數(shù)據(jù)傳輸。
②進(jìn)行TLS連接，TLS有兩個(gè)版本——TLS1.2和TLS1.3，每個(gè)版本建立連接所花的時(shí)間不同，大致是需要1~2個(gè)RTT。
總之，在傳輸數(shù)據(jù)之前，我們需要花掉 3～4 個(gè) RTT。
TCP的隊(duì)頭阻塞并沒有徹底解決
上文我們提到在HTTP/2中，多個(gè)請(qǐng)求是跑在一個(gè)TCP管道中的。但當(dāng)出現(xiàn)了丟包時(shí)，HTTP/2 的表現(xiàn)反倒不如 HTTP/1 了。因?yàn)門CP為了保證可靠傳輸，有個(gè)特別的“丟包重傳”機(jī)制，丟失的包必須要等待重新傳輸確認(rèn)，HTTP/2出現(xiàn)丟包時(shí)，整個(gè) TCP 都要開始等待重傳，那么就會(huì)阻塞該TCP連接中的所有請(qǐng)求（如下圖）。而對(duì)于 HTTP/1.1 來說，可以開啟多個(gè) TCP 連接，出現(xiàn)這種情況反到只會(huì)影響其中一個(gè)連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。
讀到這里，可能就會(huì)有人考慮為什么不直接去修改 TCP 協(xié)議？其實(shí)這已經(jīng)是一件不可能完成的任務(wù)了。因?yàn)?TCP 存在的時(shí)間實(shí)在太長(zhǎng)，已經(jīng)充斥在各種設(shè)備中，并且這個(gè)協(xié)議是由操作系統(tǒng)實(shí)現(xiàn)的，更新起來不大現(xiàn)實(shí)。
Google 在推SPDY的時(shí)候就已經(jīng)意識(shí)到了這些問題，于是就另起爐灶搞了一個(gè)基于 UDP 協(xié)議的“QUIC”協(xié)議，讓HTTP跑在QUIC上而不是TCP上。而這個(gè)“HTTP over QUIC”就是HTTP協(xié)議的下一個(gè)大版本，HTTP/3。它在HTTP/2的基礎(chǔ)上又實(shí)現(xiàn)了質(zhì)的飛躍，真正“完美”地解決了“隊(duì)頭阻塞”問題。
QUIC 雖然基于 UDP，但是在原本的基礎(chǔ)上新增了很多功能，接下來我們重點(diǎn)介紹幾個(gè)QUIC新功能。不過HTTP/3目前還處于草案階段，正式發(fā)布前可能會(huì)有變動(dòng)，所以本文盡量不涉及那些不穩(wěn)定的細(xì)節(jié)。
上面我們提到QUIC基于UDP，而UDP是“無連接”的，根本就不需要“握手”和“揮手”，所以就比TCP來得快。此外QUIC也實(shí)現(xiàn)了可靠傳輸，保證數(shù)據(jù)一定能夠抵達(dá)目的地。它還引入了類似HTTP/2的“流”和“多路復(fù)用”，單個(gè)“流"是有序的，可能會(huì)因?yàn)閬G包而阻塞，但其他“流”不會(huì)受到影響。具體來說QUIC協(xié)議有以下特點(diǎn)：
實(shí)現(xiàn)了類似TCP的流量控制、傳輸可靠性的功能。
雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎(chǔ)之上增加了一層來保證數(shù)據(jù)可靠性傳輸。它提供了數(shù)據(jù)包重傳、擁塞控制以及其他一些TCP中存在的特性。
實(shí)現(xiàn)了快速握手功能。
由于QUIC是基于UDP的，所以QUIC可以實(shí)現(xiàn)使用0-RTT或者1-RTT來建立連接，這意味著QUIC可以用最快的速度來發(fā)送和接收數(shù)據(jù)，這樣可以大大提升首次打開頁(yè)面的速度。0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優(yōu)勢(shì)。
集成了TLS加密功能。
目前QUIC使用的是TLS1.3，相較于早期版本TLS1.3有更多的優(yōu)點(diǎn)，其中最重要的一點(diǎn)是減少了握手所花費(fèi)的RTT個(gè)數(shù)。
多路復(fù)用，徹底解決TCP中隊(duì)頭阻塞的問題
和TCP不同，QUIC實(shí)現(xiàn)了在同一物理連接上可以有多個(gè)獨(dú)立的邏輯數(shù)據(jù)流（如下圖）。實(shí)現(xiàn)了數(shù)據(jù)流的單獨(dú)傳輸，就解決了TCP中隊(duì)頭阻塞的問題。
HTTP/1.1有兩個(gè)主要的缺點(diǎn)：安全不足和性能不高。
HTTP/2完全兼容HTTP/1，是“更安全的HTTP、更快的HTTPS"，頭部壓縮、多路復(fù)用等技術(shù)可以充分利用帶寬，降低延遲，從而大幅度提高上網(wǎng)體驗(yàn)；
QUIC 基于 UDP 實(shí)現(xiàn)，是 HTTP/3 中的底層支撐協(xié)議，該協(xié)議基于 UDP，又取了 TCP 中的精華，實(shí)現(xiàn)了即快又可靠的協(xié)議。
透視HTTP協(xié)議
Web協(xié)議詳解與抓包實(shí)戰(zhàn)
瀏覽器工作原理與實(shí)踐
HTTP2講解
一文讀懂 HTTP/2 特性
科普：QUIC協(xié)議原理分析
HTTP2簡(jiǎn)介和基于HTTP2的Web優(yōu)化
聯(lián)系客服
