QUIC會成為網際網路傳輸的顛覆者嗎？_LiveVideoStack

翻譯：Alex

技術審校：劉連響

本文來自Compira Labs，作者為Ravid Hadar。

▲掃描圖中二維碼瞭解音視訊技術大會更多資訊▲

影音探索 #012#

當電腦科學家注意到TCP的限制性使它無法繼續支援新的、更加先進的網際網路服務時，他們對QUIC的興趣便與日俱增。作為傳輸協議，QUIC是替代TCP的最重要“候選人”，它將有可能為網際網路資料傳輸開啟新的局面。

在昨天的文章中，我們討論了什麼是QUIC、它的目的以及工作原理。現在我們要回答一個稍許不同的問題：它真的值得采用嗎？接下來，本文將深入探索使用QUIC的優勢和劣勢。

QUIC的優勢

QUIC的支持者指出它可以使網際網路更高效、快速、安全且不斷髮展。

1∕可擴充套件性

更改TCP並不容易，因為其中的中介軟體抗拒更新，而且TCP 40位元組的可選位幾乎全部填滿（更多相關資訊，請閱讀QUIC和網際網路傳輸的未來）。

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

2∕使用者空間實現

QUIC能夠在應用層實現，與在作業系統核心中實現的TCP相比，它可以更快地進行更新。這進一步提高了QUIC的可擴充套件性，使得服務可以非常快速地演進，從而新的特性每天都能得到部署。同時它還能在上下文切換時通過呼叫較少的開銷而實現更高的響應能力。

3∕更快建立連線

Web瀏覽特別需要快速建立連線，因為使用者通常會開啟多個、短暫的連線。當使用HTTPS時，TCP在建立連線前，需要“三次握手”以及後續的TLS協議設定。

QUIC（基於UDP）不需要三次握手，加上它會在初次握手時交換安全金鑰，從而使它在建立加密連線時速度提升了一倍。

4∕降低對丟包的敏感度

使用TCP時，如果丟失一個數據包，接下來所有的資料包都會停止傳輸，直到丟失的那個資料包被髮送，這種現象被稱為“隊頭阻塞”，它會導致延遲明顯增加。

相比之下，QUIC使用的是類似HTTP/2的多路複用模式，可以同時支援多個數據流。如果一個數據流傳送錯誤，導致丟包，那麼其他資料流會繼續傳送資料包，而不會阻塞傳輸。

下圖的示例中顯示了包含三個資料包的擁塞視窗的連線，其中0號資料包被丟棄。在只有單一資料流的TCP連線中，後續的資料包被阻止。QUIC的多路連線擁有三個資料流，每個都能獨立操作。因此，2號和3號資料流仍然在正常傳輸，只有1號資料流中後續的資料包被阻止。

5∕切換網路時的效能提升

切換網路時，QUIC可以實現平穩過渡。比如，如果你使用家裡的wifi觀看手機上的視訊，然後你走出家門，家裡的wifi便切換到LTE，或者當你一直忙於觀看視訊，在不同的移動基站間移動時。

在以上這些場景中，TCP將切斷連線，並通過新的網路建立新的連線，進而影響到你的觀看體驗。而QUIC則能夠實現無縫連線。

6∕提升的安全性和隱私保護

QUIC在傳輸層中內建了加密功能，從而驗證整個負載（包括header）。TCP在header中不包含加密，使它非常容易受到攻擊。QUIC預設支援安全的TLS，意味著端到端完全安全。

QUIC的侷限性

TCP發明時，網路都是有線連線，而且相當可靠。但顯然，情況已經發生改變。QUIC對非可靠、無法預測的無線連線進行了改進，但並沒有改變網際網路傳輸的本質，它的侷限性導致它只能改變某些特定使用場景。下面列舉了一些額外的QUIC侷限性：

1∕遷移app面臨巨大挑戰

將app從HTTP/2遷移到HTTP/3（或者從TCP遷移到UDP）要費很大力氣。整個過程需要將整個應用層實現和傳輸層實現轉移到UDP，並在服務端和客戶端構建全新的解決方案。

這對於流媒體領域中資源相對有限的小廠商而言無疑挑戰重重，同時也解釋了谷歌和微軟這樣的科技巨頭可以率先採用QUIC協議的原因。

2∕採用受限

QUIC的最大問題就是它的採用依然受限。幾乎每個瀏覽器都接受使用QUIC進行簡單的網頁瀏覽，但是除了chromium，沒有瀏覽器將它設定為預設選項。

