深入探索使用QUIC的優(yōu)勢(shì)和劣勢(shì)

當(dāng)計(jì)算機(jī)科學(xué)家注意到TCP的限制性使它無(wú)法繼續(xù)支持新的、更加先進(jìn)的互聯(lián)網(wǎng)服務(wù)時(shí)，他們對(duì)QUIC的興趣便與日俱增。作為傳輸協(xié)議，QUIC是替代TCP的最重要“候選人”，它將有可能為互聯(lián)網(wǎng)數(shù)據(jù)傳輸打開新的局面。

在昨天的文章中，我們討論了什么是QUIC、它的目的以及工作原理?，F(xiàn)在我們要回答一個(gè)稍許不同的問題：它真的值得采用嗎？接下來(lái)，本文將深入探索使用QUIC的優(yōu)勢(shì)和劣勢(shì)。

QUIC的優(yōu)勢(shì)

QUIC的支持者指出它可以使互聯(lián)網(wǎng)更高效、快速、安全且不斷發(fā)展。

1∕可擴(kuò)展性

更改TCP并不容易，因?yàn)槠渲械闹虚g件抗拒更新，而且TCP 40字節(jié)的可選位幾乎全部填滿。

TCP沒有任何版本協(xié)商（version negotiation）擴(kuò)展位，相比之下，QUIC有32位，所以它有很多空間部署新版本，廠商也可以利用這些空間定義自己的專屬版本。

2∕用戶空間實(shí)現(xiàn)

QUIC能夠在應(yīng)用層實(shí)現(xiàn)，與在操作系統(tǒng)內(nèi)核中實(shí)現(xiàn)的TCP相比，它可以更快地進(jìn)行更新。這進(jìn)一步提高了QUIC的可擴(kuò)展性，使得服務(wù)可以非?？焖俚匮葸M(jìn)，從而新的特性每天都能得到部署。同時(shí)它還能在上下文切換時(shí)通過調(diào)用較少的開銷而實(shí)現(xiàn)更高的響應(yīng)能力。

3∕更快建立連接

Web瀏覽特別需要快速建立連接，因?yàn)橛脩敉ǔ?huì)開啟多個(gè)、短暫的連接。當(dāng)使用HTTPS時(shí)，TCP在建立連接前，需要“三次握手”以及后續(xù)的TLS協(xié)議設(shè)置。

QUIC（基于UDP）不需要三次握手，加上它會(huì)在初次握手時(shí)交換安全密鑰，從而使它在建立加密連接時(shí)速度提升了一倍。

4∕降低對(duì)丟包的敏感度

使用TCP時(shí)，如果丟失一個(gè)數(shù)據(jù)包，接下來(lái)所有的數(shù)據(jù)包都會(huì)停止傳輸，直到丟失的那個(gè)數(shù)據(jù)包被發(fā)送，這種現(xiàn)象被稱為“隊(duì)頭阻塞”，它會(huì)導(dǎo)致延遲明顯增加。

相比之下，QUIC使用的是類似HTTP/2的多路復(fù)用模式，可以同時(shí)支持多個(gè)數(shù)據(jù)流。如果一個(gè)數(shù)據(jù)流發(fā)送錯(cuò)誤，導(dǎo)致丟包，那么其他數(shù)據(jù)流會(huì)繼續(xù)發(fā)送數(shù)據(jù)包，而不會(huì)阻塞傳輸。

下圖的示例中顯示了包含三個(gè)數(shù)據(jù)包的擁塞窗口的連接，其中0號(hào)數(shù)據(jù)包被丟棄。在只有單一數(shù)據(jù)流的TCP連接中，后續(xù)的數(shù)據(jù)包被阻止。QUIC的多路連接擁有三個(gè)數(shù)據(jù)流，每個(gè)都能獨(dú)立操作。因此，2號(hào)和3號(hào)數(shù)據(jù)流仍然在正常傳輸，只有1號(hào)數(shù)據(jù)流中后續(xù)的數(shù)據(jù)包被阻止。

5∕切換網(wǎng)絡(luò)時(shí)的性能提升

切換網(wǎng)絡(luò)時(shí)，QUIC可以實(shí)現(xiàn)平穩(wěn)過渡。比如，如果你使用家里的wifi觀看手機(jī)上的視頻，然后你走出家門，家里的wifi便切換到LTE，或者當(dāng)你一直忙于觀看視頻，在不同的移動(dòng)基站間移動(dòng)時(shí)。

在以上這些場(chǎng)景中，TCP將切斷連接，并通過新的網(wǎng)絡(luò)創(chuàng)建新的連接，進(jìn)而影響到你的觀看體驗(yàn)。而QUIC則能夠?qū)崿F(xiàn)無(wú)縫連接。

6∕提升的安全性和隱私保護(hù)

