這里先來回顧一下 HTTP 的發(fā)展過程。首先，我們想要一種能夠在網(wǎng)絡(luò)上獲取文檔內(nèi)容的協(xié)議，通過一種叫做 GET 請求的方式進(jìn)行獲取，后來這種 GET 請求被寫入了官方文檔，HTTP/1.0 應(yīng)運而生。HTTP/1.0 的出現(xiàn)可以說是顛覆性的，它里面涵蓋的一些標(biāo)準(zhǔn)我們目前還仍在使用，例如 HTTP header，協(xié)議號的概念，不過，這個版本的 HTTP 還有一些明顯的缺陷，比如它不支持持久性連接，每次請求響應(yīng)后，都需要斷開連接，這樣效率很差。沒過了多久，制定了 HTTP/1.1 標(biāo)準(zhǔn)，這個標(biāo)準(zhǔn)是互聯(lián)網(wǎng)上使用最頻繁的一個標(biāo)準(zhǔn)，HTTP/1.1 解決了之前不支持持久性連接的缺陷，而且 HTTP/1.1 還增加了緩存和控制模塊。

但是，即便 HTTP/1.1 解決了一部分連接性能問題，它的效率仍不是很高，而且 HTTP 還有一個隊頭阻塞問題(關(guān)于隊頭阻塞我已經(jīng)在 HTTP2.0 的那篇文章中進(jìn)行了說明和介紹。)

假如有五個請求被同時發(fā)出，如果第一個請求沒有處理完成，就會導(dǎo)致后續(xù)的請求也無法得到處理，如下圖所示

如果第一個請求沒有被處理，那么 2 3 4 5 這四個請求會直接阻塞在客戶端，等到請求 1 被處理完畢后，才能逐個發(fā)出。網(wǎng)絡(luò)通暢的時候性能影響不大，不過一旦請求 1 因為某些原因沒有抵達(dá)服務(wù)器，或者請求因為網(wǎng)絡(luò)阻塞沒有及時返回，影響的就是所有后續(xù)請求，導(dǎo)致后續(xù)請求無限阻塞下去，問題就變得比較嚴(yán)重了。

雖然 HTTP/1.1 使用了 pipling 的設(shè)計用于解決隊頭阻塞問題，但是在 pipling 的設(shè)計中，每個請求還是按照順序先發(fā)先回，并沒有從根本上解決問題。隨著協(xié)議的不斷更新，提出了 HTTP/2.0 。

HTTP/2.0

HTTP/2.0 解決隊頭阻塞的問題是采用了 stream 和分幀的方式。

HTTP/2.0 會將一個 TCP 連接切分成為多個 stream，每個 stream 都有自己的 stream id，這個 stream 可以是客戶端發(fā)往服務(wù)端，也可以是服務(wù)端發(fā)往客戶端。

HTTP/2.0 還能夠?qū)⒁獋鬏數(shù)男畔⒉鸱譃閹?，并對它們進(jìn)行二進(jìn)制格式編碼。也就是說，HTTP/2.0 會將 Header 頭和 Data 數(shù)據(jù)分別進(jìn)行拆分，而且拆分之后的二進(jìn)制格式位于多個 stream 中。下面來看張圖。

可以看到，HTTP/2.0 通過這兩種機(jī)制，將多個請求分到了不同的 stream 中，然后將請求進(jìn)行分幀，進(jìn)行二進(jìn)制傳輸，每個 stream 可以不用保證順序亂序發(fā)送，到達(dá)客戶端后，客戶端會根據(jù)每個 stream 進(jìn)行重組，而且可以根據(jù)優(yōu)先級來優(yōu)先處理哪個 stream。

QUIC 協(xié)議

雖然 HTTP/2.0 解決了隊頭阻塞問題，但是每個 HTTP 連接都是由 TCP 進(jìn)行連接建立和傳輸?shù)?，TCP 協(xié)議在處理包時有嚴(yán)格的順序要求。這也就是說，當(dāng)某個包切分的 stream 由于某些原因丟失后，服務(wù)器不會處理其他 stream，而會優(yōu)先等待客戶端發(fā)送丟失的 stream 。舉個例子來說，假如有一個請求有三個 stream，其中 stream2 由于某些原因丟失了，那么 stream1 和 stream 2 的處理也會阻塞，只有收到重發(fā)的 stream2 之后，服務(wù)器才會再次進(jìn)行處理。

這就是 TCP 連接的癥結(jié)所在。

鑒于這個問題，我們先把 TCP 放一放，先來認(rèn)識一波 QUIC 協(xié)議。

QUIC 的小寫是 quic，諧音 quick，意思就是快。它是 Google 提出來的一個基于 UDP 的傳輸協(xié)議，所以 QUIC 又被叫做快速 UDP 互聯(lián)網(wǎng)連接。

