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

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

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

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

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

HTTP/2.0

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

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

HTTP/2.0 還能夠將要傳輸的信息拆分為幀，并對它們進行二進制格式編碼。也就是說，HTTP/2.0 會將 Header 頭和 Data 數據分別進行拆分，而且拆分之后的二進制格式位于多個 stream 中。下面來看張圖。

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

QUIC 協議

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

這就是 TCP 連接的癥結所在。

鑒于這個問題，我們先把 TCP 放一放，先來認識一波 QUIC 協議。

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

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

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

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

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

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

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

在 TCP 中，TCP 為了保證數據的可靠性，使用了序號+確認號機制來實現，一旦帶有 synchronize sequence number 的包發送到服務器，服務器都會在一定時間內進行響應，如果過了這段時間沒有響應，客戶端就會重傳這個包，直到服務器收到數據包并作出響應為止。

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

TCP 一般采用的是自適應重傳算法，這個超時時間會根據往返時間 RTT 動態調整的。每次客戶端都會使用相同的 syn 來判斷超時時間，導致這個 RTT 的結果計算的不太準確。

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

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

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

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

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

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

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

TCP 基礎知識

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

而 QUIC 也實現了流量控制，QUIC 的流量控制也是使用了窗口更新window_update，來告訴對端它可以接受的字節數。

TCP 協議頭部沒有經過加密和認證，所以在傳輸的過程中很可能被篡改，與之不同的是，QUIC 中的報文頭部都是經過認證，報文也經過加密處理。這樣只要對 QUIC 的報文有任何修改，接收端都能夠及時發現，保證了安全性。

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

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

連接平滑遷移指的是，你的手機或者移動設備在 4G 信號下和 WiFi 等網絡情況下切換，不會斷線重連，用戶甚至無任何感知，能夠直接實現平滑的信號切換。

QUIC 相關資料

QUIC 協議比較復雜，想自己完全實現一套對筆者來說還比較困難。

讀者有興趣的話可以先看看開源實現有哪些。

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

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

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

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

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

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

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

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

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

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