一. 前言與背景

國內的互聯網直播技術從2005年前后興起，彼時最具代表性的直播產品是由PPLive創始人姚欣在華中科技大學就讀期間發起的校園直播項目PPLive。當時的直播技術用的還是基于windows系統自帶的mediaplayer內置的COM組件開發的播放器，采用的是RTSP協議。受當時的互聯網傳輸帶寬及成本限制，PPLive并沒有采用現在比較流行的單播技術，而是采用P2P技術分發直播流。國內的直播技術也進入了一段以P2P技術為主的時期，其中比較有代表性的就是PPLive和PPStream。用P2P技術分發直播流，具有運營成本低的明顯優勢，每一個參與播放的終端都是一個潛在的數據熱點，網絡質量隨著觀看直播流的客戶端的增加而增加。但P2P技術也有自身的不足，缺乏觀眾的冷門資源因參與數據共享的客戶端稀少而難以保證播放質量，另外P2P難以保證UDP打洞穿透率、需要下載專用的播放器等都是限制用戶數量增長的因素。

P2P直播分發技術注定是一個過渡性的技術。2005年以后，由于早期的HTML標準尚不完善，各大瀏覽器存在實現上的差異，被寄予厚望的HTML5規范也還尚未定稿，基于HTML的視頻播放技術也不成熟。彼時，Adobe公司從Macromedia公司收購的網頁多媒體插件flashplayer在這種情況下脫穎而出。在開發層面，flashplayer因其優異的多媒體表現力以及完善的開發語言和調試工具，降低了網頁播放器的開發門檻。在音視頻質量方面，Flashplayer內置的On2公司的VP6視頻編解碼器無論是在編碼質量還是在解碼效率上在當時都非常優秀，隨著2003年才定稿的H.264/AVC視頻編解碼器及更高質量的AAC音頻解碼器也很快被內置到flashplayer內核，進一步提高了flashplayer的音視頻能力。在播放器推廣層面，基于flashplayer開發的播放器文件，能像分發網頁一樣通過網站服務器下發和更新，這極大地降低了視頻網站的推廣難度。上述原因，促使flashplayer成為當時最好的網頁視頻播放器內核。在flashplayer的技術加持下，視頻點播網站如雨后春筍般涌現，尤其在2006年google收購youtube后，網頁視頻點播網站迎來了爆發，六間房、優酷、土豆等視頻網站先后融入巨資，從眾多點播網站中脫穎而出。彼時，flashplayer作為絕大部分視頻點播網站統一使用的網頁播放器，裝機率快速提高，逐步成為事實上的網頁多媒體播放器標準。2009年，隨著Adobe將flashplayer內置的革命性的流媒體傳輸協議RTMP(Real-Time Messaging Protocol)規范開放，本就已經方興未艾的RTMP直播技術，進入了發展的快車道。各種基于RTMP協議的開源實現陸續出現，涵蓋服務器和播放器。由此，互聯網直播進入了由flashplayer和RTMP協議主導的時代。

RTMP是flashplayer原生支持的流媒體傳輸協議，支持點播和直播模式，經過十多年的大規模應用，已經成為當前國內應用最為廣泛的直播協議，各大CDN廠商都已經支持。國內技術圈還發展出了HTTP-FLV協議，即將RTMP中的直播音視頻流封裝成FLV文件流，通過HTTP協議傳輸，這進一步降低了直播技術的接入成本和實現難度。

RTMP和HTTP-FLV都是基于TCP的直播協議，TCP固有的基于擁塞控制的傳輸策略在需要穩定、大量傳輸數據的直播場景下顯得過于保守，偶發的丟包或網絡抖動都會造成數據收發速率的急劇下降，從而造成畫面及聲音的卡頓，影響直播的質量及體驗。而基于帶寬和延時預測的QUIC傳輸協議的出現，為直播行業提供了一個提升直播質量和用戶體驗的新的選項。

二. QUIC介紹

