QUIC 網絡傳輸協議

小結：

1）跟 TCP 用四元組標識一個唯一連接不同，QUIC 使用一個 64 位的 ConnectionID 來標識連接，基於這個特點，QUIC 的使用連接遷移機制，在四元組發生變化時（比如客戶端從 WIFI 切換到蜂窩網絡），嘗試“保留”先前的連接，從而維持數據傳輸不中斷。

 

提速 30%！騰訊TQUIC 網絡傳輸協議 https://mp.weixin.qq.com/s/Sf8JsZKeZYxT9WBZrh_etg

提速 30%！騰訊TQUIC 網絡傳輸協議

sTGW-QUIC 騰訊技術工程 2021-11-29 18:00

作者：騰訊 sTGW-TQUIC

騰訊sTGW如何助力核心業務用戶登錄耗時降低30%，下載場景500ms內請求成功率從HTTPS的60%提升到90%，移動端APP在弱網、跨網場景下同樣取得媲美正常網絡的用戶體驗。

騰訊核心業務用戶登錄耗時降低 30%，下載場景 500ms 內請求成功率從 HTTPS 的 60%提升到 90%，騰訊的移動端 APP 在弱網、跨網場景下取得媲美正常網絡的用戶體驗。這是騰訊網關 sTGW 團隊打造的 TQUIC 網絡協議棧在實時通信、音視頻、在線游戲、在線廣告等多個騰訊業務落地取得的成果。TQUIC 基於下一代互聯網傳輸協議 HTTP3/QUIC 深度優化，日均請求量級突破千億次，在騰訊雲 CLB、CDN 開放雲客戶使用。

 

本文重點分享了 sTGW 團隊在協議棧基礎能力、私有協議、明文傳輸等功能，並且針對弱網場景，分享騰訊如何基於 0-RTT 握手、連接遷移、實時傳輸等能力幫助業務用戶體驗提升。

 

一、 QUIC/HTTP3 協議介紹

QUIC 全稱 quick udp internet connection，“快速 UDP 互聯網連接”，（和英文 quick 諧音，簡稱“快”）是由 Google 提出的基於 UDP 進行可靠傳輸的協議。QUIC 在應用層實現了丟包恢復、擁塞控制、滑窗機制等保證數據傳輸的可靠性，同時對傳輸的數據具備前向安全的加密能力。HTTP3 則是 IETF(互聯網工程任務組)基於 QUIC 協議基礎進行設計的新一代 HTTP 協議。

QUIC/HTTP3 分層模型及與 HTTP2 對比：

二、 QUIC 核心優勢是什么？

1. 0-RTT 建立連接

QUIC 基於的 UDP 協議本身無需握手，並且它早於 TLS 1.3 協議，就實現了自己的 0-RTT 加密握手。下圖分別代表了 1-RTT 握手（首次建連），成功的 0-RTT 握手，以及失敗回退的握手。

2.無隊頭阻塞的多路復用

相比於 HTTP/2 的多路復用，QUIC 不會受到隊頭阻塞的影響，各個流更獨立，多路復用的效果也更好。

3.連接遷移

跟 TCP 用四元組標識一個唯一連接不同，QUIC 使用一個 64 位的 ConnectionID 來標識連接，基於這個特點，QUIC 的使用連接遷移機制，在四元組發生變化時（比如客戶端從 WIFI 切換到蜂窩網絡），嘗試“保留”先前的連接，從而維持數據傳輸不中斷。

4.全應用態協議棧

QUIC 核心邏輯都在用戶態，能靈活的修改連接參數、替換擁塞算法、更改傳輸行為。而 TCP 核心實現在內核態，改造需要修改內核並且進行系統重啟，成本極高。

三、 QUIC 網絡協議棧的選型

雖然 QUIC 各個特性看上去很美好，但需要客戶端/服務端的網絡協議棧都支持 QUIC 協議。截止目前，除 iOS 15 在指定接口 NSURLSession 及限制條件前提下，支持了 HTTP3，其他系統及主流網絡庫均不支持 QUIC。

