之前寫過《http1.0 與 http1.1的差別》 與 《再談HTTP2性能提升之背後原理—HTTP2曆史解剖》，QUIC協定，現在nginx官方也即将支援。是以還是得跟上時代腳步。
QUIC簡史
QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于UDP的傳輸協定，它實作了TCP + HTTPS + HTTP/2的功能，目的是保證可靠性的同時降低網絡延遲。因為UDP是一個簡單傳輸協定，基于UDP可以擺脫TCP傳輸确認、重傳慢啟動等因素，建立安全連接配接隻需要一的個往返時間，它還實作了HTTP/2多路複用、頭部壓縮等功能。
為什麼要使用QUIC
衆所周知UDP比TCP傳輸速度快，TCP是可靠協定，但是代價就是 雙方确認資料而衍生的一系列消耗，可以參看《再深談TCP/IP三步握手&四步揮手原理及衍生問題—長文解剖IP》。其次TCP是系統核心實作的，如果更新TCP協定，就得讓使用者更新系統，這個的門檻比較高，而QUIC在UPD基礎上由用戶端自由發揮，隻要有伺服器能對接就可以。
這些不止讓傳輸速度更快，多路複用等優勢，還可應付移動網絡裡面頻發的切換。這些都是quic的優勢。
QUIC優勢
連接配接建立延時低
QUIC隻需要一次往返就能建立HTTPS連接配接
改進的擁塞控制
TCP 的擁塞控制實際上包含了四個算法：慢啟動，擁塞避免，快速重傳，快速恢複。
QUIC 協定目前預設使用了 TCP 協定的 Cubic 擁塞控制算法，同時也支援 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法
QUIC的NACK比TCP的延遲确認機制高效
TCP 為了保證可靠性，使用了基于位元組序号的 Sequence Number 及 Ack 來确認消息的有序到達。
QUIC 同樣是一個可靠的協定，它使用 Packet Number 代替了 TCP 的 sequence number，并且每個 Packet Number 都嚴格遞增，也就是說就算 Packet N 丢失了，重傳的 Packet N 的 Packet Number 已經不是 N，而是一個比 N 大的值。而 TCP 呢，重傳 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不變，也正是由于這個特性，引入了 Tcp 重傳的歧義問題。
在普通的TCP裡面，如果發送方收到三個重複的ACK就會觸發快速重傳，如果太久沒收到ACK就會觸發逾時重傳，而使用NACK可以直接告知發送方哪些包丢了，不用等到逾時重傳。TCP有一個SACK的選項，也具備NACK的功能，QUIC的NACK有一個差別它每次重傳的封包序号都是新的。
但是單純依靠嚴格遞增的 Packet Number 肯定是無法保證資料的順序性和可靠性。QUIC 又引入了一個 Stream Offset 的概念。
即一個 Stream 可以經過多個 Packet 傳輸，Packet Number 嚴格遞增，沒有依賴。但是 Packet 裡的 Payload 如果是 Stream 的話，就需要依靠 Stream 的 Offset 來保證應用資料的順序。如錯誤! 未找到引用源。所示，發送端先後發送了 Pakcet N 和 Pakcet N+1，Stream 的 Offset 分别是 x 和 x+y。
假設 Packet N 丢失了，發起重傳，重傳的 Packet Number 是 N+2，但是它的 Stream 的 Offset 依然是 x，這樣就算 Packet N + 2 是後到的，依然可以将 Stream x 和 Stream x+y 按照順序組織起來，交給應用程式處理。
FEC前向糾正擁塞控制
FEC是Forward Error Correction前向錯誤糾正的意思，就是通過多發一些備援的包，當有些包丢失時，可以通過備援的包恢複出來，而不用重傳。這個算法在多媒體網關擁塞控制有重要的地位。QUIC的FEC是使用的XOR的方式，即發N + 1個包，多發一個備援的包，在正常資料的N個包裡面任意一個包丢了，可以通過這個備援的包恢複出來，使用異或可以做到
切換網絡操持連接配接
經常會有從4G切換到wifi網絡或者是從wifi切換到4G網絡的場景，由于網絡的IP變了，導緻需要重建立立連接配接，而QUIC使用一個ID來标志連接配接，即使切換網絡也可以使用之前的建立連接配接的資料如交換的密鑰，而不用再重新HTTPS握手，不過切換的過程可能會導緻有些包丢了，需要利用FEC恢複或者重傳。
更安全的傳輸協定
TCP 協定頭部沒有經過任何加密和認證，是以在傳輸過程中很容易被中間網絡裝置篡改，注入和竊聽。比如修改序列号、滑動視窗。這些行為有可能是出于性能優化，也有可能是主動攻擊。
但是 QUIC 的 packet 可以說是武裝到了牙齒。除了個别封包比如 PUBLIC_RESET 和 CHLO，所有封包頭部都是經過認證的，封包 Body 都是經過加密的。
這樣隻要對 QUIC 封包任何修改，接收端都能夠及時發現，有效地降低了安全風險。
如下圖所示，紅色部分是 Stream Frame 的封包頭部，有認證。綠色部分是封包内容，全部經過加密。
這一切，歸功于 UDP的不可靠 變為可靠。
強烈推薦：
讓網際網路更快：新一代QUIC協定在騰訊的技術實踐分享 https://www.cnblogs.com/jb2011/p/8458549.html
QUIC協定的分析，性能測試以及在QQ會員實踐 https://wetest.qq.com/lab/view/384.html
如何部署QUIC
如今業界nginx打頭陣(反向代理、負債均衡、轉發)的頭号代表(占統治地位)，且看官方：
https://www.nginx.com/blog/nginx-f5-continued-commitment-open-source/
…………
And we’re not stopping there. Our plan for 2019 is to accelerate open source development with even more capabilities. Notable roadmap items include:
NGINX – QUIC and HTTP/3 implementations, as well as support for asynchronous file open
NGINX Unit – Java servlet containers, proxying capabilities, static file support
njs – Support for JavaScript modules (import/export) and deeper NGINX integrations
…………
現在上的話，就Canddy(監聽UDP 443端口) 和nginx配合打法。
具體步驟，推薦 ：《前衛一下：給你的網站開啟 QUIC——https://www.bennythink.com/quic.html 》
參考網站：
怎樣把網站更新到QUIC及QUIC特性分析 https://zhuanlan.zhihu.com/p/37919534
轉載本站文章《淺談QUIC協定原理與性能分析及部署方案》,
請注明出處：https://www.zhoulujun.cn/html/theory/ComputerScienceTechnology/network/2016_0217_5689.html