建議閱讀本文需要搭配作者 HTTP 相關文章食用。
歷史 HTTP 系列文章：
這裡先來回顧一下 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 的流量控制是通過滑動視窗來實現的，如果你對滑動視窗不太熟悉，你可以看下我寫的這篇文章
在文章後面有提到了滑動視窗的一些概念。
而 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
原文連結：10 分鐘講完 QUIC 協議