如何讓業務快速將 QUIC 協議用起來，用這些先性加速網絡性能？QUIC 協議棧的實現成本非常高，主要體現在兩方面：

1. 實現復雜度很高，如上面介紹，QUIC/HTTP3 橫跨傳輸層、安全、應用層，相當於要把 TCP+TLS+HTTP 重新實現一次。

2. QUIC 一直保持着高速發展，分為 gQUIC（Google QUIC）、iQUIC(IETF-QUIC)兩大類，衍生的 QUIC 子版本有幾十個。

為了快速把 QUIC 協議落地，給業務提升網絡性能，我們選擇了開源的 Chromium cronet 網絡協議棧作為基礎。Chomium，作為占領全球瀏覽器絕對地位的 Chrome 的開源代碼,有 Google 強大的研發團隊支撐，其網絡協議棧是一個相對獨立的組件，被稱為 Cronet。

• 協議棧完整性：完善的 QUIC 協議棧，還包括 HTTP2/WEBSOCKET/FTP/SOCKS 協議；
• QUIC 版本支持：支持 gQUIC 和 iQUIC，並且還在不斷保持更新；
• 跨平台性：非常好，基於 chrome 的跨平台能力，對於各類操作系統、終端都有適配。

 

四、QUIC 協議棧的工程實踐

Cronet 能直接用起來嗎？結合我們的實踐與業務同學的反饋，直接使用的問題和接入困難度是比較大的。

問題一：代碼體積過大，邏輯層級多，不利於集成和安裝包體積控制（移動端）

Cronet 核心及關聯的第三方庫代碼有大概 85w 行，涉及 2800 多個類。但其實 Cronet 里大部分代碼都與 QUIC 沒有關系，由於其作為瀏覽器的網絡協議棧，集成了大量瀏覽器行為邏輯，而這些能力對於網絡協議棧是不需要的。

其次，QUIC 協議只是 Cronet 里眾多通信協議之一，除 QUIC 外的其他協議，通用的平台或軟件（例如 Nginx）本身就已經有實現，沒有必要重復建設,這些協議的存在除了增加協議棧內部邏輯復雜度，還增大了整個庫的體積，例如在安卓平台上，cronet 動態庫的體積接近 3MB，這對於一些體積敏感的應用是一個巨大的挑戰。

針對體積問題，我們進行了代碼精簡和 lib 體積縮減的探究。

第一步，分析歸納

通過對 cronet 代碼的分析和理解，冗余的代碼被我們分成了三種：

1. 無用的內部邏輯，例如 HTTP 模塊里包含了很多瀏覽器才會用到的代碼和功能；

2. 無需用到的的協議，例如 FTP、Websocket 等；

3. 與 quic 無關的功能模塊，例如 tcp 連接池等。

第二步，代碼裁剪

針對分析歸納中的三種問題，我們做了針對性的裁剪。首先是精簡了關鍵類，例如協議管控的類中，核心流程步驟被從 21 步壓縮到了 5 步，函數數量從 146 個減少到 24 個，將瀏覽器相關的冗余邏輯去除。

接着對用不到的協議類型、模塊組件做了剔除。裁剪后的效果如下：

五、打磨協議棧的易用性

雖然在工程方向，解決了體積大小和編譯集成的問題。實際接入使用時，Cronet 的易用性依然不夠好。

通過挖掘業務需求，尋找共性，我們整理出了如下痛點：

在通道直連方面，我們將底層 udp socket 粒度的接口進行封裝后直接對外可見，用戶可通過 socket 粒度的接口直接發起 IP 直連的 QUIC 請求，同時也保留了 DNS 建連能力，在保持原生能力的同時，拓展了用戶的使用場景。

在網絡參數配置和性能數據打點能力上，我們深入協議棧細節，逐個分析了多個核心模塊，將關鍵的參數和性能數據抽象出來。並且在控制面上將配置參數、性能打點整合對外呈現。

