聊聊QUIC協議的發展

點擊上方“LiveVideoStack”關注我們

作者 | 王盛

策劃 | 包研、Alex

編輯 | Alex

QUIC

年終盤點

#001#

QUIC ( Quick UDP Internet Connections，快速UDP互聯網連接)是一種新的“更快”的通用網絡傳輸協議。相比於TCP和TLS，QUIC提供了許多改進來提升網絡傳輸的性能。隨着QUIC協議的標準化，QUIC之上的HTTP/3協議已經被衆多瀏覽器所支持，其中包括Chrome、Microsoft Edge(Chrome內核版本)、Firefox和Safari，除了瀏覽器，也有不少客戶端App也開始支持和使用HTTP/3。本篇文章就和大家一起聊聊QUIC協議的發展歷程，和我認爲的QUIC未來發展趨勢。

 QUIC協議的發展

事實上，我們現在談論的QUIC協議有兩個協議同名：“Google QUIC”（簡稱gQUIC）和“IETF QUIC”（簡稱iQUIC）。gQUIC是由Google工程師們在2012年設計的原始協議，2013年Google公開了QUIC協議，同年也將此協議提交給IETF。這與SPDY和HTTP/2協議的發展歷程如出一轍，先由Google公司設計和試驗，在性能有提高的情況下提交給IETF工作組進行標準化。

2015年6月，一份QUIC的Internet Draft提交到IETF組織進行標準化，同年IETF的QUIC工作組也因此成立 [1] 。

2018年10月，IETF的HTTP工作組和QUIC工作組聯合聲明了HTTP/3，也就是QUIC之上運行的HTTP協議，但此時HTTP/3的具體標準尚未定稿。

2021年5月，IETF宣佈了QUIC的標準RFC9000 [2] ，同時RFC9000由RFC8999 [3] （Version-Independent Properties of QUIC），RFC9001 [4] （Using TLS to Secure QUIC）和RFC9002 [5] （QUIC Loss Detection and Congestion Control）所支持。

至此，QUIC協議的完整標準已經形成，iQUIC與當初的gQUIC已有相當大的不同，可以完全將其視爲一個單獨的協議。從數據包的格式、握手方式和HTTP映射，iQUIC改進了當初gQUIC的設計，這也得益於許多組織和個人的開放協作，他們的共同努力讓互聯網變得更快、更安全。

作者注： 本文後續如未加特殊說明，都是在描述iQUIC。

QUIC協議的現狀

 

QUIC協議的誕生與今天的互聯網應用場景和傳輸性能密切相關。在互聯網和HTTP發展的過程中，HTTP底層協議大體上來說基本沒變。但是，隨着海量移動設備推高互聯網流量，越來越多的應用場景需要低延遲、高吞吐、應用QoS感知的網絡傳輸等，原來的HTTP協議在提供流暢、高效的Web訪問方面越來越難以滿足應用需求。

QUIC的一切特性始於“構建在UDP之上”

“構建在UDP之上”意味着可以不關心內核或者不用深入瞭解內核的開發，也可以靈活地調整可靠傳輸機制和擁塞控制算法等，這極大地方便了各種對傳輸QoS敏感的應用，比如實時音視頻傳輸、在線遊戲等。 QUIC的主要特性如下所示：

• 選擇UDP也能讓QUIC協議不依賴網絡中間設備Middle-Boxes做調整。

• TCP協議的開發、調試、觀測的困難問題也會迎刃而解，無需通過複雜的BPF（Berkeley Packet Filter）來採集和調試協議棧程序，只需在用戶態部署簡單的數據收集程序。

• 應用程序的崩潰問題也不至於影響系統內核，而且可以留足崩潰現場做後續分析。

• 用戶態有更多的程序庫幫我們實現更復雜、更全面的策略，比如自適應CC（Congestion Control）算法。

• 利用UDP的數據包無序列依賴，QUIC多數據流之間多路複用，無隊首阻塞問題，並且各自有獨立的流控（Flow Control）。

• 耦合TLS1.3實現0-RTT建連，連接複用。

