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

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

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

編輯搜圖

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

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

HTTP/2.0

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

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

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

編輯搜圖

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

QUIC 協(xié)議

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

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

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

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

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

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

編輯搜圖

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

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

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

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

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

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

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

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

編輯搜圖

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

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

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

編輯搜圖

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

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

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

TCP 基礎知識

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

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

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

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

• 使用 UDP 協(xié)議，不需要三次連接進行握手，而且也會縮短 TLS 建立連接的時間。

• 解決了隊頭阻塞問題

• 實現(xiàn)動態(tài)可插拔，在應用層實現(xiàn)了擁塞控制算法，可以隨時切換。

• 報文頭和報文體分別進行認證和加密處理，保障安全性。

• 連接能夠平滑遷移

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

QUIC 相關資料

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

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

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

這個是官方支持的。優(yōu)點自然很多，Google 官方維護基本沒有坑，隨時可以跟隨 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 剝離的，好幾年不維護了，僅支持到 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 許可，目前看是比較好的方案。

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