一. 前言與背景

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

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

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

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

二. QUIC介紹

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

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

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

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

三. 京東直播技術(shù)簡介

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

??

圖1.京東直播產(chǎn)品體系

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

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

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

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

四. 推流端技術(shù)

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

圖2.京東數(shù)字人直播SDK架構(gòu)

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

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

五. 直播源站與CDN分發(fā)網(wǎng)絡(luò)

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

圖3.京東中臺直播源站低延遲直播服務(wù)架構(gòu)

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

圖4.京東直播云CDN分發(fā)流程圖

上圖是京東直播云CDN對直播流的分發(fā)流程圖，最左側(cè)是直播源站或直播應(yīng)用直推直播流到邊緣推流集群，經(jīng)過錄制、轉(zhuǎn)碼截圖、中轉(zhuǎn)集群等中間模塊及服務(wù)處理，最后轉(zhuǎn)推給第三方CDN或經(jīng)由邊緣播放集群分發(fā)給播放端。

六. QUIC服務(wù)端設(shè)計

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

6.1．JDQUIC服務(wù)器模式

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

??

圖5.JDQuicServer工作流程

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

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

6.2. JDQUIC服務(wù)端架構(gòu)

JDQUIC服務(wù)端采用多進程單線程架構(gòu)。消息驅(qū)動采用了Libevent epoll模式，QUIC協(xié)議棧則使用了Chromium QUIC協(xié)議棧相關(guān)代碼。如下所示：

圖6.JDQuic-Servrer內(nèi)部架構(gòu)

JDQUIC 服務(wù)端采用單線程多進程架構(gòu)，單機多進程采用內(nèi)核ebpf進行負載均衡。

單線程內(nèi)部采用Libevent epoll進行消息監(jiān)聽和分發(fā)，TCP UDP Unix domain、http等多種協(xié)議依托Libevnet進行收發(fā)，同時超時和異步消息也通過Libevent架構(gòu)進行回調(diào)。

Libevent 收上來的UDP數(shù)據(jù)包，在Chromium QUIC協(xié)議棧進行解析，還原出原始Http或者裸數(shù)據(jù)。這些數(shù)據(jù)經(jīng)過線程內(nèi)無鎖調(diào)度模塊，傳給后端Nghttp2或tcp udp client模塊，發(fā)送給后端服務(wù)器。

6.3. JDQUIC連接遷移

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

??

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

【工作流程】

1.手機端從4G網(wǎng)絡(luò)切到wifi網(wǎng)絡(luò)。

2.手機端網(wǎng)絡(luò)連到不同的運營商機房（從移動機房切到聯(lián)通機房）。

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

4.Quic server 通過quic數(shù)據(jù)包中的connection id中第一個字節(jié)，判斷數(shù)據(jù)包該發(fā)回哪個機房。

5.Quic server 把數(shù)據(jù)包轉(zhuǎn)發(fā)給原來的機房。

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

【說明】

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

?Nftable單機負載: 操作系統(tǒng)內(nèi)核級別的負載服務(wù)。

?QUIC服務(wù): quic服務(wù)器，可以將quic協(xié)議轉(zhuǎn)換為http去后端FMS/SRS拉流。

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

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

?藍色箭頭：手機端網(wǎng)絡(luò)切換WIFI后進行連接遷移的拉流路線。

6.4. JDQUIC DCID設(shè)計

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

圖8.JDQuic-Server CID擴展設(shè)計方案

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

6.5. JDQUIC ebpf設(shè)計

6.5.1. eBPF簡介

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

將 Linux 內(nèi)核變成可編程之后，就能基于現(xiàn)有的（而非增加新的）抽象層來打造更加智能、 功能更加豐富的基礎(chǔ)設(shè)施軟件，而不會增加系統(tǒng)的復(fù)雜度，也不會犧牲執(zhí)行效率和安全性。

??

圖9.eBPF原理及工作流程

6.5.2. eBPF在JDQuic-Server中的應(yīng)用

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

圖10.JDQuic-Server內(nèi)部ebpf負載均衡原理

七. QUIC技術(shù)收益

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

??

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

八. 結(jié)語

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

審核編輯 黃宇