hi ，大家周五好，之前分享過一篇QUIC在螞蟻金服落地的文章：

實(shí)戰(zhàn)|QUIC協(xié)議在螞蟻集團(tuán)落地

今天我們分析一篇，QUIC在騰訊落地的文章，希望大家了解和學(xué)習(xí)新技術(shù)是如何在大廠落地，其中會(huì)遇到什么困難，技術(shù)難點(diǎn)攻破，以及工程實(shí)踐。

導(dǎo)語

騰訊核心業(yè)務(wù)用戶登錄耗時(shí)降低30%，下載場(chǎng)景500ms內(nèi)請(qǐng)求成功率從HTTPS的60%提升到90%，騰訊的移動(dòng)端APP在弱網(wǎng)、跨網(wǎng)場(chǎng)景下取得媲美正常網(wǎng)絡(luò)的用戶體驗(yàn)。這是騰訊網(wǎng)關(guān)sTGW團(tuán)隊(duì)打造的TQUIC網(wǎng)絡(luò)協(xié)議棧在實(shí)時(shí)通信、音視頻、在線游戲、在線廣告等多個(gè)騰訊業(yè)務(wù)落地取得的成果。

TQUIC基于下一代互聯(lián)網(wǎng)傳輸協(xié)議HTTP3/QUIC深度優(yōu)化，日均請(qǐng)求量級(jí)突破千億次，在騰訊云CLB、CDN開放云客戶使用。本文重點(diǎn)分享了sTGW團(tuán)隊(duì)在協(xié)議棧基礎(chǔ)能力、私有協(xié)議、明文傳輸?shù)裙δ苎邪l(fā)經(jīng)驗(yàn)，并且針對(duì)弱網(wǎng)場(chǎng)景，分享騰訊如何基于0-RTT握手、連接遷移、實(shí)時(shí)傳輸?shù)饶芰椭鷺I(yè)務(wù)用戶體驗(yàn)提升。

一、QUIC/HTTP3協(xié)議介紹

QUIC全稱quick udp internet connection，“快速UDP互聯(lián)網(wǎng)連接”，（和英文quick諧音，簡(jiǎn)稱“快”）是由Google提出的基于UDP進(jìn)行可靠傳輸?shù)膮f(xié)議。QUIC在應(yīng)用層實(shí)現(xiàn)了丟包恢復(fù)、擁塞控制、滑窗機(jī)制等保證數(shù)據(jù)傳輸?shù)目煽啃?#xff0c;同時(shí)對(duì)傳輸?shù)臄?shù)據(jù)具備前向安全的加密能力。HTTP3則是IETF(互聯(lián)網(wǎng)工程任務(wù)組)基于QUIC協(xié)議基礎(chǔ)進(jìn)行設(shè)計(jì)的新一代HTTP協(xié)議。

QUIC/HTTP3分層模型及與HTTP2對(duì)比：

二、QUIC核心優(yōu)勢(shì)是什么？

1

●

0-RTT建立連接

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

2

●

無隊(duì)頭阻塞的多路復(fù)用

相比于HTTP/2的多路復(fù)用，QUIC不會(huì)受到隊(duì)頭阻塞的影響，各個(gè)流更獨(dú)立，多路復(fù)用的效果也更好。

3

●

連接遷移

跟TCP用四元組標(biāo)識(shí)一個(gè)唯一連接不同，QUIC使用一個(gè)64位的ConnectionID來標(biāo)識(shí)連接，基于這個(gè)特點(diǎn)，QUIC的使用連接遷移機(jī)制，在四元組發(fā)生變化時(shí)（比如客戶端從WIFI切換到蜂窩網(wǎng)絡(luò)），嘗試“保留”先前的連接，從而維持?jǐn)?shù)據(jù)傳輸不中斷。

4

●

全應(yīng)用態(tài)協(xié)議棧

QUIC核心邏輯都在用戶態(tài)，能靈活的修改連接參數(shù)、替換擁塞算法、更改傳輸行為。而TCP核心實(shí)現(xiàn)在內(nèi)核態(tài)，改造需要修改內(nèi)核并且進(jìn)行系統(tǒng)重啟，成本極高。

