QUIC協議快速建立連接、擁塞控制靈活、多路復用等特性為網絡傳輸帶來了不少收益，也更好的提升了用戶的體驗。嗶哩嗶哩高級工程師 王盛在LiveVideoStack線上交流分享中介紹了B站在QIUC研發與部署中的實踐經驗，LiveVideoStack對分享內容進行了整理。

文 / 王盛

整理 / LiveVideoStack

直播回放

https://www.baijiayun.com/web/playback/index?classid=19010981268177&token=-tkUdxVX8Ti1r0cPh106AvZXQLOzrJs4N_7hHIksFNZBJ7OhUy3qsJbeBQgjkUbzjAk6Qj2pOAo

大家好，我是來自Bilibili的王盛，五年多來我一直從事網絡協議和點直播系統的研發工作，加入B站后主要負責Bilibili的點直播系統開發，可以說見證了B站的點直播系統從零發展到目前TB級別的整個過程。接下來我將從以下四個方面為大家分享B站在QUIC協議上的技術探索，希望大家能通過此次分享了解更多QUIC特性與服務端架構技術細節。

1.?從Http1.1、Http2到QUIC

我們討論QUIC協議一定先從HTTP協議出發。作為目前互聯網上被使用最多的網絡協議，HTTP經歷了從1996年誕生到現在二十多年的發展，相對于早期的1.0、1.1版本，現在的2.0版本可以說發生了非常大的變化。據第三方機構統計，2015年HTTP/2版本的更新不僅加入了如二進制協議、多路復用、服務端推送等諸多新特性，更是實現了相對于HTTP/1近兩倍的性能提升。

而我們今天討論的QUIC協議其實就是所謂的HTTP/3，Google從提出QUIC協議以來一直想將其作為優化與替代現行HTTP協議的解決方案。從上圖我們可以看出QUIC是完全基于UDP協議實現的，我們知道現在主流的兩大互聯網傳輸協議是TCP與UDP，前者連接可靠的數據傳輸而后者連接不可靠的數據傳輸；如果QUIC協議建立在UDP協議之上就需要實現一系列與TCP相似的數據傳輸操作如擁塞控制、數據重傳、數據排序等，使得基于UDP的QUIC成為一種用戶態的協議。目前TCP協議實現大部分功能都離不開內核，這就導致如果開發者希望修改調整TCP協議中的某一些特性與功能或根據需求進行定制化開發部署的難度非常大，尤其是涉及到內核改動的工作會帶來不必要的開發成本；除了具備用戶態協議的優勢，為了實現更快的數據傳輸，QUIC也囊括了一些類似于TLS安全傳輸層的功能，為了提高兼容性QUIC也提供與之前HTTP2一樣HTTP語義，從而實現在應用層程序方面良好的兼容性。

QUIC協議從誕生至今獲得了不少廠家與企業的支持，也為這些企業帶來了收益與回報。縱覽整個行業，國外如Google搜索、YouTube視頻、Akamai CDN等等都實現了對QUIC協議的支持，國內如騰訊云的負載網關、QQ空間、七牛直播云的直播推流等都在QUIC協議的幫助下實現了如0卡頓的直播推流等等技術提升，而B站的點直播CDN也實現了對QUIC的全面支持。QUIC為這些企業帶來的收益同樣不容小覷，如為Google搜索頁面帶來了5%的加載速度提升，使YouTube的視頻卡頓率降低了30%；為QQ空間帶來了10%的加載速度提升，幫助B站提升10%視頻首幀的同時減小5%的卡頓，可以說極大提升了互聯網產品的用戶體驗。

接下來我們將QUIC和TCP之間的性能與參數差異落實在用戶體驗層面，首先模擬用戶同時使用分別基于QUIC與TCP的兩個播放器播放同一個視頻文件，理想環境下用戶的直觀感受是二者畫面基本同步流暢；但如果使用網絡模擬工具為用戶播放器端到視頻服務器端之間的網絡傳輸增加20%的丟包，此時基于TCP傳輸協議的播放器會出現明顯卡頓而基于QUIC傳輸協議的播放器則仍可保持較為流暢的播放狀態，二者會出現5～10s的播放時間差，不難發現QUIC在弱網環境下的傳輸性能優勢非常明顯。

其次我們模擬增加每個數據包的延遲如增加到200ms，隨后使兩個播放器從同一幀開始播放，不難觀察到基于TCP協議播放器的畫面明顯滯后，QUIC的首幀展示也更快。