• 用戶態實現和網絡五元組無關的連接標識ID，ConnectionID，實現連接遷移，以及後續的多路徑（Multipath QUIC）。

QUIC的使用量穩步提升中

隨着QUIC v1版協議標準的出現，越來越多的網站開始使用QUIC流量，根據W3Techs [6] 的統計顯示，目前大概有23.8%的網站使用了HTTP/3。

瀏覽器支持情況

• Chrome和Opera都支持gQUIC和iQUIC。

• 2021年5月，Firefox在Firefox Nightly版本中開始支持QUIC。

• 2020年4月，Apple在WebKit引擎進行了試驗性的QUIC支持，並正式在macOS Big Sur和iOS 14上的Safari 14中支持，但是需要手動打開HTTP/3。

  
  

客戶端支持情況

• Cronet是最早支持QUIC的客戶端庫，目前有比較多的客戶端引用了Cronet庫，其中包括Google Play Services、YouTube、Gmail等。

• cURL 7.66版本（2019年9月發佈）也支持了QUIC，不過cURL引用的QUIC協議棧是Cloudflare RUST開發的quiche開源庫。

• 2020年10月，Facebook聲稱其下各APP也都支持了QUIC，包括Instagram，並且有75%的流量使用了QUIC協議。

• Uber App也支持了QUIC協議。

服務端支持情況

• 2016年和2017年開始就已經有不少公開的QUIC服務端實現了，其中Google開源了其原型服務端源碼：https://github.com/google/quiche/blob/main/quic/tools/quic_server_bin.cc。

• 開源Caddy Server也有一套基於Go語言實現的QUIC協議棧，能夠提供QUIC服務。

• 2017年開始，LiteSpeed在其WebADC（Load balancer）和LiteSpeed Web Server產品上也支持了QUIC協議。

• 2018年開始，Facebook和Cloudflare也開始在其服務端支持QUIC協議。

• 2021年開始，微軟在其Windows Server 2022和SMB上開始支持了QUIC協議，並開源了其協議棧MsQuic。

• 隨後，Citrix的ADC（Application Delivery Controller）和NetScaler產品也支持了QUIC協議。

部分開源QUIC協議棧列表 [7]

阻礙QUIC發展的一些問題

集成難度

無論是在客戶端還是服務端，QUIC協議的集成並非一件易事。如果當前使用的網絡不支持QUIC，意味着我們需要修改應用程序來適配網絡庫的調整。這往往並不是應用迭代的出發點。

下面讓我們來看看客戶端和服務端在集成QUIC協議時需要考慮的問題：

客戶端

• 應用適配成本和收益之間的權衡。

• 過渡期可能還需要新舊網絡庫都存在，方便降級容錯，增加應用體積。

• 不同的QUIC庫的接口並不統一，不像Socket統一接口具備移植性。

服務端

• 網絡事件模型需要適配QUIC協議棧做調整，同時還要考慮和TCP的兼容。

• 後端架構面臨調整，4層Load Balancer是否支持QUIC，HTTP/3的QUIC流量如何換成HTTP/1轉給Backend Service。

• 需要考慮到多Region、多節點之間的QUIC連接複用和連接遷移。

• 服務端QUIC流量的能耗比，如何做到和TCP一樣的能耗性能。

QUIC協議棧性能

對比已經發展了三十多年的TCP協議，新興的QUIC協議在協議棧實現的工程上還有很多優化的事情要做，根據Google 2017年公開的數據可以看到 [8] ，當時QUIC同等流量的CPU消耗是TCP的2倍之多。QUIC協議棧的性能痛點主要有：

• UDP數據包收發性能

• 數據裝包、拆包處理性能

• 數據包解析性能

• ACK處理性能

• 加、解密性能

• 其他流程處理的性能：數據包Pacing、CC算法、內存使用等

UDP數據包性能

UDP數據包在內核接收發送上一直沒有得到和TCP數據包一樣的優化待遇，UDP收發佔據了QUIC協議棧比較大的消耗。

• 原始的sendto/write的UDP Socket接口性能很弱。

• 批量收發數據sendmsg/sendmmsg提升不夠明顯。