首先 QUIC 的第一個特征就是快，為什么說它快，它到底快在哪呢?

我們大家知道，HTTP 協(xié)議在傳輸層是使用了 TCP 進(jìn)行報文傳輸，而且 HTTPS 、HTTP/2.0 還采用了 TLS 協(xié)議進(jìn)行加密，這樣就會導(dǎo)致三次握手的連接延遲：即 TCP 三次握手(一次)和 TLS 握手(兩次)，如下圖所示。

對于很多短連接場景，這種握手延遲影響較大，而且無法消除。

相比之下，QUIC 的握手連接更快，因為它使用了 UDP 作為傳輸層協(xié)議，這樣能夠減少三次握手的時間延遲。而且 QUIC 的加密協(xié)議采用了 TLS 協(xié)議的最新版本 TLS 1.3，相對之前的 TLS 1.1-1.2，TLS1.3 允許客戶端無需等待 TLS 握手完成就開始發(fā)送應(yīng)用程序數(shù)據(jù)的操作，可以支持1 RTT 和 0 RTT，從而達(dá)到快速建立連接的效果。

我們上面還說過，HTTP/2.0 雖然解決了隊頭阻塞問題，但是其建立的連接還是基于 TCP，無法解決請求阻塞問題。

而 UDP 本身沒有建立連接這個概念，并且 QUIC 使用的 stream 之間是相互隔離的，不會阻塞其他 stream 數(shù)據(jù)的處理，所以使用 UDP 并不會造成隊頭阻塞。

在 TCP 中，TCP 為了保證數(shù)據(jù)的可靠性，使用了序號+確認(rèn)號機(jī)制來實現(xiàn)，一旦帶有 synchronize sequence number 的包發(fā)送到服務(wù)器，服務(wù)器都會在一定時間內(nèi)進(jìn)行響應(yīng)，如果過了這段時間沒有響應(yīng)，客戶端就會重傳這個包，直到服務(wù)器收到數(shù)據(jù)包并作出響應(yīng)為止。

那么 TCP 是如何判斷它的重傳超時時間呢?

TCP 一般采用的是自適應(yīng)重傳算法，這個超時時間會根據(jù)往返時間 RTT 動態(tài)調(diào)整的。每次客戶端都會使用相同的 syn 來判斷超時時間，導(dǎo)致這個 RTT 的結(jié)果計算的不太準(zhǔn)確。

雖然 QUIC 沒有使用 TCP 協(xié)議，但是它也保證了可靠性，QUIC 實現(xiàn)可靠性的機(jī)制是使用了 Packet Number，這個序列號可以認(rèn)為是 synchronize sequence number 的替代者，這個序列號也是遞增的。與 syn 所不同的是，不管服務(wù)器有沒有接收到數(shù)據(jù)包，這個 Packet Number 都會 + 1，而 syn 是只有服務(wù)器發(fā)送 ack 響應(yīng)之后，syn 才會 + 1。

比如有一個 PN = 10 的數(shù)據(jù)包在發(fā)送的過程中由于某些原因遲遲沒到服務(wù)器，那么客戶端會重傳一個 PN = 11 的數(shù)據(jù)包，經(jīng)過一段時間后客戶端收到 PN = 10 的響應(yīng)后再回送響應(yīng)報文，此時的 RTT 就是 PN = 10 這個數(shù)據(jù)包在網(wǎng)絡(luò)中的生存時間，這樣計算相對比較準(zhǔn)確。

雖然 QUIC 保證了數(shù)據(jù)包的可靠性，但是數(shù)據(jù)的可靠性是如何保證的呢?

QUIC 引入了一個 stream offset 的概念，一個 stream 可以傳輸多個 stream offset，每個 stream offset 其實就是一個 PN 標(biāo)識的數(shù)據(jù)，即使某個 PN 標(biāo)識的數(shù)據(jù)丟失，PN + 1 后，它重傳的仍舊是 PN 所標(biāo)識的數(shù)據(jù)，等到所有 PN 標(biāo)識的數(shù)據(jù)發(fā)送到服務(wù)器，就會進(jìn)行重組，以此來保證數(shù)據(jù)可靠性。到達(dá)服務(wù)器的 stream offset 會按照順序進(jìn)行組裝，這同時也保證了數(shù)據(jù)的順序性。