三、QUIC網(wǎng)絡(luò)協(xié)議棧的選型

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

如何讓業(yè)務(wù)快速將QUIC協(xié)議用起來，用這些先進(jìn)特性加速網(wǎng)絡(luò)性能？

QUIC協(xié)議棧的實(shí)現(xiàn)成本非常高，主要體現(xiàn)在兩方面：

實(shí)現(xiàn)復(fù)雜度很高，如上面介紹，QUIC/HTTP3橫跨傳輸層、安全、應(yīng)用層，相當(dāng)于要把TCP+TLS+HTTP重新實(shí)現(xiàn)一次。

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

為了快速把QUIC協(xié)議落地，給業(yè)務(wù)提升網(wǎng)絡(luò)性能，我們選擇了開源的Chromium cronet網(wǎng)絡(luò)協(xié)議棧作為基礎(chǔ)。

Chomium，作為占領(lǐng)全球?yàn)g覽器絕對(duì)地位的Chrome的開源代碼,有Google強(qiáng)大的研發(fā)團(tuán)隊(duì)支撐，其網(wǎng)絡(luò)協(xié)議棧是一個(gè)相對(duì)獨(dú)立的組件，被稱為Cronet。

• 協(xié)議棧完整性：完善的QUIC協(xié)議棧，還包括HTTP2/WEBSOCKET/FTP/SOCKS協(xié)議。

• QUIC版本支持：支持gQUIC和iQUIC，并且還在不斷保持更新。

• 跨平臺(tái)性：非常好，基于chrome的跨平臺(tái)能力，對(duì)于各類操作系統(tǒng)、終端都有適配。

四、QUIC協(xié)議棧的工程實(shí)踐

Cronet能直接用起來嗎？結(jié)合我們的實(shí)踐與業(yè)務(wù)同學(xué)的反饋，直接使用的問題和接入困難度是比較大的。

問題一：代碼體積過大，邏輯層級(jí)多，不利于集成和安裝包體積控制（移動(dòng)端）

Cronet核心及關(guān)聯(lián)的第三方庫代碼有大概85w行，涉及2800多個(gè)類。但其實(shí)Cronet里大部分代碼都與QUIC沒有關(guān)系，由于其作為瀏覽器的網(wǎng)絡(luò)協(xié)議棧，集成了大量瀏覽器行為邏輯，而這些能力對(duì)于網(wǎng)絡(luò)協(xié)議棧是不需要的。

其次，QUIC協(xié)議只是Cronet里眾多通信協(xié)議之一，除QUIC外的其他協(xié)議，通用的平臺(tái)或軟件（例如Nginx）本身就已經(jīng)有實(shí)現(xiàn)，沒有必要重復(fù)建設(shè),這些協(xié)議的存在除了增加協(xié)議棧內(nèi)部邏輯復(fù)雜度，還增大了整個(gè)庫的體積，例如在安卓平臺(tái)上，cronet動(dòng)態(tài)庫的體積接近3MB，這對(duì)于一些體積敏感的應(yīng)用是一個(gè)巨大的挑戰(zhàn)。

針對(duì)體積問題，我們進(jìn)行了代碼精簡(jiǎn)和lib體積縮減的探究。

第一步，分析歸納

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

無用的內(nèi)部邏輯，例如HTTP模塊里包含了很多瀏覽器才會(huì)用到的代碼和功能。

無需用到的的協(xié)議，例如FTP、Websocket等

與quic無關(guān)的功能模塊，例如tcp連接池等

第二步，代碼裁剪

針對(duì)分析歸納中的三種問題，我們做了針對(duì)性的裁剪。

首先是精簡(jiǎn)了關(guān)鍵類，例如協(xié)議管控的類中，核心流程步驟被從21步壓縮到了5步，函數(shù)數(shù)量從146個(gè)減少到24個(gè)，將瀏覽器相關(guān)的冗余邏輯去除。

接著對(duì)用不到的協(xié)議類型、模塊組件做了剔除。裁剪后的效果如下：

五、打磨協(xié)議棧的易用性

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

通過挖掘業(yè)務(wù)需求，尋找共性，我們整理出了如下痛點(diǎn)：