QUIC（讀作“quick”）是一個通用的傳輸層網絡協議，最初由Google的Jim Roskind設計。該協議于2012年實現并部署，2013年隨著實驗范圍的擴大而公開發布，并向IETF描述。雖然長期處于互聯網草案（英語：Internet Draft）階段，但從Chrome瀏覽器至Google服務器的連接中超過一半的連接都使用了QUIC。Microsoft Edge、Firefox都已支持此協議；Safari實現了QUIC，但默認情況下沒有啟用。QUIC于RFC9000中被正式標準化。

雖然QUIC的名稱最初是“快速UDP互聯網連接”（Quick UDP Internet Connection）的首字母縮寫，但IETF指定的標準中QUIC并不是任何內容的縮寫。QUIC提高了目前使用TCP的面向連接的網絡應用的性能。它通過使用用戶數據報協議（UDP）在兩個端點之間建立若干個多路連接來實現這一目標，其目的是為了在網絡層淘汰TCP，以滿足許多應用的需求，因此該協議偶爾也會獲得 “TCP/2”的昵稱。

QUIC與HTTP/2的多路復用連接協同工作，允許多個數據流獨立到達所有端點，因此不受涉及其他數據流的丟包影響。相反，HTTP/2建立在傳輸控制協議（TCP）上，如果任何一個TCP數據包延遲或丟失，所有多路數據流都會遭受隊頭阻塞延遲。

QUIC的次要目標包括降低連接和傳輸時延，以及每個方向的帶寬估計以避免擁塞。它還將擁塞控制算法移到了兩個端點的使用者空間，而不是內核空間，據稱這將使這些算法得到更快的改進。此外，該協議還可以擴展前向糾錯（FEC），以進一步提高預期錯誤時的性能，這被視為協議演進的下一步。

三. 京東直播技術簡介

京東直播體系從零開始構建，如下圖所示，涵蓋四大業務模塊：推流端、中臺源站、直播云CDN及播放端。

??

圖1.京東直播產品體系

從上圖可以看出，直播流的端到端傳輸，中間要經過多個鏈路。直播數據因數據量大、占用帶寬高、傳輸距離長而符合典型的Long-Fat（長肥）網絡定義。在應用QUIC技術之前，京東的直播產品都是使用基于TCP的協議（RTMP/HTTP-FLV/HLS等）進行直播流數據傳輸，TCP因其保守的擁堵控制策略，在應對Long-Fat網絡應用場景時差強人意，QUIC技術的出現，為優化直播傳輸質量提供了新的選擇。

京東從2021年上半年開始研究QUIC，基于QUIC ietf v1版本開發了自研的QUIC實現QUIC-Pro，并最先在京東的直播場景落地。QUIC在京東直播技術體系的落地過程并非一蹴而就，而是循序漸進的。考慮到直播數據流從CDN邊緣服務器分發到用戶端是最復雜的“最后一公里”問題，因此，我們選擇QUIC最初的落地場景是直播的分發和播放。

QUIC落地之前，為了量化直播質量，方便對比優化收益，我們制定了統一的全鏈路質量監控及數據上報標準，收集推流端、直播源站、直播云CDN及播放端等所有環節的跟傳輸、播放相關的監控數據，并統一上報到數據收集平臺進行聚合、分類及統計，在眾多質量指標中，選定畫面首開時長、卡頓率及播放失敗率作為播放質量的重要量化參考指標。

本文將分別從推流端、中臺源站、直播云CDN及播放端四個部分串燒式地介紹與直播相關的一些技術實踐，并重點介紹QUIC技術的應用情況及收益。

四. 推流端技術

京東直播支持的推流端包括京東視頻APP，PC桌面端推流工具以及web網頁端企業直播工具。京東視頻APP及PC桌面端推流工具除支持真人直播及美顏功能外，還支持數字人直播，數字人直播數據流程如下圖所示。

圖2.京東數字人直播SDK架構

上圖中，VideoSource和AudioRecord分別控制圖像和聲音數據的輸出，當真人直播時，VideoSource打開CameraCapturer，采集攝像頭圖像數據，并送到Filter濾鏡鏈條進行美顏等操作，然后進行視頻編碼并打包發送，音頻則通過AudioRecord打開MicrophoneRecord，采集麥克風聲音進行錄制、編碼并打包發送。

