前言

HTTP/2 相比于 HTTP/1，可以說(shuō)是大幅度提高了網(wǎng)頁(yè)的性能，只需要升級(jí)到該協(xié)議就可以減少很多之前需要做的性能優(yōu)化工作，當(dāng)然兼容問(wèn)題以及如何優(yōu)雅降級(jí)應(yīng)該是國(guó)內(nèi)還不普遍使用的原因之一。

雖然 HTTP/2 提高了網(wǎng)頁(yè)的性能，但是并不代表它已經(jīng)是完美的了，HTTP/3 就是為了解決 HTTP/2 所存在的一些問(wèn)題而被推出來(lái)的。

[[277475]]

一、HTTP協(xié)議

HTTP協(xié)議是HyperText Transfer Protocol(超文本傳輸協(xié)議)的縮寫(xiě)，它是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。伴隨著計(jì)算機(jī)網(wǎng)絡(luò)和瀏覽器的誕生，HTTP1.0也隨之而來(lái)，處于計(jì)算機(jī)網(wǎng)絡(luò)中的應(yīng)用層，HTTP是建立在TCP協(xié)議之上，所以HTTP協(xié)議的瓶頸及其優(yōu)化技巧都是基于TCP協(xié)議本身的特性，例如tcp建立連接的3次握手和斷開(kāi)連接的4次揮手以及每次建立連接帶來(lái)的RTT延遲時(shí)間。

二、HTTP/1.x的缺陷

• 連接無(wú)法復(fù)用：連接無(wú)法復(fù)用會(huì)導(dǎo)致每次請(qǐng)求都經(jīng)歷三次握手和慢啟動(dòng)。三次握手在高延遲的場(chǎng)景下影響較明顯，慢啟動(dòng)則對(duì)大量小文件請(qǐng)求影響較大(沒(méi)有達(dá)到最大窗口請(qǐng)求就被終止)。
• HTTP/1.0傳輸數(shù)據(jù)時(shí)，每次都需要重新建立連接，增加延遲。
• HTTP/1.1雖然加入keep-alive可以復(fù)用一部分連接，但域名分片等情況下仍然需要建立多個(gè)connection，耗費(fèi)資源，給服務(wù)器帶來(lái)性能壓力。
• Head-Of-Line Blocking(HOLB)：導(dǎo)致帶寬無(wú)法被充分利用，以及后續(xù)健康請(qǐng)求被阻塞。HOLB是指一系列包(package)因?yàn)榈谝粋€(gè)包被阻塞;當(dāng)頁(yè)面中需要請(qǐng)求很多資源的時(shí)候，HOLB(隊(duì)頭阻塞)會(huì)導(dǎo)致在達(dá)到最大請(qǐng)求數(shù)量時(shí)，剩余的資源需要等待其他資源請(qǐng)求完成后才能發(fā)起請(qǐng)求。
• HTTP 1.0：下個(gè)請(qǐng)求必須在前一個(gè)請(qǐng)求返回后才能發(fā)出，request-response對(duì)按序發(fā)生。顯然，如果某個(gè)請(qǐng)求長(zhǎng)時(shí)間沒(méi)有返回，那么接下來(lái)的請(qǐng)求就全部阻塞了。
• HTTP 1.1：嘗試使用 pipeling 來(lái)解決，即瀏覽器可以一次性發(fā)出多個(gè)請(qǐng)求(同個(gè)域名，同一條 TCP 鏈接)。但 pipeling 要求返回是按序的，那么前一個(gè)請(qǐng)求如果很耗時(shí)(比如處理大圖片)，那么后面的請(qǐng)求即使服務(wù)器已經(jīng)處理完，仍會(huì)等待前面的請(qǐng)求處理完才開(kāi)始按序返回。所以，pipeling 只部分解決了 HOLB。

如上圖所示，紅色圈出來(lái)的請(qǐng)求就因域名鏈接數(shù)已超過(guò)限制，而被掛起等待了一段時(shí)間。

• 協(xié)議開(kāi)銷(xiāo)大： HTTP1.x在使用時(shí)，header里攜帶的內(nèi)容過(guò)大，在一定程度上增加了傳輸?shù)某杀?，并且每次?qǐng)求header基本不怎么變化，尤其在移動(dòng)端增加用戶(hù)流量。
• 安全因素：HTTP1.x在傳輸數(shù)據(jù)時(shí)，所有傳輸?shù)膬?nèi)容都是明文，客戶(hù)端和服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份，這在一定程度上無(wú)法保證數(shù)據(jù)的安全性

三、SPDY 協(xié)議