在通道直連方面，我們將底層udp socket粒度的接口進(jìn)行封裝后直接對(duì)外可見，用戶可通過socket粒度的接口直接發(fā)起IP直連的QUIC請(qǐng)求，同時(shí)也保留了DNS建連能力，在保持原生能力的同時(shí)，拓展了用戶的使用場(chǎng)景。

在網(wǎng)絡(luò)參數(shù)配置和性能數(shù)據(jù)打點(diǎn)能力上，我們深入?yún)f(xié)議棧細(xì)節(jié)，逐個(gè)分析了多個(gè)核心模塊，將關(guān)鍵的參數(shù)和性能數(shù)據(jù)抽象出來。并且在控制面上將配置參數(shù)、性能打點(diǎn)整合對(duì)外呈現(xiàn)。

六、進(jìn)階之路：私有協(xié)議和明文傳輸

除了基礎(chǔ)功能的打磨，TQUIC協(xié)議棧也提供了進(jìn)階功能進(jìn)一步滿足業(yè)務(wù)豐富的使用需求。在Cronet中，要想使用QUIC協(xié)議，應(yīng)用層傳輸?shù)膱?bào)文必須是HTTP，也就是所謂的HTTP3協(xié)議。但HTTP報(bào)文對(duì)于游戲、音視頻等業(yè)務(wù)是個(gè)巨大的阻礙，它們當(dāng)前都是通過TCP或者UDP傳輸自定義的協(xié)議的，如果為了接入QUIC而把應(yīng)用層數(shù)據(jù)從私有協(xié)議強(qiáng)行改為HTTP3，無疑是本末倒置。另外，由于是自定義協(xié)議，這些報(bào)文一般不需要QUIC進(jìn)行加密，但加密是QUIC協(xié)議的標(biāo)配，這會(huì)消耗額外的性能。

為此，在仔細(xì)研究了Quic核心代碼后，我們研發(fā)對(duì)私有協(xié)議、明文傳輸?shù)闹С?#xff0c;來滿足業(yè)務(wù)傳輸自定義協(xié)議的需求。

首先是在QuicStream中，允許stream直接收發(fā)數(shù)據(jù)報(bào)文，HTTP流程只是其中一個(gè)選擇。

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

在做完明文傳輸方案后，我們意識(shí)到由于這是一個(gè)非常底層的修改，對(duì)于客戶端和服務(wù)端來需要高度一致的，要么雙端都選擇加密，要么雙端都選擇明文。如果雙端不統(tǒng)一，則握手就會(huì)失敗。為了使兼容性更好，減少運(yùn)維成本和失敗風(fēng)險(xiǎn)，我們?cè)谖帐謪f(xié)商過程中，加入了明文傳輸?shù)膮f(xié)商。

如下圖流程，當(dāng)前的握手過程，使用了AEAD這個(gè)tag標(biāo)識(shí)了待協(xié)商的加密算法。

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

七、弱網(wǎng)優(yōu)化之連接遷移

隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，移動(dòng)端APP的能力越來越強(qiáng)大，我們可以輕松通過手機(jī)進(jìn)行會(huì)議通話、視頻直播、在線游戲等，這類應(yīng)用實(shí)時(shí)性要求很高。而移動(dòng)端的特點(diǎn)是網(wǎng)絡(luò)會(huì)經(jīng)常發(fā)生變化，例如通過手機(jī)進(jìn)行在線會(huì)議的同時(shí)，從辦公區(qū)走到電梯，隨著網(wǎng)絡(luò)信號(hào)衰退到切換，APP需要重新建立連接，這會(huì)觸發(fā)用戶重新登錄，體驗(yàn)很差。前面背景介紹的QUIC連接遷移可以做到跨網(wǎng)場(chǎng)景自動(dòng)遷移，業(yè)務(wù)無任何感知。那是不是使用QUIC后就可以直接用起來呢？

我們以Google cronet為例，在iOS下使用Cronet進(jìn)行了一次切網(wǎng)嘗試，通過抓包發(fā)現(xiàn)網(wǎng)絡(luò)切換后，quic其實(shí)進(jìn)行了重新握手，并沒有如預(yù)期內(nèi)的進(jìn)行連接遷移。