除此之外，在流媒體領域，除了谷歌和Facebook（現更名為Meta）之外，少有公司使用QUIC。只有少數CDN提供商支援QUIC，而其中的一些也只是驗證了QUIC的實現，並沒有為大規模部署準備好。這就帶來了問題：如果你推出了使用multi-CDN並基於QUIC的新服務，那麼將只有20%的訪問使用QUIC，因為你無法向用戶證明它對使用者體驗的顯著影響。

3∕QUIC包含TCP回退

QUIC之所以被構建在UDP之上，部分原因是極少有中介軟體和網路裝置攔截UDP。但確實存在被攔截的風險，所以基於QUIC的app必須設計成能夠回退到TCP，以防萬一。

這意味著app（基於QUIC）的開發者要同時開發和維護兩個不同的版本（由於TCP回退和受到限制的採用率），導致他們的負擔很重。

好訊息是，隨著最新的DEVOPS結構與HTTP的Alt-Svc標籤的使用，支援兩種協議要比以前簡單得多。

4∕無法檢查資料包

網路防火牆無法解密QUIC流量來檢查資料包，所以潛在的惡意流量非常有可能沒有被標準安全功能檢測出來而進入網路。因此，思科和Palo Alto Networks等安全廠商通常會在埠80（Web伺服器）和443（TSL）攔截QUIC資料包（認為它們包含惡意軟體），迫使客戶端回退使用HTTP/2和TCP協議。

但上述操作並不會顯著影響內容使用者體驗，因為正確實現的流媒體服務會預設回退到TCP+TLS，但這種操作可能會阻止率先部署QUIC的想法。只有解決這一挑戰，QUIC才能被各大企業廣泛接受。

5∕不具備某些TCP特性

人們理所當然地使用TCP中所預設包含的一些特性（比如Throttling）。但使用QUIC，你可能需要自己構建這些特性。

除此之外，HTTP/3缺乏一些採用某些特定協議時所需的特性。比如，HTTP/3仍然不支援成塊傳輸（chunked transfer，即將視訊切片分割為小塊的能力），但HTTP1.1卻支援該特性。這就限制了用於基於QUIC的視訊傳輸的協議數量。

因此，儘管QUIC支援大部分常見傳輸協議（如HLS、MPEG-DASH），但目前它無法支援更多新的協議，這些協議主要用於降低glass-to-glass延遲，比如依賴於成塊傳輸的LL CMAF（Low Latency Common Media Format）。

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

6∕更容易被fingerprinting

惡意行為者很可能嗅探到網際網路使用者與所訪問網站之間的網路流量，並通過被發現的資料包建立與特定網站相對應的不同模式，這種操作被稱為web fingerprinting。在早期流量連線階段，TCP+HTTPS似乎更能抵禦fingerprinting。

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

一些觀點認為QUIC所需的HTTP/3在客戶端和服務端都佔用了更多的CPU資源。然而，谷歌卻持相反觀點，認為QUIC有助於延長電池壽命。

無論如何，一旦QUIC進入主流技術棧，這一問題預計不會有太大影響。

8∕需要實現的協議眾多

由於IETF歷經5年多才釋出第一版QUIC，所以目前市面上有60種QUIC版本實現，都開發於QUIC標準之前。因此，大部分QUIC版本或不支援完整的QUIC標準，或只支援自己版本的實現。只有當不同版本的QUIC與官方標準保持一致時，它才能被廣泛採用。

9∕網際網路依然針對TCP進行優化

TCP傳輸已經存在幾十年，多年以來，TCP應用通過在軟體（如作業系統核心）和硬體（如網路介面和智慧NIC）中構建解除安裝效能而徹底得到了優化。而QUIC卻不具備這一能力。它基於UDP，位於使用者空間內，所以它的端點，以及一些中介軟體功能在現階段存在明顯的劣勢。不過，一旦QUIC被廣泛採用，就會得到這種優化，所以這對於QUIC而言只是暫時性問題。

QUIC vs TCP：對於質量體驗的影響

QUIC支援某些獨特的特性並在新的特性實現方面提供了更多靈活性。因此，對比TCP，基於QUIC的應用有望在QoE方面帶來更多優勢。

下面是兩個QUIC帶來QoE優勢的常見用例：

Web瀏覽： QUIC支援內建TLS，並能夠迅速建立連線。在大部分連線時長較短的情況下（如安全網站的快速下載時長），它可以提供明顯的效能優勢。谷歌聲稱執行在QUIC上的應用頁面下載時長縮短了10%。
視訊流： QUIC支援的某些特性有望提升視訊流的QoE。目前為止，因為QUIC的實現邏輯與TCP相似，所以可預測的影響已受到限制。但在一些情況中，還是可以體驗到QUIC所帶來的好處，比如，QUIC減少隊頭阻塞的能力為具有中高丟包率的網路所帶來的QoE優勢。