因?yàn)镠TTP/1.x的問(wèn)題，我們會(huì)引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個(gè)域名等等的方式來(lái)提高性能。不過(guò)這些優(yōu)化都繞開(kāi)了協(xié)議，直到2009年，谷歌公開(kāi)了自行研發(fā)的 SPDY 協(xié)議，主要解決HTTP/1.1效率不高的問(wèn)題。谷歌推出SPDY，才算是正式改造HTTP協(xié)議本身。降低延遲，壓縮header等等，SPDY的實(shí)踐證明了這些優(yōu)化的效果，也最終帶來(lái)HTTP/2的誕生。

SPDY 協(xié)議在Chrome瀏覽器上證明可行以后，就被當(dāng)作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。

四、HTTP/2 簡(jiǎn)介

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

HTTP/2由兩個(gè)規(guī)范(Specification)組成：

Hypertext Transfer Protocol version 2 - RFC7540

HPACK - Header Compression for HTTP/2 - RFC7541

五、HTTP/2 新特性

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

HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP 1.x 的文本格式，二進(jìn)制協(xié)議解析起來(lái)更高效。 HTTP / 1 的請(qǐng)求和響應(yīng)報(bào)文，都是由起始行，首部和實(shí)體正文(可選)組成，各部分之間以文本換行符分隔。HTTP/2 將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼。

接下來(lái)我們介紹幾個(gè)重要的概念：

流：流是連接中的一個(gè)虛擬信道，可以承載雙向的消息;每個(gè)流都有一個(gè)唯一的整數(shù)標(biāo)識(shí)符(1、2…N);

消息：是指邏輯上的 HTTP 消息，比如請(qǐng)求、響應(yīng)等，由一或多個(gè)幀組成。

幀：HTTP 2.0 通信的最小單位，每個(gè)幀包含幀首部，至少也會(huì)標(biāo)識(shí)出當(dāng)前幀所屬的流，承載著特定類(lèi)型的數(shù)據(jù)，如 HTTP 首部、負(fù)荷，等等

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

2.多路復(fù)用

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

大家可以通過(guò) 該鏈接 直觀感受下 HTTP/2 比 HTTP/1 到底快了多少。

在 HTTP/2 中，有了二進(jìn)制分幀之后，HTTP /2 不再依賴(lài) TCP 鏈接去實(shí)現(xiàn)多流并行了，在 HTTP/2中：

• 同域名下所有通信都在單個(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è) TCP 連接而帶來(lái)的延時(shí)和內(nèi)存消耗。
• 并行交錯(cuò)地發(fā)送多個(gè)請(qǐng)求，請(qǐng)求之間互不影響。
• 并行交錯(cuò)地發(fā)送多個(gè)響應(yīng)，響應(yīng)之間互不干擾。
• 在HTTP/2中，每個(gè)請(qǐng)求都可以帶一個(gè)31bit的優(yōu)先值，0表示最高優(yōu)先級(jí)， 數(shù)值越大優(yōu)先級(jí)越低。有了這個(gè)優(yōu)先值，客戶(hù)端和服務(wù)器就可以在處理不同的流時(shí)采取不同的策略，以最優(yōu)的方式發(fā)送流、消息和幀。

如上圖所示，多路復(fù)用的技術(shù)可以只通過(guò)一個(gè) TCP 連接就可以傳輸所有的請(qǐng)求數(shù)據(jù)。

3.Header 壓縮

在 HTTP/1 中，我們使用文本的形式傳輸 header，在 header 攜帶 cookie 的情況下，可能每次都需要重復(fù)傳輸幾百到幾千的字節(jié)。

為了減少這塊的資源消耗并提升性能， HTTP/2對(duì)這些首部采取了壓縮策略：

• HTTP/2在客戶(hù)端和服務(wù)器端使用“首部表”來(lái)跟蹤和存儲(chǔ)之前發(fā)送的鍵-值對(duì)，對(duì)于相同的數(shù)據(jù)，不再通過(guò)每次請(qǐng)求和響應(yīng)發(fā)送;
• 首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶(hù)端和服務(wù)器共同漸進(jìn)地更新;
• 每個(gè)新的首部鍵-值對(duì)要么被追加到當(dāng)前表的末尾，要么替換表中之前的值

例如下圖中的兩個(gè)請(qǐng)求， 請(qǐng)求一發(fā)送了所有的頭部字段，第二個(gè)請(qǐng)求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開(kāi)銷(xiāo)

4.Server Push

Server Push即服務(wù)端能通過(guò)push的方式將客戶(hù)端需要的內(nèi)容預(yù)先推送過(guò)去，也叫“cache push”。