通過代碼分析原因后，我們發(fā)現(xiàn)Google其實(shí)并沒有將連接遷移在各個(gè)系統(tǒng)版本上進(jìn)行支持，僅在安卓平臺(tái)“打折扣”的支持了，他們是在java層注冊(cè)系統(tǒng)通知才能使用連接遷移，對(duì)于native的網(wǎng)絡(luò)庫以及其他操作系統(tǒng)是很不友好的。

既然原生實(shí)現(xiàn)并不好用，經(jīng)過我們的改造，使用跨平臺(tái)通用的內(nèi)核層調(diào)用，達(dá)到了預(yù)期的效果，并且不依賴任何特定的操作系統(tǒng)組件。

在逐步的實(shí)踐過程中，我們還發(fā)現(xiàn)，如果僅僅是切網(wǎng)時(shí)候發(fā)起連接遷移并不完美。有時(shí)候客戶端處在弱網(wǎng)環(huán)境，wifi信號(hào)并未徹底斷開，但傳輸數(shù)據(jù)實(shí)際上已經(jīng)有損。為了解決這種場(chǎng)景下的問題，我們建立了一套弱網(wǎng)評(píng)估模型，通過主動(dòng)探測(cè)和弱網(wǎng)評(píng)估進(jìn)行啟發(fā)式分析，在數(shù)據(jù)通道有損的情況下，盡可能早的主動(dòng)進(jìn)行連接遷移，減少對(duì)上層業(yè)務(wù)的影響。

通過研發(fā)跨平臺(tái)通用的連接遷移，以及啟發(fā)式主動(dòng)遷移能力，最終在客戶端看到的連接遷移效果如下，當(dāng)切網(wǎng)發(fā)生時(shí)，連接并未斷開，無需重連即可續(xù)傳數(shù)據(jù)。

業(yè)務(wù)在使用QUIC連接遷移后，對(duì)網(wǎng)絡(luò)切換無感知，數(shù)據(jù)不中斷。

或許有同學(xué)發(fā)現(xiàn)了，這里僅僅講了連接遷移在客戶端上的實(shí)現(xiàn)和效果，畢竟連接遷移后，客戶端源IP發(fā)生了變化，云端接入層難道不需要做適配嗎？答案是需要的，sTGW作為公司云CLB和自研的主要七層網(wǎng)關(guān)接入，在QUIC連接遷移方面做了完整的解決方案，目前也已經(jīng)將能力開放出來，在QUIC集群上全量上線。sTGW對(duì)于連接遷移的解決方案可參見sTGW大規(guī)模運(yùn)營(yíng)QUIC之路。

八、弱網(wǎng)優(yōu)化之完全0-RTT握手與金融級(jí)前向安全

如下是GQUIC的握手流程，原生實(shí)現(xiàn)里，應(yīng)用發(fā)生冷啟動(dòng)時(shí)，首先會(huì)進(jìn)行1RTT握手，拿到服務(wù)端的證書和ServerConfig（簡(jiǎn)稱SCFG），隨后SCFG會(huì)被作為隨機(jī)數(shù)用于生成非前向安全的密鑰。

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

在原生實(shí)現(xiàn)中，SCFG會(huì)被臨時(shí)存儲(chǔ)在進(jìn)程內(nèi)存堆區(qū)，下次發(fā)起新連接或者熱啟動(dòng)時(shí)，直接就能進(jìn)入0-RTT流程，但冷啟動(dòng)則永遠(yuǎn)是1-RTT。

基于原生的實(shí)現(xiàn)情況，我們針對(duì)握手流程做了兩個(gè)方向的優(yōu)化。

實(shí)現(xiàn)100% 0-RTT成功率，用于在握手時(shí)延極其敏感的業(yè)務(wù)上，例如廣告請(qǐng)求、API調(diào)用、短連接下載等。

強(qiáng)制前向安全，針對(duì)安全敏感型業(yè)務(wù)，例如金融業(yè)務(wù)，0-RTT中發(fā)送的非前向安全數(shù)據(jù)包風(fēng)險(xiǎn)遠(yuǎn)高于前向安全數(shù)據(jù)包，因此對(duì)于金融型業(yè)務(wù)，可以強(qiáng)制1-RTT握手生產(chǎn)前向安全密鑰后，再發(fā)送數(shù)據(jù)包。

