1、先聊聊什么是 HTTP：

我們通常所說的 HTTP(S)1.1 其實是由多個協(xié)議組成的：

1. HTTP協(xié)議：用來解析 url 和 數(shù)據(jù)。
2. TSL協(xié)議：用來對傳輸?shù)臄?shù)據(jù)進(jìn)行加密（即為 HTTPS 的 "S"）。
3. IP協(xié)議：用來定位客戶端與服務(wù)器，以便雙方通信。
4. TCP協(xié)議：用來確保數(shù)據(jù)完整、準(zhǔn)確地傳遞。

上述四種協(xié)議，在互聯(lián)網(wǎng)經(jīng)過這么多年發(fā)展后，其中 HTTP1.1協(xié)議 和 TCP協(xié)議 都各自暴露出一些問題。

而 HTTP2 則是為了解決 HTTP1.1協(xié)議 的一些問題。
<br />
而 HTTP3 則是為了解決 TCP協(xié)議 的一些問題。

2、HTTP1.1 的主要問題 和 HTTP2 對其的解決之道：

HTTP1.1 的主要問題：

1. HTTP協(xié)議的隊頭阻塞（Head-of-Line blocking）：HTTP1.1雖然實現(xiàn)了多個HTTP請求可以共用TCP管道。
   但建立TCP連接后，每條HTTP的 request 和 response 都是串行交互數(shù)據(jù)。所以若前面的 response 有延遲，就會阻塞后面的request，從而造成后續(xù)http請求的等待，進(jìn)而影響數(shù)據(jù)的傳輸速度。
2. 隊列堆積（Queueing）：瀏覽器對每個域名的http并發(fā)請求是有限制的（chrome為6個）,當(dāng)請求數(shù)量超過限制時，則新請求會進(jìn)入隊列等待，當(dāng)并發(fā)的請求過多時，也會造成阻塞。
3. 報文頭(Header)信息冗余：每次request都需要攜帶報文頭，且其數(shù)據(jù)非常冗余。
4. 自身沒有 加密 和 認(rèn)證機(jī)制。

HTTP2 針對 HTTP1.1 的優(yōu)化點：

1. 二進(jìn)制分幀（Binary Framing）:HTTP2在應(yīng)用層(HTTP)和傳輸層(TCP)之間加了一層 二進(jìn)制分幀層。將http1.1字符串的“大”數(shù)據(jù)，分割成多個“小”的二進(jìn)制數(shù)據(jù)。其好處：“二進(jìn)制”可以壓縮數(shù)據(jù)，而“分幀”將大數(shù)據(jù)變成多個小數(shù)據(jù)，以便“多路復(fù)用”（HTTP2相比HTTP1.1性能的提高主要是因為這一層的引入）。
2. 多路復(fù)用（Multiplexing）：其機(jī)制是在建立一個TCP管道中，可以同時收/發(fā)多個HTTP請求和二進(jìn)制幀，從而解決HTTP1.1的阻塞問題。
3. 對HTTP頭壓縮：HTTP1.1的header有很多信息，每次請求都要重復(fù)發(fā)送，而HTTP2對頭部信息進(jìn)行了壓縮。
4. 服務(wù)器推送：這個功能其實已事實上被廢棄，具體原因文末簡述。

3、TCP的主要問題 和 HTTP3 對其的解決之道：

HTTP3相比HTTP2本身升級不多，其重點是將 TCP協(xié)議 換成了 QUIC協(xié)議，以QUIC解決TCP的問題。

HTTP2 VS HTTP3

圖片來自 《http3-core-concepts》

TCP 的主要問題：

1. TCP沒有加密功能：TCP協(xié)議不包含TLS協(xié)議（即 HTTPS 的 "S"），使得現(xiàn)在 HTTPS 運行必須有 TCP 和 TLS 兩個協(xié)議的連接，才能傳輸數(shù)據(jù)。
2. TCP協(xié)議的隊頭阻塞（Head-of-Line blocking）：上文說到HTTP有隊頭阻塞，其實TCP也有隊頭阻塞。即TCP傳輸數(shù)據(jù)時會將數(shù)據(jù)拆分一個個順序的數(shù)據(jù)包，但傳輸過程中若某個數(shù)據(jù)包沒有按順序到達(dá)，則接收端會一直保持等待該數(shù)據(jù)包，這時候就會阻塞后續(xù)的數(shù)據(jù)傳輸。

QUIC 針對 TCP 的優(yōu)化點：

首先，QUIC協(xié)議基于已存在的UDP協(xié)議實現(xiàn)（其原因可見：What Is QUIC）

1. 整合TLS：從上圖可見，QUIC包含TLS，所以QUIC相比TCP天然更安全且建立時間更短（TCP協(xié)議建議鏈接需要額外建立TLS連接，而QUIC協(xié)議將兩者合二為一）。
2. 多路復(fù)用+二進(jìn)制分幀：其目的為解決TCP協(xié)議的隊頭阻塞。
3. 使用connection IDs：連接ID獨立于客戶端端口和IP地址，使得避免重復(fù)的連接握手。

最后總結(jié)：

1. 2.0到3.0不斷升級的目的：HTTP作為數(shù)據(jù)傳輸協(xié)議，技術(shù)發(fā)展的方向就是不斷提速；所以 HTTP2.0和HTTP3.0 分別對 HTTP協(xié)議 和 TCP協(xié)議 進(jìn)行了升級。其最大的目的都是：進(jìn)一步提速。
2. 分成兩次升級原因：同時升級HTTP和TCP兩大協(xié)議工作量巨大，所以互聯(lián)網(wǎng)工程任務(wù)組（IETF）將其升級一分為二。
3. QUIC協(xié)議基于UDP協(xié)議的原因：TCP作為傳輸層協(xié)議已廣泛被互聯(lián)網(wǎng)世界的中間硬件(如防火墻、網(wǎng)站、路由器等)所支持，而這些硬件升級非常慢，若斷然廢棄TCP協(xié)議而采用新協(xié)議，這些硬件無法良好支持。而UDP協(xié)議是古老的協(xié)議，上述這些硬件都默認(rèn)支持UDP，所以QUIC協(xié)議基于運行在UDP協(xié)議之上而設(shè)計。
4. HTTP2為什么廢棄服務(wù)端推送功能：具體原因見# Intent to Remove: HTTP/2 and gQUIC server push
   。HTTP3中用于替代 Websocket 的方案為：《# [譯]WebTransport 會在不久的將來取代 WebRTC 嗎？》