QUIC在京東直播的應(yīng)用與實(shí)踐

一. 前言與背景

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

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

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

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

二. QUIC介紹

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

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

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

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

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

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

??

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

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

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

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

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

四. 推流端技術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

??

圖5.JDQuicServer工作流程

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

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

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

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

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

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

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

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

6.3. JDQUIC連接遷移

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

??

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

【工作流程】

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

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

3.Ospf和nftable負(fù)載分配到一個(gè)機(jī)器quic server實(shí)例。

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

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

6.原來(lái)的機(jī)房再負(fù)載到正確的quic實(shí)例。

【說(shuō)明】

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

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

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

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

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

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

6.4. JDQUIC DCID設(shè)計(jì)

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

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

CID字段取一個(gè)字節(jié)來(lái)映射機(jī)房信息，例如0x01表示長(zhǎng)春移動(dòng)，0x02表示長(zhǎng)春聯(lián)通等。

6.5. JDQUIC ebpf設(shè)計(jì)

6.5.1. eBPF簡(jiǎn)介

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

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

??

圖9.eBPF原理及工作流程

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

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

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

七. QUIC技術(shù)收益

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

??

圖11.TCP與QUIC分別在直播卡頓率及首開(kāi)時(shí)間上的對(duì)比

八. 結(jié)語(yǔ)

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

審核編輯 黃宇