2. QUIC協議特性

無論是弱網環境的卡頓還是首幀展示，QUIC相對于TCP的實際傳輸性能提升都十分明顯。這與QUIC協議本身的一些特性緊密相關，主要包含以下四部分：

?

2.1 極短的建連時間

在QUIC的建連時間中大部分為0-ORTT，極少部分是1-RTT，如何實現這樣的分配？首先大家知道，TCP的一個建連包含三次握手，而如果基于HTTPS加密則還需包含TLS一層的一個握手，同時增加1 RTT的時間；綜合來看，已完成建連的TCP連接進行握手大概需要2 RTT，而首次建連的TCP則需3 RTT，其中便包括TLS的證書交換。但對于QUIC協議，若客戶端之前未建連，其第一次建連時需在客戶端直接生成證書與和協議棧相關的配置且附帶一個ID，這些數據會與請求數據一起直接發送并保存在服務端，假若服務端已存在以上數據那么系統會直接進行校驗操作并直接回復數據；而已建連的客戶端則僅需0-RTTs時間，初次建連的QUIC服務端為便于進行建連與校驗會把ID保存在服務端本地，待服務端完成校驗即可發送證書至客戶端并進行客戶端校驗，校驗成功即可直接啟動數字交換；且對于第一次建連的QUIC而言只需1 RTT就可完成建連并允許后續的數據交互，以上就是QUIC的建連時間特性——大部分0-RTT、極少部分1-RTT。

2.2 多路復用

QUIC協議的第二條特性為完全多路復用，以HTTP1.1為例，每條數據流基于一個TCP連接，每個TCP連接都單獨傳輸數據，但此TCP連接方案會明顯增加服務端與客戶端的并發負載；HTTP/2對此問題進行了有效優化也就是采用多路復用的傳輸策略，通過一條TCP連接傳輸多路數據，但此方案容易造成隊首阻塞問題：以上圖展示的HTTP/2數據流為例，若Stream 2丟失那么Stream 1與Stream 3都會被阻塞，直到丟失的Stream 2數據重傳完成之后Stream 1與Stream 3才能被繼續傳輸，這種因為一條數據流的丟失重傳等問題造成其他多條數據流阻塞的現象被稱為隊首阻塞問題；QUIC對此問題進行了修正，也就是把每個重傳過程安排在每條Stream中單獨完成，由于Stream本質上是一個基于UDP的小數據包，所以這種方案并不會造成隊首阻塞問題。

2.3 靈活的擁塞控制

QUIC的第三個特性被稱為靈活的擁塞控制，QUIC能夠在操作系統層面實現完全用戶態得益于協議棧非常靈活的擁塞控制。如我們之前熟知的被用于TCP的BBR擁塞控制算法也是一開始在QUIC上實驗成功之后才被移植到TCP內核中。當然這種將模塊移植進內核的嘗試是一個非常漫長的過程，但為了實現較為良好的擁塞控制并達到用戶態要求，此方案不失為一種良策。

2.4 連接轉移

QUIC的最后一個特性被稱為連接轉移。什么是連接轉移？假設當你正在家中使用WLAN觀看視頻時需要外出辦事，當你走出家門時手機也會從通過WLAN下載數據改為通過蜂窩網絡下載，在WLAN與蜂窩網絡切換的瞬間TCP連接會被切斷再重連，這是因為TCP采用包括原IP、目標IP、原端口、目標端口在內的四元組方式表征一個連接；QUIC并未采用四元組的表征方式，而是將數據包中一個64位的數值ID作為表征，無論WLAN與蜂窩網絡如何切換，只要發送至的服務端數據當中的ConnectionID一致，服務端就會默認其為同一個連接，從而避免出現切斷重連的過程。

3. 視頻云的QUIC實踐

3.1 Roadmap

?

接下來我將重點介紹B站開發QUIC協議的實踐經驗。我們在開發QUIC協議之前，遇到了以下兩個難點：首先，作為一個正在開發中的協議草案，QUIC協議標準本身需要頻繁進行迭代更新，大約1.5個月更新一個版本。如現在被廣泛使用的QUIC43就是不到一年前從QUIC37、35或39等版本迭代而來，而不斷跟進此協議標準的迭代升級確實是一件很難的事情；其次是開發QUIC網絡協議本身是一個比較底層的實踐，需要開發者具備較強的技術素養才能攻克其中諸多的技術難點。B站已在服務端全面上線QUIC，客戶端的QUIC也正在灰度上線中。