可以想象以下情況，某些資源客戶(hù)端是一定會(huì)請(qǐng)求的，這時(shí)就可以采取服務(wù)端 push 的技術(shù)，提前給客戶(hù)端推送必要的資源，這樣就可以相對(duì)減少一點(diǎn)延遲時(shí)間。當(dāng)然在瀏覽器兼容的情況下你也可以使用 prefetch。

例如服務(wù)端可以主動(dòng)把JS和CSS文件推送給客戶(hù)端，而不需要客戶(hù)端解析HTML時(shí)再發(fā)送這些請(qǐng)求。

服務(wù)端可以主動(dòng)推送，客戶(hù)端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過(guò)，瀏覽器可以通過(guò)發(fā)送RST_STREAM幀來(lái)拒收。主動(dòng)推送也遵守同源策略，換句話(huà)說(shuō)，服務(wù)器不能隨便將第三方資源推送給客戶(hù)端，而必須是經(jīng)過(guò)雙方確認(rèn)才行。

六、HTTP/3 新特性

1.HTTP/3簡(jiǎn)介

雖然 HTTP/2 解決了很多之前舊版本的問(wèn)題，但是它還是存在一個(gè)巨大的問(wèn)題，主要是底層支撐的 TCP 協(xié)議造成的。

上文提到 HTTP/2 使用了多路復(fù)用，一般來(lái)說(shuō)同一域名下只需要使用一個(gè) TCP 連接。但當(dāng)這個(gè)連接中出現(xiàn)了丟包的情況，那就會(huì)導(dǎo)致 HTTP/2 的表現(xiàn)情況反倒不如 HTTP/1 了。

因?yàn)樵诔霈F(xiàn)丟包的情況下，整個(gè) TCP 都要開(kāi)始等待重傳，也就導(dǎo)致了后面的所有數(shù)據(jù)都被阻塞了。但是對(duì)于 HTTP/1.1 來(lái)說(shuō)，可以開(kāi)啟多個(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)的，更新起來(lái)不大現(xiàn)實(shí)。

基于這個(gè)原因，Google 就更起爐灶搞了一個(gè)基于 UDP 協(xié)議的 QUIC 協(xié)議，并且使用在了 HTTP/3 上，HTTP/3 之前名為 HTTP-over-QUIC，從這個(gè)名字中我們也可以發(fā)現(xiàn)，HTTP/3 最大的改造就是使用了 QUIC。

QUIC 雖然基于 UDP，但是在原本的基礎(chǔ)上新增了很多功能，接下來(lái)我們重點(diǎn)介紹幾個(gè)QUIC新功能。

2.QUIC新功能

0-RTT

通過(guò)使用類(lèi)似 TCP 快速打開(kāi)的技術(shù)，緩存當(dāng)前會(huì)話(huà)的上下文，在下次恢復(fù)會(huì)話(huà)的時(shí)候，只需要將之前的緩存?zhèn)鬟f給服務(wù)端驗(yàn)證通過(guò)就可以進(jìn)行傳輸了。0RTT 建連可以說(shuō)是 QUIC 相比 HTTP2 最大的性能優(yōu)勢(shì)。那什么是 0RTT 建連呢?

這里面有兩層含義:

1.傳輸層 0RTT 就能建立連接。

2.加密層 0RTT 就能建立加密連接。

上圖左邊是 HTTPS 的一次完全握手的建連過(guò)程，需要 3 個(gè) RTT。就算是會(huì)話(huà)復(fù)用也需要至少 2 個(gè) RTT。

而 QUIC 呢?由于建立在 UDP 的基礎(chǔ)上，同時(shí)又實(shí)現(xiàn)了 0RTT 的安全握手，所以在大部分情況下，只需要 0 個(gè) RTT 就能實(shí)現(xiàn)數(shù)據(jù)發(fā)送，在實(shí)現(xiàn)前向加密的基礎(chǔ)上，并且 0RTT 的成功率相比 TLS 的會(huì)話(huà)記錄單要高很多。

多路復(fù)用

雖然 HTTP/2 支持了多路復(fù)用，但是 TCP 協(xié)議終究是沒(méi)有這個(gè)功能的。QUIC 原生就實(shí)現(xiàn)了這個(gè)功能，并且傳輸?shù)膯蝹€(gè)數(shù)據(jù)流可以保證有序交付且不會(huì)影響其他的數(shù)據(jù)流，這樣的技術(shù)就解決了之前 TCP 存在的問(wèn)題。