當采用數字人直播時，流程經過圖中黃色模塊，TextureFactory模擬攝像頭運行機制，按幀率設置定期生成空白紋理，紋理經過VideoSource進入濾鏡鏈條，濾鏡鏈條中有一個3DEngineFilter濾鏡，將京東自研的數字人3D引擎生成的數字人圖像渲染到紋理，然后在屏幕上展示該紋理，同時將紋理上的圖像進行編碼、打包、發送。數字人的音頻，則通過AudioPlayer控制音頻播放到設備的同時，將音頻采樣數據輸出到AudioRecord，然后經過編碼、打包，并發送出去。

五. 直播源站與CDN分發網絡

京東直播包括實時音視頻源站、實時轉碼、錄制、審核等業務，推流端的實時音視頻流都是先推到中臺源站，然后再經過處理通過京東直播云CDN分發到播放端。中臺源站還負責直播連麥相關業務的處理，包括混音、合屏等操作。

圖3.京東中臺直播源站低延遲直播服務架構

直播云CDN通過京東云對外提供賦能，直播云CDN承載了京東主站、京喜等含直播功能的產品的日常直播流分發服務。經過近一年的密切合作，京東直播中臺團隊和京東直播云CDN團隊已將共建的QUIC直播流分發服務全量部署到所有服務節點。直播云服務流程如下圖所示。

圖4.京東直播云CDN分發流程圖

上圖是京東直播云CDN對直播流的分發流程圖，最左側是直播源站或直播應用直推直播流到邊緣推流集群，經過錄制、轉碼截圖、中轉集群等中間模塊及服務處理，最后轉推給第三方CDN或經由邊緣播放集群分發給播放端。

六. QUIC服務端設計

當前網絡上開源的服務端QUIC協議棧實現方案有多種，例如Chromium QUIC、Lsquic、Nginx 官方quic、cloudfare quic等。其中Chromium QUIC發展的最早，也相對最成熟。因此JDQUIC服務端依托Chromium QUIC，使用了其QUIC協議棧相關源碼，服務器框架及其他所有代碼則為自研。

6.1．JDQUIC服務器模式

為盡量減少對現有直播CDN分發體系的改造，并保持QUIC的可擴展性及高效迭代更新，JDQUIC服務器采用反向代理模式進行QUIC直播流的請求、轉換與分發。

??

圖5.JDQuicServer工作流程

如上圖顯示，手機端播放器發送QUIC直播流拉流請求到JDQuic-Server服務器，JDQuic-Server服務器將請求格式轉換為普通的http或tcp數據，發送給后端Web或者TCP服務器，然后接收后端HTTP-FLV服務器返回的直播流數據并通過HTTP/QUIC協議下發給播放器。整個服務過程無需對后端服務體系作任何修改。

由于JDQUIC服務器一般和后端服務器部署在同一機房、甚至同一機器上，兩者之間的數據傳輸延遲基本可以忽略不計。

6.2. JDQUIC服務端架構

JDQUIC服務端采用多進程單線程架構。消息驅動采用了Libevent epoll模式，QUIC協議棧則使用了Chromium QUIC協議棧相關代碼。如下所示：

圖6.JDQuic-Servrer內部架構

JDQUIC 服務端采用單線程多進程架構，單機多進程采用內核ebpf進行負載均衡。

單線程內部采用Libevent epoll進行消息監聽和分發，TCP UDP Unix domain、http等多種協議依托Libevnet進行收發，同時超時和異步消息也通過Libevent架構進行回調。

Libevent 收上來的UDP數據包，在Chromium QUIC協議棧進行解析，還原出原始Http或者裸數據。這些數據經過線程內無鎖調度模塊，傳給后端Nghttp2或tcp udp client模塊，發送給后端服務器。

6.3. JDQUIC連接遷移

網絡的切換在當今移動網絡大規模普及的背景下，是經常發生的事情。考慮如下場景，當用戶正在戶外用移動4G/5G網絡看著直播的過程中，走到了一個具備WIFI網絡的地方，連上了可用的wifi網絡，此時，網絡切換便發生了。如果要保證直播連接在網絡切換后仍然保持暢通，需要實現一套連接遷移機制。JDQUIC-server的實現及工作原理，如圖7所示：