QUIC在傳輸層中內(nèi)置了加密功能，從而驗(yàn)證整個(gè)負(fù)載（包括header）。TCP在header中不包含加密，使它非常容易受到攻擊。QUIC默認(rèn)支持安全的TLS，意味著端到端完全安全。

QUIC的局限性

TCP發(fā)明時(shí)，網(wǎng)絡(luò)都是有線連接，而且相當(dāng)可靠。但顯然，情況已經(jīng)發(fā)生改變。QUIC對(duì)非可靠、無(wú)法預(yù)測(cè)的無(wú)線連接進(jìn)行了改進(jìn)，但并沒有改變互聯(lián)網(wǎng)傳輸?shù)谋举|(zhì)，它的局限性導(dǎo)致它只能改變某些特定使用場(chǎng)景。下面列舉了一些額外的QUIC局限性：

1∕遷移app面臨巨大挑戰(zhàn)

將app從HTTP/2遷移到HTTP/3（或者從TCP遷移到UDP）要費(fèi)很大力氣。整個(gè)過程需要將整個(gè)應(yīng)用層實(shí)現(xiàn)和傳輸層實(shí)現(xiàn)轉(zhuǎn)移到UDP，并在服務(wù)端和客戶端構(gòu)建全新的解決方案。

這對(duì)于流媒體領(lǐng)域中資源相對(duì)有限的小廠商而言無(wú)疑挑戰(zhàn)重重，同時(shí)也解釋了谷歌和微軟這樣的科技巨頭可以率先采用QUIC協(xié)議的原因。

2∕采用受限

QUIC的最大問題就是它的采用依然受限。幾乎每個(gè)瀏覽器都接受使用QUIC進(jìn)行簡(jiǎn)單的網(wǎng)頁(yè)瀏覽，但是除了chromium，沒有瀏覽器將它設(shè)置為默認(rèn)選項(xiàng)。

除此之外，在流媒體領(lǐng)域，除了谷歌和Facebook（現(xiàn)更名為Meta）之外，少有公司使用QUIC。只有少數(shù)CDN提供商支持QUIC，而其中的一些也只是驗(yàn)證了QUIC的實(shí)現(xiàn)，并沒有為大規(guī)模部署準(zhǔn)備好。這就帶來(lái)了問題：如果你推出了使用multi-CDN并基于QUIC的新服務(wù)，那么將只有20%的訪問使用QUIC，因?yàn)槟銦o(wú)法向用戶證明它對(duì)用戶體驗(yàn)的顯著影響。

3∕QUIC包含TCP回退

QUIC之所以被構(gòu)建在UDP之上，部分原因是極少有中間件和網(wǎng)絡(luò)設(shè)備攔截UDP。但確實(shí)存在被攔截的風(fēng)險(xiǎn)，所以基于QUIC的app必須設(shè)計(jì)成能夠回退到TCP，以防萬(wàn)一。

這意味著app（基于QUIC）的開發(fā)者要同時(shí)開發(fā)和維護(hù)兩個(gè)不同的版本（由于TCP回退和受到限制的采用率），導(dǎo)致他們的負(fù)擔(dān)很重。

好消息是，隨著最新的DEVOPS結(jié)構(gòu)與HTTP的Alt-Svc標(biāo)簽的使用，支持兩種協(xié)議要比以前簡(jiǎn)單得多。

4∕無(wú)法檢查數(shù)據(jù)包

網(wǎng)絡(luò)防火墻無(wú)法解密QUIC流量來(lái)檢查數(shù)據(jù)包，所以潛在的惡意流量非常有可能沒有被標(biāo)準(zhǔn)安全功能檢測(cè)出來(lái)而進(jìn)入網(wǎng)絡(luò)。因此，思科和Palo Alto Networks等安全廠商通常會(huì)在端口80（Web服務(wù)器）和443（TSL）攔截QUIC數(shù)據(jù)包（認(rèn)為它們包含惡意軟件），迫使客戶端回退使用HTTP/2和TCP協(xié)議。

但上述操作并不會(huì)顯著影響內(nèi)容用戶體驗(yàn)，因?yàn)檎_實(shí)現(xiàn)的流媒體服務(wù)會(huì)默認(rèn)回退到TCP+TLS，但這種操作可能會(huì)阻止率先部署QUIC的想法。只有解決這一挑戰(zhàn)，QUIC才能被各大企業(yè)廣泛接受。

5∕不具備某些TCP特性

人們理所當(dāng)然地使用TCP中所默認(rèn)包含的一些特性（比如Throttling）。但使用QUIC，你可能需要自己構(gòu)建這些特性。

除此之外，HTTP/3缺乏一些采用某些特定協(xié)議時(shí)所需的特性。比如，HTTP/3仍然不支持成塊傳輸（chunked transfer，即將視頻切片分割為小塊的能力），但HTTP1.1卻支持該特性。這就限制了用于基于QUIC的視頻傳輸?shù)膮f(xié)議數(shù)量。