同HTTP2.0一樣，同一條 QUIC連接上可以創(chuàng)建多個(gè)stream，來(lái)發(fā)送多個(gè)HTTP請(qǐng)求，但是，QUIC是基于UDP的，一個(gè)連接上的多個(gè)stream之間沒(méi)有依賴(lài)。比如下圖中stream2丟了一個(gè)UDP包，不會(huì)影響后面跟著 Stream3 和 Stream4，不存在 TCP 隊(duì)頭阻塞。雖然stream2的那個(gè)包需要重新傳，但是stream3、stream4的包無(wú)需等待，就可以發(fā)給用戶(hù)。

另外QUIC 在移動(dòng)端的表現(xiàn)也會(huì)比 TCP 好。因?yàn)?TCP 是基于 IP 和端口去識(shí)別連接的，這種方式在多變的移動(dòng)端網(wǎng)絡(luò)環(huán)境下是很脆弱的。但是 QUIC 是通過(guò) ID 的方式去識(shí)別一個(gè)連接，不管你網(wǎng)絡(luò)環(huán)境如何變化，只要 ID 不變，就能迅速重連上。

加密認(rèn)證的報(bào)文

TCP 協(xié)議頭部沒(méi)有經(jīng)過(guò)任何加密和認(rèn)證，所以在傳輸過(guò)程中很容易被中間網(wǎng)絡(luò)設(shè)備篡改，注入和竊聽(tīng)。比如修改序列號(hào)、滑動(dòng)窗口。這些行為有可能是出于性能優(yōu)化，也有可能是主動(dòng)攻擊。

但是 QUIC 的 packet 可以說(shuō)是武裝到了牙齒。除了個(gè)別報(bào)文比如 PUBLIC_RESET 和 CHLO，所有報(bào)文頭部都是經(jīng)過(guò)認(rèn)證的，報(bào)文 Body 都是經(jīng)過(guò)加密的。

這樣只要對(duì) QUIC 報(bào)文任何修改，接收端都能夠及時(shí)發(fā)現(xiàn)，有效地降低了安全風(fēng)險(xiǎn)。

如上圖所示，紅色部分是 Stream Frame 的報(bào)文頭部，有認(rèn)證。綠色部分是報(bào)文內(nèi)容，全部經(jīng)過(guò)加密。

向前糾錯(cuò)機(jī)制

QUIC協(xié)議有一個(gè)非常獨(dú)特的特性，稱(chēng)為向前糾錯(cuò) (Forward Error Correction，F(xiàn)EC)，每個(gè)數(shù)據(jù)包除了它本身的內(nèi)容之外，還包括了部分其他數(shù)據(jù)包的數(shù)據(jù)，因此少量的丟包可以通過(guò)其他包的冗余數(shù)據(jù)直接組裝而無(wú)需重傳。向前糾錯(cuò)犧牲了每個(gè)數(shù)據(jù)包可以發(fā)送數(shù)據(jù)的上限，但是減少了因?yàn)閬G包導(dǎo)致的數(shù)據(jù)重傳，因?yàn)閿?shù)據(jù)重傳將會(huì)消耗更多的時(shí)間(包括確認(rèn)數(shù)據(jù)包丟失、請(qǐng)求重傳、等待新數(shù)據(jù)包等步驟的時(shí)間消耗)

假如說(shuō)這次我要發(fā)送三個(gè)包，那么協(xié)議會(huì)算出這三個(gè)包的異或值并單獨(dú)發(fā)出一個(gè)校驗(yàn)包，也就是總共發(fā)出了四個(gè)包。當(dāng)出現(xiàn)其中的非校驗(yàn)包丟包的情況時(shí)，可以通過(guò)另外三個(gè)包計(jì)算出丟失的數(shù)據(jù)包的內(nèi)容。當(dāng)然這種技術(shù)只能使用在丟失一個(gè)包的情況下，如果出現(xiàn)丟失多個(gè)包就不能使用糾錯(cuò)機(jī)制了，只能使用重傳的方式了。

七、總結(jié)

HTTP/1.x 有連接無(wú)法復(fù)用、隊(duì)頭阻塞、協(xié)議開(kāi)銷(xiāo)大和安全因素等多個(gè)缺陷

HTTP/2 通過(guò)多路復(fù)用、二進(jìn)制流、Header 壓縮等等技術(shù)，極大地提高了性能，但是還是存在著問(wèn)題的

QUIC 基于 UDP 實(shí)現(xiàn)，是 HTTP/3 中的底層支撐協(xié)議，該協(xié)議基于 UDP，又取了 TCP 中的精華，實(shí)現(xiàn)了即快又可靠的協(xié)議