六、進階之路：私有協議和明文傳輸

除了基礎功能的打磨，TQUIC 協議棧也提供了進階功能進一步滿足業務豐富的使用需求。在 Cronet 中，要想使用 QUIC 協議，應用層傳輸的報文必須是 HTTP，也就是所謂的 HTTP3 協議。但 HTTP 報文對於游戲、音視頻等業務是個巨大的阻礙，它們當前都是通過 TCP 或者 UDP 傳輸自定義的協議的，如果為了接入 QUIC 而把應用層數據從私有協議強行改為 HTTP3，無疑是本末倒置。另外，由於是自定義協議，這些報文一般不需要 QUIC 進行加密，但加密是 QUIC 協議的標配，這會消耗額外的性能。

為此，在仔細研究了 Quic 核心代碼后，我們研發對私有協議、明文傳輸的支持，來滿足業務傳輸自定義協議的需求。首先是在 QuicStream 中，允許 stream 直接收發數據報文，HTTP 流程只是其中一個選擇。

為了實現明文傳輸，如果直接去改加解密流程，對代碼的入侵較大，如果考慮不周容易引入未知風險。為了盡量較少代碼入侵以及維護原生實現的安全運行，我們將 QuicFramer 中的加解密套件選擇處進行了 hook，引入了 FakeEncrypt/FakeDecrypt 替換真實的加解密套件，以極小的入侵代價低成本的實現了明文傳輸。

在做完明文傳輸方案后，我們意識到由於這是一個非常底層的修改，對於客戶端和服務端來需要高度一致的，要么雙端都選擇加密，要么雙端都選擇明文。如果雙端不統一，則握手就會失敗。為了使兼容性更好，減少運維成本和失敗風險，我們在握手協商過程中，加入了明文傳輸的協商。

如下圖流程，當前的握手過程，使用了 AEAD 這個 tag 標識了待協商的加密算法。

改進后，AEAD 可以攜帶明文的加密算法，客戶端如果也認可，則在下一次 CHLO 中選擇該算法，則之后兩邊都進行明文傳輸。

 

七、弱網優化之連接遷移

隨着移動互聯網的發展，移動端 APP 的能力越來越強大，我們可以輕松通過手機進行會議通話、視頻直播、在線游戲等，這類應用實時性要求很高。而移動端的特點是網絡會經常發生變化，例如通過手機進行在線會議的同時，從辦公區走到電梯，隨着網絡信號衰退到切換，APP 需要重新建立連接，這會觸發用戶重新登錄，體驗很差。前面背景介紹的 QUIC 連接遷移可以做到跨網場景自動遷移，業務無任何感知。那是不是使用 QUIC 后就可以直接用起來呢？

我們以 Google cronet 為例，在 iOS 下使用 Cronet 進行了一次切網嘗試，通過抓包發現網絡切換后，quic 其實進行了重新握手，並沒有如預期內的進行連接遷移。

通過代碼分析原因后，我們發現 Google 其實並沒有將連接遷移在各個系統版本上進行支持，僅在安卓平台“打折扣”的支持了，他們是在 java 層注冊系統通知才能使用連接遷移，對於 native 的網絡庫以及其他操作系統是很不友好的。既然原生實現並不好用，經過我們的改造，使用跨平台通用的內核層調用，達到了預期的效果，並且不依賴任何特定的操作系統組件。

在逐步的實踐過程中，我們還發現，如果僅僅是切網時候發起連接遷移並不完美。有時候客戶端處在弱網環境，wifi 信號並未徹底斷開，但傳輸數據實際上已經有損。為了解決這種場景下的問題，我們建立了一套弱網評估模型，通過主動探測和弱網評估進行啟發式分析，在數據通道有損的情況下，盡可能早的主動進行連接遷移，減少對上層業務的影響。

通過研發跨平台通用的連接遷移，以及啟發式主動遷移能力，最終在客戶端看到的連接遷移效果如下，當切網發生時，連接並未斷開，無需重連即可續傳數據。

