談談quic協議原理（淺談QUIC協議原理與性能分析及部署方案）

2023-05-08 17:11:00 2

之前寫過《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