• 內核GRO/GSO可以提升性能，但還不夠。

• 內核XDP或者DPDK可大幅提升性能，但程序改造量極大。

• 硬件NIC Offload UDP收發能終極優化，同樣程序改造量極大。

上圖是Google在2020年統計的QUIC能耗情況 [8] ：相比於TCP/SSL，QUIC有20%的額外消耗。B站內部也差不多在這個水平，不過相信隨着更多的優化方案的實施，QUIC和TCP的流量能耗會趨於一致。

UDP被運營商QoS限制

據我瞭解，結合我們自己部署的QUIC協議運行情況來看，國內運營商確實會對UDP流量做些QoS的限制，但是能夠被QoS限制的比例微乎其微，可以完全忽略。運營商這麼做主要基於兩個原因：

1. UDP流量五元組在NAT狀態上連接老化的時間控制不夠精確，時間設置太長會破壞低頻通信的UDP連接，太短會導致UDP連接消耗比較多的設備性能。一般會選擇一個折中的經驗值，這就會傷害一些特定場景的UDP流量了。

2. 運營商設備上包分類的優先級隊列對於UDP五元組的管理比較困難，因爲UDP的五元組會頻繁變動，只能眼睜睜看着UDP流量擠佔各級隊列，卻沒辦法實施精確地控制。一般來說，運營商會在特定時間段或者特定負載情況下對UDP流量做全侷限制。

調試QUIC協議

隨着QUIC協議越來越多的使用，調試QUIC協議的方法也逐漸形成了標準——qlog（目前還是草案 [9] ）。我們可以把qlog理解成一種和wireshark類似的抓包工具，但是是嵌入到協議棧內部的抓取數據包關鍵信息的一套協議，具體可參考qlog草案。qvis則是qlog的一套前端工具 [10] ，用來幫助工程師調試調優QUIC協議交互過程。

其實qlog能做的不僅這些，我們可以結合大數據分析和機器學習模型，在海量的QUIC傳輸數據裏進行分析，能夠做到網絡故障的自動定位、傳輸算法調優和網絡特徵工程等，具體可參考 [11] 開源項目，本文不做詳述。

 QUIC協議的未來

雖然QUIC協議是因爲HTTP/3而提出來，但我認爲，QUIC的未來應該不僅限於HTTP/3。QUIC已具備的一些特性，不僅可以讓現有的Web應用運行得更快更安全，還能適配到更多應用場景上，比如IoT、VR、音視頻會議等。基於QUIC協議之上，工程師們可以定製開發更多場景的應用，同時也讓QUIC協議具備的能力更加完善。

從我個人出發，結合B站的業務場景，我主要關注了QUIC協議在音視頻傳輸領域的未來發展：QUIC Datagram[12]和QUIC Multipath[13]。

QUIC Datagram——QUIC的非可靠數據報文傳輸擴展

QUIC v1（RFC9000）提供了一個安全、可靠、多路複用的傳輸方案，QUIC Stream數據流是QUIC主要數據傳輸的載體，可靠傳輸是其需要保證的基本功能。

但是有些應用場景並不需要嚴格的可靠傳輸，例如實時音視頻、在線遊戲等。現在這些場景有些是直接基於自定義UDP或者WebRTC實現的。自定義UDP實現傳輸層功能的話比較麻煩，工程量大，有時候爲了安全考慮還需要加上DTLS支持，而WebRTC的建立數據傳輸通道流程也比較繁瑣，WebRTC主要場景是爲了P2P設計的，長遠來看並不適合客戶端服務端的場景。

因此，QUIC支持不可靠數據傳輸能夠讓QUIC協議的應用範圍更廣，適合更多的應用場景，而且QUIC之上的不可靠數據傳輸能夠很好地複用QUIC的安全特性。

QUIC Datagram特點

• 同一QUIC連接裏面可以同時包含可靠Stream傳輸和不可靠數據傳輸，它們可以共享一次握手信息，分別可以作用於TLS和DTLS，可降低握手延遲。

• QUIC在握手上比DTLS更加精準，它對每個握手數據包加上了超時重傳定時器，能夠快速感知握手包的丟失和恢復。

