QUIC(Quick UDP Internet Connection)是Google提出的一個(gè)基于UDP的傳輸協(xié)議，因其高效的傳輸效率和多路并發(fā)的能力，已經(jīng)成為下一代互聯(lián)網(wǎng)協(xié)議HTTP/3的底層傳輸協(xié)議。除了應(yīng)用于Web領(lǐng)域，它的優(yōu)勢(shì)同樣適用于一些通用的需要低延遲、高吞吐特性的傳輸場(chǎng)景。本文從QUIC的由來(lái)和優(yōu)勢(shì)出發(fā)，分享實(shí)際項(xiàng)目中需要考慮的問(wèn)題和解決思路，通過(guò)測(cè)試對(duì)比QUIC和TCP的實(shí)際傳輸能力，希望有助于大家理解和實(shí)踐QUIC協(xié)議。
PART 01
為什么需要QUIC？
眾所周知，HTTP從最初的HTTP/0.9，經(jīng)歷了HTTP/1.x，HTTP/2到最新的HTTP/3這幾個(gè)大的更新版本。在HTTP/3版本之前，HTTP底層都是用TCP傳輸數(shù)據(jù)，而伴隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡(luò)交互場(chǎng)景越來(lái)越豐富并要求及時(shí)性，傳統(tǒng)TCP固有的性能瓶頸越來(lái)越不能滿(mǎn)足需求，原因有以下幾點(diǎn)：
建立連接的握手延遲大
HTTPS包含兩個(gè)握手：1）TCP三次握手，1個(gè)RTT；2）TLS握手，2個(gè)RTT。完整握手總共需要3個(gè)RTT，對(duì)于直播等需要首幀秒開(kāi)場(chǎng)景，握手延遲太大。
多路復(fù)用的隊(duì)首阻塞
以HTTP/2多路復(fù)用為例，多個(gè)數(shù)據(jù)請(qǐng)求作為不同的流，共用一條TCP連接發(fā)送，所有的流應(yīng)用層都必須按序處理。若某個(gè)流的數(shù)據(jù)丟失，后面其他流的數(shù)據(jù)都會(huì)被阻塞，直到丟失的流數(shù)據(jù)重傳完成其他流才能被繼續(xù)傳輸。即使接收端已經(jīng)收到之后流的數(shù)據(jù)包，HTTP協(xié)議也不會(huì)通知應(yīng)用層去處理。
TCP協(xié)議的更新滯后
TCP協(xié)議是實(shí)現(xiàn)在操作系統(tǒng)內(nèi)核內(nèi)，但是用戶(hù)端的操作系統(tǒng)版本升級(jí)非常困難，很多老舊的系統(tǒng)像WindowsXP還有大量用戶(hù)使用，因此TCP協(xié)議的一些更新很難被快速推廣。
正是考慮到以上的這些問(wèn)題，QUIC在應(yīng)用層之上基于UDP實(shí)現(xiàn)丟包恢復(fù)，擁塞控制，加解密，多路復(fù)用等功能，既能優(yōu)化握手延遲，同時(shí)又完全解決內(nèi)核協(xié)議更新滯后問(wèn)題。
PART 02
QUIC的優(yōu)勢(shì)
這里列舉下QUIC的主要優(yōu)勢(shì)。
握手建連更快
QUIC建連時(shí)間大約0~1 RTT，在兩方面做了優(yōu)化：
1）傳輸層使用了UDP，減少了1個(gè)RTT三次握手的延遲。
2）加密協(xié)議采用了TLS 協(xié)議的最新版本TLS 1.3，相對(duì)之前的TLS 1.1-1.2，TLS1.3允許客戶(hù)端無(wú)需等待TLS握手完成就開(kāi)始發(fā)送應(yīng)用程序數(shù)據(jù)的操作，可以支持1 RTT和0RTT。
對(duì)于QUIC協(xié)議，客戶(hù)端第一次建連的握手協(xié)商需1-RTT，而已建連的客戶(hù)端重新建連可以使用之前協(xié)商好的緩存信息來(lái)恢復(fù)TLS連接，僅需0-RTT時(shí)間。因此QUIC建連時(shí)間大部分0-RTT、極少部分1-RTT，相比HTTPS的3-RTT的建連，具有極大的優(yōu)勢(shì)。
避免隊(duì)首阻塞的多路復(fù)用
QUIC同樣支持多路復(fù)用，相比HTTP/2，QUIC的流與流之間完全隔離的，互相沒(méi)有時(shí)序依賴(lài)。如果某個(gè)流出現(xiàn)丟包，不會(huì)阻塞其他流數(shù)據(jù)的傳輸和應(yīng)用層處理，所以這個(gè)方案并不會(huì)造成隊(duì)首阻塞。
支持連接遷移
什么是連接遷移？舉個(gè)例子，當(dāng)你用手機(jī)使用蜂窩網(wǎng)絡(luò)參加遠(yuǎn)程會(huì)議，當(dāng)你把網(wǎng)絡(luò)切換到WLAN時(shí)，會(huì)議客戶(hù)端會(huì)立馬重連，視頻同時(shí)出現(xiàn)一瞬間的卡頓。這是因?yàn)椋琓CP采用四元組（包括源IP、源端口、目標(biāo)地址、目標(biāo)端口）標(biāo)識(shí)一個(gè)連接，在網(wǎng)絡(luò)切換時(shí)，客戶(hù)端的IP發(fā)生變化，TCP連接被瞬間切斷然后重連。連接遷移就是當(dāng)四元組中任一值發(fā)生變化時(shí)，連接依舊能保持，不中斷業(yè)務(wù)。QUIC支持連接遷移，它用一個(gè)（一般是64位隨機(jī)數(shù)）ConnectionID標(biāo)識(shí)連接，這樣即使源的IP或端口發(fā)生變化，只要ConnectionID一致，連接都可以保持，不會(huì)發(fā)生切斷重連。
可插拔的擁塞控制
QUIC是應(yīng)用層協(xié)議，用戶(hù)可以插拔式選擇像Cubic、BBR、Reno等擁塞控制算法，也可以根據(jù)具體的場(chǎng)景定制私有算法。
前向糾錯(cuò)（FEC）
QUIC支持前向糾錯(cuò)，弱網(wǎng)丟包環(huán)境下，動(dòng)態(tài)的增加一些FEC數(shù)據(jù)包，可以減少重傳次數(shù)，提升傳輸效率。
PART 03
基于QUIC的服務(wù)架構(gòu)
實(shí)際項(xiàng)目在應(yīng)用QUIC之前，首先要對(duì)整體服務(wù)架構(gòu)做一些宏觀上的思考，對(duì)下面的問(wèn)題進(jìn)行一定的思考后，再去考慮項(xiàng)目本身的細(xì)節(jié)，可以規(guī)避一些技術(shù)彎路。
哪些鏈路需要提升傳輸效率？
TCP的性能瓶頸主要體現(xiàn)在具有數(shù)據(jù)丟包的網(wǎng)絡(luò)，由于TCP的AIMD（加性增、乘性減）的擁塞避免策略，網(wǎng)絡(luò)上出現(xiàn)少量丟包，TCP擁塞控制算法會(huì)指數(shù)級(jí)降低傳輸速率，導(dǎo)致其無(wú)法有效利用帶寬。對(duì)于一些比較理想的網(wǎng)絡(luò)，比如局域網(wǎng)內(nèi)，TCP與QUIC的傳輸能力相當(dāng)，傳輸速率受限于實(shí)際帶寬，引入QUIC反而增加了復(fù)雜度。
如何兼容老的客戶(hù)端？
新的架構(gòu)不能影響老的客戶(hù)端，因此需要同時(shí)支持TCP和QUIC。
如何實(shí)現(xiàn)連接遷移？
用戶(hù)在4G和WIFI之間切換，如何實(shí)現(xiàn)連接遷移，保證業(yè)務(wù)層不中斷？
QUIC是否會(huì)帶來(lái)一些弊端，如何解決？
新事物產(chǎn)生往往會(huì)伴隨新的問(wèn)題，QUIC實(shí)現(xiàn)在內(nèi)核之上的應(yīng)用層，用UDP替代TCP傳輸，也帶來(lái)了一些問(wèn)題：
（1）國(guó)內(nèi)運(yùn)營(yíng)商針對(duì)UDP做QOS限速和丟包，一些企業(yè)的局域網(wǎng)防火墻有時(shí)候會(huì)禁用 UDP 協(xié)議，導(dǎo)致網(wǎng)絡(luò)UDP傳輸?shù)托Р豢捎谩?/span>
（2）QUIC的協(xié)議棧運(yùn)行在用戶(hù)態(tài)，同時(shí)因?yàn)閰f(xié)議的復(fù)雜度，對(duì)CPU的消耗會(huì)比TCP高不少，實(shí)際實(shí)現(xiàn)時(shí)如何盡可能的減少Q(mào)UIC對(duì)服務(wù)器性能的影響？
（3）UDP的報(bào)文長(zhǎng)度受限于MTU，對(duì)于大塊數(shù)據(jù)，QUIC在應(yīng)用層切成大量的小包，收發(fā)會(huì)造成大量的系統(tǒng)調(diào)用sendmsg/recvmsg，因此QUIC的網(wǎng)絡(luò)吞吐相比TCP有很大劣勢(shì)。Linux系統(tǒng)提供了多種優(yōu)化手段：1）支持批量發(fā)送函數(shù)sendmmsg，多個(gè)UDP報(bào)文，通過(guò)一次系統(tǒng)調(diào)用完成發(fā)送；2)開(kāi)啟內(nèi)核GRO/GSO，在網(wǎng)卡驅(qū)動(dòng)完成拆包和組包；3）網(wǎng)卡支持硬件UDP GSO offload。
考慮到以上問(wèn)題之后，一般QUIC服務(wù)可以類(lèi)似按照下圖的架構(gòu)設(shè)計(jì)。
加速鏈路
對(duì)以下兩段鏈路使用QUIC加速：
1）最后一公里：因受wifi設(shè)備性能、蜂窩網(wǎng)絡(luò)信號(hào)覆蓋范圍強(qiáng)弱等因素影響，用戶(hù)終端的最后一公里網(wǎng)絡(luò)能力參差不齊，是比較容易出現(xiàn)弱網(wǎng)的一段鏈路。
2）數(shù)據(jù)中心間級(jí)聯(lián)：數(shù)據(jù)中心之間的數(shù)據(jù)一般會(huì)走骨干網(wǎng)，但在一些流量高峰時(shí)段，可能會(huì)出現(xiàn)網(wǎng)絡(luò)擁塞，比較容易出現(xiàn)數(shù)據(jù)丟包，延時(shí)加劇。
雙鏈路備份
客戶(hù)端一般會(huì)同時(shí)支持TCP和QUIC兩種傳輸通道，互為備份，根據(jù)兩條鏈路的實(shí)際狀況（RTT、丟包等）智能選擇最優(yōu)傳輸通道。
連接遷移的實(shí)現(xiàn)
如前文所述，QUIC socket采用UDP收發(fā)數(shù)據(jù)，一個(gè)連接用一個(gè)ConnectionID唯一標(biāo)識(shí)，無(wú)論用戶(hù)在蜂窩網(wǎng)絡(luò)與WLAN之間如何切換，只要數(shù)據(jù)包中的ConnectionID不變，服務(wù)端可以將不同的四元組關(guān)聯(lián)到同一個(gè)連接上下文，從而避免出現(xiàn)斷網(wǎng)重連。但是實(shí)現(xiàn)無(wú)縫的連接遷移困難并不小，為了實(shí)現(xiàn)高并發(fā)，服務(wù)端一般都會(huì)采用多線程，多進(jìn)程的架構(gòu)，負(fù)載均衡根據(jù)四元組將連接ConnectionID關(guān)聯(lián)到特定的運(yùn)行環(huán)境（線程或進(jìn)程），連接遷移大概率會(huì)導(dǎo)致緩存的連接上下文失效。以下圖多線程的設(shè)計(jì)舉例，設(shè)想CID1連接遷移發(fā)生時(shí)，用戶(hù)源IP和端口由A變成C，socket綁定的線程由1遷移到2，因線程2查找不到CID1連接的上下文，導(dǎo)致連接遷移失敗。
上圖只是多線程的架構(gòu)，我們可以想辦法把新的socket重新bind回線程1。如果是多進(jìn)程架構(gòu)，負(fù)載均衡會(huì)尋址到不同的服務(wù)器上，如何將連接重新尋址到原始服務(wù)器？
業(yè)內(nèi)一般的解決思路借鑒了雪花算法，在建連完成就給Server的destination ConnectionId打上初始服務(wù)器的地址標(biāo)記，根據(jù)這些標(biāo)記信息（集群ID+機(jī)器ID+線程ID），讓新的服務(wù)器尋址到初始的服務(wù)器，后續(xù)數(shù)據(jù)再透明轉(zhuǎn)發(fā)給初始服務(wù)器，整個(gè)過(guò)程僅增加了一次轉(zhuǎn)發(fā)動(dòng)作，對(duì)用戶(hù)沒(méi)有任何感知。
PART 04
傳輸時(shí)延測(cè)試
建連時(shí)延
上圖可以看到建連有將近50%的提升，QUIC節(jié)省了2-RTT時(shí)間，對(duì)于一些RTT高網(wǎng)絡(luò)，效果更顯著。
丟包時(shí)延
為了對(duì)比TCP和QUIC在丟包網(wǎng)絡(luò)下的表現(xiàn)，分別對(duì)5%、15%、30%的丟包率場(chǎng)景做了對(duì)比測(cè)試。每一種場(chǎng)景，進(jìn)行1000次測(cè)試，每次測(cè)試發(fā)送10KB數(shù)據(jù)，統(tǒng)計(jì)最終落在指定時(shí)延以下的概率。最終的結(jié)果參考下圖，橫坐標(biāo)表示時(shí)延，縱坐標(biāo)用百分比表示指定時(shí)延下的樣本數(shù)量，曲線收斂速度越快，落在較低時(shí)延范圍的樣本數(shù)量越多，所以時(shí)延表現(xiàn)越好。
5%丟包下，200ms內(nèi)傳輸完成的測(cè)試樣本，QUIC占95%，TCP占78%，QUIC比TCP提升了17%左右。
15%丟包下，200ms內(nèi)傳輸完成的測(cè)試樣本，QUIC占90%，TCP占50%，QUIC比TCP提升了90%左右。
30%丟包下，200ms內(nèi)傳輸完成的測(cè)試樣本，QUIC占62%，TCP占22%，QUIC比TCP提升了300%左右。
總結(jié)起來(lái)，QUIC相比TCP的弱網(wǎng)丟包下的延時(shí)提升比較比較明顯，丟包率越高，提升越明顯。
PART 05
總結(jié)
本文對(duì)QUIC實(shí)踐中遇到的主要問(wèn)題和相應(yīng)解決思路做了一些分享，實(shí)際項(xiàng)目應(yīng)用時(shí)，由于需求的多樣性、現(xiàn)有服務(wù)架構(gòu)的差異，需要因地制宜，將QUIC的一些好的特性以比較優(yōu)雅地姿勢(shì)應(yīng)用。
關(guān)注拍樂(lè)云Pano，了解更多音視頻相關(guān)技術(shù)、產(chǎn)品實(shí)踐！
聯(lián)系客服