因此，盡管QUIC支持大部分常見傳輸協(xié)議（如HLS、MPEG-DASH），但目前它無(wú)法支持更多新的協(xié)議，這些協(xié)議主要用于降低glass-to-glass延遲，比如依賴于成塊傳輸?shù)腖L CMAF（Low Latency Common Media Format）。

glass-to-glass延遲：指顯示器屏幕和相機(jī)鏡片之間的延遲，也可以叫做“端到端延遲”，意思是開始（ 捕獲）并結(jié)束（顯示）之間整個(gè)傳輸管道上的延遲[1]。

6∕更容易被fingerprinting

惡意行為者很可能嗅探到互聯(lián)網(wǎng)用戶與所訪問網(wǎng)站之間的網(wǎng)絡(luò)流量，并通過被發(fā)現(xiàn)的數(shù)據(jù)包創(chuàng)建與特定網(wǎng)站相對(duì)應(yīng)的不同模式，這種操作被稱為web fingerprinting。在早期流量連接階段，TCP+HTTPS似乎更能抵御fingerprinting。

7∕QUIC可能需要更高的CPU使用率

一些觀點(diǎn)認(rèn)為QUIC所需的HTTP/3在客戶端和服務(wù)端都占用了更多的CPU資源。然而，谷歌卻持相反觀點(diǎn)，認(rèn)為QUIC有助于延長(zhǎng)電池壽命。

無(wú)論如何，一旦QUIC進(jìn)入主流技術(shù)棧，這一問題預(yù)計(jì)不會(huì)有太大影響。

8∕需要實(shí)現(xiàn)的協(xié)議眾多

由于IETF歷經(jīng)5年多才發(fā)布第一版QUIC，所以目前市面上有60種QUIC版本實(shí)現(xiàn)，都開發(fā)于QUIC標(biāo)準(zhǔn)之前。因此，大部分QUIC版本或不支持完整的QUIC標(biāo)準(zhǔn)，或只支持自己版本的實(shí)現(xiàn)。只有當(dāng)不同版本的QUIC與官方標(biāo)準(zhǔn)保持一致時(shí)，它才能被廣泛采用。

9∕互聯(lián)網(wǎng)依然針對(duì)TCP進(jìn)行優(yōu)化

TCP傳輸已經(jīng)存在幾十年，多年以來(lái)，TCP應(yīng)用通過在軟件（如操作系統(tǒng)內(nèi)核）和硬件（如網(wǎng)絡(luò)接口和智能NIC）中構(gòu)建卸載性能而徹底得到了優(yōu)化。而QUIC卻不具備這一能力。它基于UDP，位于用戶空間內(nèi)，所以它的端點(diǎn)，以及一些中間件功能在現(xiàn)階段存在明顯的劣勢(shì)。不過，一旦QUIC被廣泛采用，就會(huì)得到這種優(yōu)化，所以這對(duì)于QUIC而言只是暫時(shí)性問題。

QUIC vs TCP：對(duì)于質(zhì)量體驗(yàn)的影響

QUIC支持某些獨(dú)特的特性并在新的特性實(shí)現(xiàn)方面提供了更多靈活性。因此，對(duì)比TCP，基于QUIC的應(yīng)用有望在QoE方面帶來(lái)更多優(yōu)勢(shì)。

下面是兩個(gè)QUIC帶來(lái)QoE優(yōu)勢(shì)的常見用例：

Web瀏覽：QUIC支持內(nèi)置TLS，并能夠迅速建立連接。在大部分連接時(shí)長(zhǎng)較短的情況下（如安全網(wǎng)站的快速下載時(shí)長(zhǎng)），它可以提供明顯的性能優(yōu)勢(shì)。谷歌聲稱運(yùn)行在QUIC上的應(yīng)用頁(yè)面下載時(shí)長(zhǎng)縮短了10%。

視頻流：QUIC支持的某些特性有望提升視頻流的QoE。目前為止，因?yàn)镼UIC的實(shí)現(xiàn)邏輯與TCP相似，所以可預(yù)測(cè)的影響已受到限制。但在一些情況中，還是可以體驗(yàn)到QUIC所帶來(lái)的好處，比如，QUIC減少隊(duì)頭阻塞的能力為具有中高丟包率的網(wǎng)絡(luò)所帶來(lái)的QoE優(yōu)勢(shì)。

QUIC也許是“改進(jìn)者”，不是“顛覆者”

QUIC確實(shí)為互聯(lián)網(wǎng)用戶帶來(lái)了漸進(jìn)式的增益，但對(duì)于它是否是真正的“顛覆者”這一觀點(diǎn)還存在爭(zhēng)議。目前存在充分的理由采用QUIC，但QUIC所帶來(lái)的問題以及早期采用者所遇到的挑戰(zhàn)都在“鼓勵(lì)”一種觀望態(tài)度。

審核編輯 ：李倩