??

圖7.JDQuic-Server連接遷移原理

【工作流程】

1.手機端從4G網絡切到wifi網絡。

2.手機端網絡連到不同的運營商機房（從移動機房切到聯通機房）。

3.Ospf和nftable負載分配到一個機器quic server實例。

4.Quic server 通過quic數據包中的connection id中第一個字節，判斷數據包該發回哪個機房。

5.Quic server 把數據包轉發給原來的機房。

6.原來的機房再負載到正確的quic實例。

【說明】

?Ospf負載: 三層負載均衡服務，硬件負載，效率很高。

?Nftable單機負載: 操作系統內核級別的負載服務。

?QUIC服務: quic服務器，可以將quic協議轉換為http去后端FMS/SRS拉流。

?后端FMS/SRS：直播流媒體/CDN服務器。

?紅色箭頭：手機端首次播放直播的拉流路線。

?藍色箭頭：手機端網絡切換WIFI后進行連接遷移的拉流路線。

6.4. JDQUIC DCID設計

連接遷移時，聯通機房的quic server想要找到回源的機器，需要從quic數據包的DestionationConntion id字段獲取機房信息，如下圖所示。

圖8.JDQuic-Server CID擴展設計方案

CID字段取一個字節來映射機房信息，例如0x01表示長春移動，0x02表示長春聯通等。

6.5. JDQUIC ebpf設計

6.5.1. eBPF簡介

Linux 內核一直是實現監控/可觀測性、網絡和安全功能的理想地方。 不過很多情況下這并非易事，因為這些工作需要修改內核源碼或加載內核模塊， 最終實現形式是在已有的層層抽象之上疊加新的抽象。 eBPF 是一項革命性技術，它能在內核中運行沙箱程序（sandbox programs）， 而無需修改內核源碼或者加載內核模塊。

將 Linux 內核變成可編程之后，就能基于現有的（而非增加新的）抽象層來打造更加智能、 功能更加豐富的基礎設施軟件，而不會增加系統的復雜度，也不會犧牲執行效率和安全性。

??

圖9.eBPF原理及工作流程

6.5.2. eBPF在JDQuic-Server中的應用

linux內核中，通過ebpf維護兩個映射表，并編寫一段ebpf JIT（即時編譯）程序。客戶端QUIC數據包進來后，ebpf JIT程序根據ip端口、CID進行hash，分別訪問兩個map表，來判斷需要轉發給哪個后端QUIC實例。其中，ip和端口為UDP協議數據包的字段，包括源IP、目的IP、源端口、目的端口（合稱四元組），如圖所示。

圖10.JDQuic-Server內部ebpf負載均衡原理

七. QUIC技術收益

QUIC協議基于帶寬瓶頸預測及環路延時預測的傳輸控制算法，相比TCP的基于網絡擁塞的控制算法，在抗網絡抖動、提高網絡傳輸速率方面有顯著優勢。根據QuicPro在線上Android應用內的直播場景中的使用情況統計數據顯示，直播卡頓率較TCP由1.43%降為1.14%，降幅為20%，首開時間較TCP的949毫秒降為659毫秒，降幅為30.5%，如下圖所示：

??

圖11.TCP與QUIC分別在直播卡頓率及首開時間上的對比

八. 結語

京東直播經過4年多的發展，技術上無論是服務架構還是播放協議都經過了多輪迭代，截至本文成文，仍在進行迄今為止最大規模的改造升級，涉及全鏈路的協議升級與架構優化。協議上，將原有的基于TCP的信令、推流、分發、播放等環節升級為QUIC協議，在服務架構上，進行推流及媒體服務邊緣化改造，在分發上，中臺與京東云直播CDN兄弟部門共建低延遲分發網絡，我們共同的目標是提升傳輸質量、降低卡頓率的同時，將直播端到端的延遲降低到2秒甚至是1秒以內。

審核編輯 黃宇