眾所周知，TCP 協(xié)議的具體實現(xiàn)是由操作系統(tǒng)內(nèi)核來完成的，應(yīng)用程序只能使用，不能對內(nèi)核進(jìn)行修改，隨著移動端和越來越多的設(shè)備接入互聯(lián)網(wǎng)，性能逐漸成為一個非常重要的衡量指標(biāo)。雖然移動網(wǎng)絡(luò)發(fā)展非常快，但是用戶端的更新卻非常緩慢，我仍然看見有很多地區(qū)很多計算機(jī)還仍舊使用 xp 系統(tǒng)，盡管它早已發(fā)展了很多年。服務(wù)端系統(tǒng)不依賴用戶升級，但是由于操作系統(tǒng)升級涉及到底層軟件和運行庫的更新，所以也比較保守和緩慢。

QUIC 協(xié)議的一個重要特點就是可插拔性，能夠動態(tài)更新和升級，QUIC 在應(yīng)用層實現(xiàn)了擁塞控制算法，不需要操作系統(tǒng)和內(nèi)核的支持，遇到擁塞控制算法切換時，只需要在服務(wù)器重新加載一遍即可，不需要停機(jī)和重啟。

我們知道 TCP 的流量控制是通過滑動窗口來實現(xiàn)的，如果你對滑動窗口不太熟悉，你可以看下我寫的這篇文章。

TCP 基礎(chǔ)知識

在文章后面有提到了滑動窗口的一些概念。

而 QUIC 也實現(xiàn)了流量控制，QUIC 的流量控制也是使用了窗口更新window_update，來告訴對端它可以接受的字節(jié)數(shù)。

TCP 協(xié)議頭部沒有經(jīng)過加密和認(rèn)證，所以在傳輸?shù)倪^程中很可能被篡改，與之不同的是，QUIC 中的報文頭部都是經(jīng)過認(rèn)證，報文也經(jīng)過加密處理。這樣只要對 QUIC 的報文有任何修改，接收端都能夠及時發(fā)現(xiàn)，保證了安全性。

總的來說，QUIC 相比于 HTTP/2.0 來說，具有下面這些優(yōu)勢

• 使用 UDP 協(xié)議，不需要三次連接進(jìn)行握手，而且也會縮短 TLS 建立連接的時間。
• 解決了隊頭阻塞問題
• 實現(xiàn)動態(tài)可插拔，在應(yīng)用層實現(xiàn)了擁塞控制算法，可以隨時切換。
• 報文頭和報文體分別進(jìn)行認(rèn)證和加密處理，保障安全性。
• 連接能夠平滑遷移

連接平滑遷移指的是，你的手機(jī)或者移動設(shè)備在 4G 信號下和 WiFi 等網(wǎng)絡(luò)情況下切換，不會斷線重連，用戶甚至無任何感知，能夠直接實現(xiàn)平滑的信號切換。

QUIC 相關(guān)資料

QUIC 協(xié)議比較復(fù)雜，想自己完全實現(xiàn)一套對筆者來說還比較困難。

讀者有興趣的話可以先看看開源實現(xiàn)有哪些。

1)Chromium：https://github.com/hanpfei/chromium-net

這個是官方支持的。優(yōu)點自然很多，Google 官方維護(hù)基本沒有坑，隨時可以跟隨 chrome 更新到最新版本。不過編譯 Chromium 比較麻煩，它有單獨的一套編譯工具。暫時不建議考慮這個方案。

2)proto-quic：https://github.com/google/proto-quic

從 chromium 剝離的一個 QUIC 協(xié)議部分，但是其 github 主頁已宣布不再支持，僅作實驗使用。不建議考慮這個方案。

3)goquic：https://github.com/devsisters/goquic

goquic 封裝了 libquic 的 go 語言封裝，而 libquic 也是從 chromium 剝離的，好幾年不維護(hù)了，僅支持到 quic-36， goquic 提供一個反向代理，測試發(fā)現(xiàn)由于 QUIC 版本太低，最新 chrome 瀏覽器已無法支持。不建議考慮這個方案。

4)quic-go：https://github.com/lucas-clemente/quic-go

quic-go 是完全用 go 寫的 QUIC 協(xié)議棧，開發(fā)很活躍，已在 Caddy 中使用，MIT 許可，目前看是比較好的方案。

那么，對于中小團(tuán)隊或個人開發(fā)者來說，比較推薦的方案是最后一個，即采用 caddy https://github.com/caddyserver/caddy/wiki/QUIC 來部署實現(xiàn) QUIC。caddy 這個項目本意并不是專門用來實現(xiàn) QUIC 的，它是用來實現(xiàn)一個免簽的 HTTPS web 服務(wù)器的(caddy 會自動續(xù)簽證書)。而QUIC 只是它的一個附屬功能(不過現(xiàn)實是——好像用它來實現(xiàn) QUIC 的人更多)。

從 Github 的技術(shù)趨勢來說，有關(guān) QUIC 的開源資源越來越多，有興趣可以自已逐一研究研究：https://github.com/search?q=quic