• QUIC Datagram的不可靠傳輸也可以被ACK，這是一個選項，如果有ACK，可以讓應用程序感知到QUIC Datagram的成功接收。

• QUIC Datagram也適用於QUIC的CC。

  
  

這些特性能夠讓實時音視頻流、在線遊戲和實時網絡服務等應用的傳輸得到極大的效率提升。

WebTransport呼之欲出

WebTransport是一個框架型的協議[14]，該協議使客戶端與遠程服務器端在安全模型下通信，並且採用安全多路複用傳輸技術。注意：WebTransport是一個框架，在它下面是實際的協議，框架提供了一個一致的接口，因此它由一組可以安全地暴露給不受信任的應用程序的協議以及一個允許它們互換使用的模型組成。它還提供了一組靈活的功能，爲我們提供了可靠的單向和雙向流以及非可靠的數據報文傳輸。

QUIC Multipath

QUIC Multipath多路徑傳輸，簡言之就是用多個物理網絡路徑來傳輸數據，可以同時使用WIFI、LTE/4G或者IPV4/IPV6。隨着音視頻的消費碼率越來越高，對網絡連接的吞吐能力要求越來越高，單路徑的網絡情況開始捉襟見肘，MP-QUIC可以發揮比較大的作用。比如在超高清、超高碼率視頻8K、VR等場景。

MP-QUIC基本思路是: 用多個網絡路徑來組成一個QUIC連接進行數據傳輸，MP-QUIC其實也是對連接遷移特性的一次拓展，協議標準也在草案階段[13]。用多個網絡路徑實現一個QUIC連接看似簡單，其實實現上有很多事情需要考慮：

• 異構網絡

• 數據包冗餘分配和流量成本之間的ROI

• 多路徑調度策略

  
  

  
  

協議標準目前只規定了多路徑實現的機制，也就是多個單向的UniFlow組成QUIC連接，多路徑調度和冗餘包策略都需要額外單獨實現。不過隨着業務場景需求的展開和協議標準的正式推出，我相信MP-QUIC在音視頻傳輸上的應用會越來越多。

參考文獻

[1] QUIC Wiki: https://en.wikipedia.org/wiki/QUIC

[2] RFC9000: https://datatracker.ietf.org/doc/html/rfc9000

[3] RFC8999: https://datatracker.ietf.org/doc/html/rfc8999

[4] RFC9001: https://datatracker.ietf.org/doc/html/rfc9001

[5] RFC9002: https://datatracker.ietf.org/doc/html/rfc9002

[6] W3Techs HTTP/3 Usage Statistics: https://w3techs.com/technologies/details/ce-http3 

[7] QUIC Workgroup Implementations List: 

https://github.com/quicwg/base-drafts/wiki/Implementations 

[8] QUIC CPU Performance: https://conferences.sigcomm.org/sigcomm/2020/files/slides/epiq/0%20QUIC%20and%20HTTP_3%20CPU%20Performance.pdf

[9] QLog: https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-01

[10] Debugging QUIC and HTTP3 with QLog: https://www.researchgate.net/publication/342783373_Debugging_QUIC_and_HTTP3_with_qlog_and_qvis

[11] QLog&Qvis Tools: https://github.com/quiclog

[12] QUIC Datagram: https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram-06

[13] QUIC Multipath: 

https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/

[14] W3C WebTransport: https://www.w3.org/TR/webtransport/

作者簡介 ：王盛，B站視頻雲CDN系統負責人。多年音視頻後端開發和網絡傳輸開發的經驗，參與了B站視頻雲平臺從零到TB級的建設。主導研發了B站千萬級DAU的音視頻分發網絡，精通各類網絡傳輸協議和各場景敏感的網絡算法調優。

---

講師招募

LiveVideoStackCon 2022 音視頻技術大會 上海站，正在面向社會公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內容對技術人有幫助，其他都是次要的。歡迎通過 [email protected] 提交個人資料及議題描述，我們將會在24小時內給予反饋。

喜歡我們的內容就點個“在看”吧！

本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。