3.2 技術選型

?

我們嘗試探索多元化技術選型，通過一個季度的調研確定了以下幾個可實現QUIC的常見開源項目：Libquic、Caddy&Quic-Go、Stellite&Isquic與Chromium。我們嘗試借助這幾個開源項目快速搭建并上線QUIC服務端，并仔細對比這幾個方案的利弊：Libquic雖然具有一些可在Chromium中實現的優勢，但其早在兩年前就已經停止更新；Caddy&Quic-Go作為使用（……long）實現的單協議棧，其測試性能無法滿足我們的上線標準；Stellite&Isquic作為商業解決方案不但需要我們花大量成本進行部署，而且其協議棧的功能也不夠全面；Chromium作為Google官方的開源項目，雖然與QUIC協議標準始終保持一致的版本更新，但其接近兩千多萬行的龐大代碼量明顯增加了我們的運維壓力。基于以上調研結果，最終我們決定使用Chromium快速搭建QUIC服務端，主要分為以下兩步：首先使用Chromium的QUIC協議棧模塊打包一些API，其次是自主實現能夠滿足生產環境的UDP Server，結合以上兩者完成QUIC服務端的上線開發。

?

上圖展示的就是我們在調研與探索過程中參考的資料來源。

3.3 初期架構

?

上圖展示了B站在QUIC服務端實現的一個初期架構，為了與B站目前點直播系統的（NGX）體系兼容，我們僅將QUIC服務端作為一個代理接收來自公網的數據并轉發至本機的（NGX ）服務器。由上圖架構不難發現我們的工作重點是根據在主線程上進行收發的UDP數據包中的一些連接，將ConnectID分發至不同的工作線程。每個工作線程上都會運行一個QUIC協議棧，從而進一步發掘整個QUIC服務器的性能。需要注意的是，非單一的QUIC協議棧在處理網絡UDP數據包或QUIC數據包時存在限制條件，也就是必須按照其ConnectID進行分發，否則就會出現一個連接進入兩個協議棧的錯誤，繼而導致數據丟失甚至服務宕機的狀況。在此限制條件下此架構可實現如負載均衡等功能。與此同時我們通過QUIC到TCP的代理轉發，把QUIC的HTTP2的協議轉發為（NGX） Server使其能夠為本地的（NGX） Server服務并接收（NGX） Server的回復，最終將（回復）轉化為UDP包返回至QUIC客戶端，這便是我們QUIC服務端的初期架構與細節。

3.4 使用方式

?

用戶可直接使用內核支持QUIC的Web端如Chrome、QQ瀏覽器、Opera（內核）觀看B站的視頻；與此同時我們也會盡快灰度上線移動端的QUIC灰，為大家帶來酣暢淋漓的QUIC高效傳輸體驗。

4. QUIC展望

?

展望未來的QUIC，機遇和挑戰并存。作為較早入局QUIC探索的開發團隊，我們除了期待更優秀的適合視頻傳輸的擁塞控制模型算法早日出現，也期待有更多建立在QUIC之上的協議如RTMP等的出現；當然，我們也面臨著諸多挑戰，如一旦gQUIC、iQUIC或HTTP/3成為標準，那么我們的協議棧就會面臨大范圍的改動，同時迭代更新也會增加我們的開發成本；其次，由于不存在流量控制，容易被用于流量攻擊，UDP包存在被運營商特殊對待的可能；最后是移動端的不同平臺（如Android、iOS）對QUIC的態度與支持力度，我們的愿景是與全行業志同道合者一起致力于QUIC的標準化，彼此分享研究技術亮點，共同努力使用戶的音視頻流媒體觀看體驗登上一個新的高度。

精品文章推薦

技術干貨：

• RUDP傳輸那些事兒

• RTMP之后，SRT與QUIC

• TCP的困境與解決方案

• WebRTC的擁塞控制和帶寬策略

• 基于HLS格式的低延時互動直播技術

• CCtalk高可用多媒體服務技術選型與實現

• UDP成為低延時流媒體關鍵 選SRT還是QUIC？

• 下一代低延時直播CDN：HLS、RTMP 與UDP +WebRTC

總結

以上是生活随笔為你收集整理的B站QUIC实践之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。