改進(jìn)后的兩種握手流程如下圖

九、弱網(wǎng)優(yōu)化之實(shí)時(shí)傳輸

實(shí)時(shí)傳輸是QUIC的一個(gè)拓展功能，目前在IETF草稿階段。實(shí)時(shí)傳輸適用于對(duì)數(shù)據(jù)可靠性要求不高，但非常注重?cái)?shù)據(jù)實(shí)時(shí)性的業(yè)務(wù)。例如音視頻傳輸、互動(dòng)游戲等。實(shí)時(shí)傳輸在QUIC中的定位，以及與可靠傳輸?shù)膮^(qū)別如下：

• 相同點(diǎn)

在QUIC連接建立、創(chuàng)建QUIC數(shù)據(jù)包、數(shù)據(jù)加解密這些基礎(chǔ)功能，不可靠數(shù)據(jù)與可靠數(shù)據(jù)都是共用的。

不可靠傳輸也有擁塞控制、ACK機(jī)制，與可靠傳輸一致。

• 不同點(diǎn)：

不可靠數(shù)據(jù)不受滑動(dòng)窗口限制，滑窗窗口滿只限制可靠數(shù)據(jù)傳輸。

發(fā)生丟包重傳時(shí)，只重傳可靠數(shù)據(jù)幀，不可靠數(shù)據(jù)幀不進(jìn)行重傳。

不可靠數(shù)據(jù)沒有quic stream概念，只是frame粒度

這其中，一個(gè)關(guān)鍵點(diǎn)在于數(shù)據(jù)是否重傳，IETF草稿的定義對(duì)這塊比較開放，可以完全不重傳，也可以選擇性重傳。

為此，TQUIC在實(shí)現(xiàn)實(shí)時(shí)傳輸時(shí)，做了靈活的改造，對(duì)于實(shí)時(shí)傳輸?shù)臄?shù)據(jù)，提供多種重傳策略供使用者選擇，可以完全不重傳，也可以選擇性重傳某個(gè)重要的數(shù)據(jù)（比如關(guān)鍵幀），我們也在嘗試做動(dòng)態(tài)重傳控制，依托我們的弱網(wǎng)判斷模型，動(dòng)態(tài)調(diào)整重傳策略。

十、總結(jié)

經(jīng)過騰訊sTGW團(tuán)隊(duì)持續(xù)投入。TQUIC在騰訊多個(gè)重要業(yè)務(wù)落地，覆蓋業(yè)務(wù)包括實(shí)時(shí)通信、音視頻、在線游戲、在線廣告等。在登錄成功率、登錄耗時(shí)、握手時(shí)延、下載速度等性能指標(biāo)上均取得了明顯收益。騰訊云客戶通過CLB使用HTTP3后，延遲降低了超過20個(gè)點(diǎn)，也歡迎大家接入使用。（點(diǎn)擊閱讀原文了解更多：CLB 支持 QUIC 協(xié)議）

附部分業(yè)務(wù)效果總結(jié)如下：

相關(guān)鏈接

---

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

最后

想學(xué)習(xí)網(wǎng)絡(luò)，進(jìn)階網(wǎng)絡(luò)也可以加入極客星球，一起高效學(xué)習(xí)！助你成為技術(shù)專家！

極客星球詳細(xì)了解:

醍醐灌頂！

- END -

---

求在看，分享，點(diǎn)贊

是對(duì)文章最大的贊賞，極客重生感謝你

推薦閱讀

實(shí)戰(zhàn)|QUIC協(xié)議在螞蟻集團(tuán)落地

QUIC 是如何解決TCP 性能瓶頸的？

Google的TCP BBR擁塞控制算法深度解析

談?wù)凲UIC協(xié)議原理|網(wǎng)絡(luò)硬核系列

求點(diǎn)贊，在看，分享三連

總結(jié)

以上是生活随笔為你收集整理的实战|QUIC协议助力腾讯业务提速30%的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。