業務在使用 QUIC 連接遷移后，對網絡切換無感知，數據不中斷。

或許有同學發現了，這里僅僅講了連接遷移在客戶端上的實現和效果，畢竟連接遷移后，客戶端源 IP 發生了變化，雲端接入層難道不需要做適配嗎？答案是需要的，sTGW 作為公司雲 CLB 和自研的主要七層網關接入，在 QUIC 連接遷移方面做了完整的解決方案，目前也已經將能力開放出來，在 QUIC 集群上全量上線。sTGW 對於連接遷移的解決方案可參見sTGW 大規模運營 QUIC 之路。

 

八、弱網優化之完全 0-RTT 握手與金融級前向安全

如下是 GQUIC 的握手流程，原生實現里，應用發生冷啟動時，首先會進行 1RTT 握手，拿到服務端的證書和 ServerConfig（簡稱 SCFG），隨后 SCFG 會被作為隨機數用於生成非前向安全的密鑰。

因此在下一次發送數據包時，便可用非前向安全的密鑰進行加密。直到收到了服務端發來的 Server Hello 后，通過類似 DHE 算法生成前向安全秘鑰，自此開始發送前向安全的數據包。

在原生實現中，SCFG 會被臨時存儲在進程內存堆區，下次發起新連接或者熱啟動時，直接就能進入 0-RTT 流程，但冷啟動則永遠是 1-RTT。基於原生的實現情況，我們針對握手流程做了兩個方向的優化。

1. 實現 100% 0-RTT 成功率，用於在握手時延極其敏感的業務上，例如廣告請求、API 調用、短連接下載等。

2. 強制前向安全，針對安全敏感型業務，例如金融業務，0-RTT 中發送的非前向安全數據包風險遠高於前向安全數據包，因此對於金融型業務，可以強制 1-RTT 握手生產前向安全密鑰后，再發送數據包。

改進后的兩種握手流程如下圖：

九、弱網優化之實時傳輸

實時傳輸是 QUIC 的一個拓展功能，目前在 IETF 草稿階段。實時傳輸適用於對數據可靠性要求不高，但非常注重數據實時性的業務。例如音視頻傳輸、互動游戲等。實時傳輸在 QUIC 中的定位，以及與可靠傳輸的區別如下：

相同點：

1. 在 QUIC 連接建立、創建 QUIC 數據包、數據加解密這些基礎功能，不可靠數據與可靠數據都是共用的。

2. 不可靠傳輸也有擁塞控制、ACK 機制，與可靠傳輸一致。

不同點：

1. 不可靠數據不受滑動窗口限制，滑窗窗口滿只限制可靠數據傳輸。

2. 發生丟包重傳時，只重傳可靠數據幀，不可靠數據幀不進行重傳。

不可靠數據沒有 quic stream 概念，只是 frame 粒度。這其中，一個關鍵點在於數據是否重傳，IETF 草稿的定義對這塊比較開放，可以完全不重傳，也可以選擇性重傳。

為此，TQUIC 在實現實時傳輸時，做了靈活的改造，對於實時傳輸的數據，提供多種重傳策略供使用者選擇，可以完全不重傳，也可以選擇性重傳某個重要的數據（比如關鍵幀），我們也在嘗試做動態重傳控制，依托我們的弱網判斷模型，動態調整重傳策略。

十、總結

經過騰訊 sTGW 團隊持續投入。TQUIC 在騰訊多個重要業務落地，覆蓋業務包括實時通信、音視頻、在線游戲、在線廣告等。在登錄成功率、登錄耗時、握手時延、下載速度等性能指標上均取得了明顯收益。騰訊雲客戶通過 CLB 使用 HTTP3 后，延遲降低了超過 20 個點，也歡迎大家接入使用。

附部分業務效果總結如下：

參考列表：

• https://datatracker.ietf.org/doc/html/rfc9000
• https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/?include_text=1
• https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit
• https://dl.acm.org/doi/abs/10.1145/3098822.3098842