◎賴材棟 張小強(qiáng) 劉 斌

(中國(guó)移動(dòng)通信集團(tuán)陜西有限公司，陜西 西安 710077)

隨著家庭寬帶業(yè)務(wù)的高速發(fā)展，陜西移動(dòng)互聯(lián)網(wǎng)電視用戶規(guī)模已經(jīng)突破600 萬(wàn)，成為傳播紅色能量、弘揚(yáng)主旋律、傳遞疫情防控政策、豐富市民精神文化生活的一支重要力量。移動(dòng)互聯(lián)網(wǎng)電視業(yè)務(wù)隨著規(guī)模和影響力的不斷擴(kuò)大，已經(jīng)成為省內(nèi)乃至全國(guó)主流的宣傳渠道。如何構(gòu)建全新的互聯(lián)網(wǎng)電視視頻直播業(yè)務(wù)發(fā)展模式，保障互聯(lián)網(wǎng)電視視頻直播業(yè)務(wù)低延遲、高品質(zhì)、優(yōu)體驗(yàn)，成為互聯(lián)網(wǎng)電視從業(yè)人員需要關(guān)注的重大課題。

在多媒體領(lǐng)域技術(shù)盛會(huì)——LiveVideoStackCon 音視頻技術(shù)大會(huì)上，阿里云的高級(jí)技術(shù)專家進(jìn)行了下一代低延時(shí)的直播CDN 技術(shù)分享[1]，從當(dāng)下直播技術(shù)回顧、低延時(shí)直播技術(shù)思考、低延時(shí)直播技術(shù)實(shí)現(xiàn)、直播業(yè)務(wù)未來(lái)展望四個(gè)部分展開，對(duì)直播CDN 相關(guān)從業(yè)者有一定的幫助和啟發(fā)。

陜西移動(dòng)結(jié)合互聯(lián)網(wǎng)電視系統(tǒng)業(yè)務(wù)構(gòu)架及CDN 直播業(yè)務(wù)發(fā)展需求，提出了OTTx 直播業(yè)務(wù)模式改造方案。OTTx業(yè)務(wù)是一種新的互聯(lián)網(wǎng)電視形態(tài)，直播采用組播技術(shù)，在節(jié)省項(xiàng)目投資預(yù)算和提升用戶體驗(yàn)方面具有非常明顯的競(jìng)爭(zhēng)優(yōu)勢(shì)。為保障OTTx 業(yè)務(wù)的安全平穩(wěn)發(fā)展，互聯(lián)網(wǎng)電視系統(tǒng)優(yōu)化包括MRF、FCC、FEC、探針等各邊緣節(jié)點(diǎn)網(wǎng)絡(luò)設(shè)備及用戶側(cè)的直播頻道音視頻質(zhì)量監(jiān)測(cè)，針對(duì)接入網(wǎng)絡(luò)、傳輸網(wǎng)絡(luò)進(jìn)行整體質(zhì)量提升等，旨在提升移動(dòng)互聯(lián)網(wǎng)整體傳輸網(wǎng)絡(luò)質(zhì)量，保障互聯(lián)網(wǎng)電視視頻內(nèi)容的流暢性、穩(wěn)定性、安全性，為推動(dòng)互聯(lián)網(wǎng)電視業(yè)務(wù)發(fā)展提供可靠基礎(chǔ)，為提升和優(yōu)化互聯(lián)網(wǎng)電視CDN 終端用戶體驗(yàn)滿意度提供堅(jiān)強(qiáng)后盾。

一、直播業(yè)務(wù)發(fā)展歷程

直播業(yè)務(wù)包括多種場(chǎng)景[2]。秀場(chǎng)直播是國(guó)內(nèi)最早出現(xiàn)的直播形式，在各個(gè)直播平臺(tái)比較常見。游戲直播，例如斗魚、虎牙、戰(zhàn)旗等直播平臺(tái)都是比較典型的游戲直播平臺(tái)，游戲直播對(duì)編碼的要求高，同時(shí)在線觀看人數(shù)多，所以它是流量貢獻(xiàn)最大的直播形式。賽事直播，如F1、奧運(yùn)會(huì)、世界杯等對(duì)即時(shí)交互要求不高，所以一般都是HLS 形式，延遲相對(duì)其他場(chǎng)景會(huì)稍微高一點(diǎn)，賽事直播最重要的指標(biāo)是穩(wěn)定性，熱點(diǎn)事件帶來(lái)的帶寬快速增長(zhǎng)、高收視并發(fā)需要CDN 具備足夠的儲(chǔ)備帶寬應(yīng)對(duì)突發(fā)情況，直播全程不能出現(xiàn)任何中斷故障，否則會(huì)影響用戶體驗(yàn)。移動(dòng)直播、短視頻是近兩年井噴式發(fā)展和全民參與的直播形式，其特點(diǎn)是推流和播放比較便捷, 通過手機(jī)APP 就可以進(jìn)行直播，所以手機(jī)直播也是推流數(shù)最多的直播形式，這種直播用戶通過隨機(jī)的封面選擇，對(duì)于不感興趣的直播內(nèi)容，用戶點(diǎn)進(jìn)去觀看不超過幾分鐘就可能退出觀看下一個(gè)，在這樣頻繁地接入和退出操作下，首屏體驗(yàn)感知就變成最重要的指標(biāo)，用戶難以忍受切換慢或起播慢的體驗(yàn)，對(duì)延遲要求高，視頻秒開是客戶非常關(guān)注并評(píng)價(jià)很高的技術(shù)。還有近幾年興起的VR 直播，VR 直播視頻碼率很大，一般在10M/bits，VR 直播主打的就是用戶的視覺沖擊體驗(yàn)，在畫質(zhì)上要保證優(yōu)質(zhì)，在控制清晰度不變的情況下需要降低使用的帶寬，這就涉及到視頻編碼格式。比如h265 編碼格式的視頻帶寬比同清晰度的要低2—3 倍，也就意味著帶寬最少會(huì)降低一半，直播用戶并發(fā)峰值期間對(duì)CDN 出流負(fù)載要求很高，所以對(duì)網(wǎng)絡(luò)質(zhì)量及內(nèi)容源流暢度要求極高，如果觀看流暢度不能保證連續(xù)性，就不能帶來(lái)用戶體驗(yàn)滿意度提升，無(wú)法增強(qiáng)互聯(lián)網(wǎng)電視品牌競(jìng)爭(zhēng)力。

二、低延遲直播需求

國(guó)內(nèi)主要使用HTTP-FLV 和RTMP 這種傳輸形式，這兩種傳輸形式一般延遲在3—5 秒，當(dāng)然延遲時(shí)長(zhǎng)也會(huì)受視頻本身GOP 影響，移動(dòng)直播一般在1—2 秒間隔。游戲直播關(guān)鍵幀延遲一般在8—10 秒，所以游戲直播的延遲更大一些，而賽事活動(dòng)一般不會(huì)強(qiáng)調(diào)互動(dòng)性，對(duì)流暢度要求比較高，所以一般會(huì)選擇HLS，延遲在10 秒左右。

直播業(yè)務(wù)場(chǎng)景下3—5 秒延遲對(duì)于大多數(shù)常見直播形式一般影響不大，但是在某些特定場(chǎng)景下效果不能滿足業(yè)務(wù)需求。如直播連麥場(chǎng)景下延遲造成的影響是最明顯的，連麥延遲超過1 秒，對(duì)話可能就會(huì)出現(xiàn)卡頓甚至掉線；在答題直播場(chǎng)景下，需要參與者在固定時(shí)間內(nèi)完成答題后提交答案，如果出現(xiàn)個(gè)別用戶延遲比較大而不能在固定時(shí)間內(nèi)完成答題并提交，就對(duì)其他用戶不公平。雖然現(xiàn)在大多數(shù)直播平臺(tái)仍然使用FLV 的傳輸形式進(jìn)行答題類直播，但是基本都會(huì)采用SEI 插幀等方法來(lái)解決時(shí)間同步問題，需要平臺(tái)的客戶端和直播CDN 做一些配合來(lái)完成。除了直播連麥場(chǎng)景之外，像在線課堂、在線拍賣等直播場(chǎng)景因?yàn)樯婕暗綄?shí)時(shí)互動(dòng)，對(duì)延時(shí)的要求也比較高。從對(duì)業(yè)務(wù)的支持層面來(lái)看，僅僅有RTMP、FLV 這種3—5 秒延時(shí)以上的直播形式已經(jīng)不能滿足客戶對(duì)流暢度的需求, 需要對(duì)更低延遲的直播業(yè)務(wù)場(chǎng)景進(jìn)行支持。

三、技術(shù)選型的思考

技術(shù)選型首先必須要兼容已有直播業(yè)務(wù)和技術(shù)棧，因?yàn)橹辈DN 系統(tǒng)已經(jīng)承載了很多用戶，短延時(shí)直播需要從現(xiàn)有直播的業(yè)務(wù)基礎(chǔ)上逐步衍生, 可以讓客戶在短延時(shí)和常規(guī)直播手段間進(jìn)行切換，這也是基于現(xiàn)網(wǎng)業(yè)務(wù)穩(wěn)定性的考慮。對(duì)于直播業(yè)務(wù)來(lái)講，視頻秒開和卡頓率是非常重要的業(yè)務(wù)指標(biāo)。

傳統(tǒng)CDN 業(yè)務(wù)場(chǎng)景，無(wú)論是圖片、大小文件、點(diǎn)播、直播等業(yè)務(wù)，都是在TCP 協(xié)議通信基礎(chǔ)上實(shí)現(xiàn)的，所以短延時(shí)直播在研究初期就思考使用TCP 協(xié)議的可能性。我們對(duì)于短延時(shí)的目標(biāo)定義為從端到端延遲在800 毫秒以內(nèi)，例如一場(chǎng)直播的延遲主要包括推流端延遲、CDN 延遲、播放端延遲這三個(gè)方面，很多客戶會(huì)關(guān)注CDN 延遲，通過實(shí)際收集相關(guān)延遲數(shù)據(jù)分析，CDN 從入流到出流整個(gè)業(yè)務(wù)流程所產(chǎn)生的總延時(shí)全網(wǎng)平均不超過100 毫秒，晚高峰期間平均也不超過200 毫秒。而從業(yè)務(wù)系統(tǒng)維護(hù)經(jīng)驗(yàn)角度來(lái)分析，播放端的延遲會(huì)比較嚴(yán)重，主要包括兩方面，一方面是開播時(shí)卡前一個(gè)關(guān)鍵幀所帶來(lái)的延遲，另一方面如果CDN 服務(wù)器到播放端之間網(wǎng)絡(luò)有抖動(dòng)，累積的延遲會(huì)越來(lái)越多。所以我們就可以得出這樣的結(jié)論，在網(wǎng)絡(luò)正常的情況下使用現(xiàn)有的RTMP、HTTP-FLV 進(jìn)行分發(fā)，延遲也基本可以做到控制在1 秒以內(nèi)。但是現(xiàn)實(shí)情況是網(wǎng)絡(luò)不可能出現(xiàn)不丟包的情況。當(dāng)網(wǎng)絡(luò)抖動(dòng)丟包導(dǎo)致卡頓等質(zhì)差時(shí)，TCP 協(xié)議能提供可靠的數(shù)據(jù)傳輸服務(wù)。為保證數(shù)據(jù)傳輸?shù)恼_性，TCP 會(huì)重傳其認(rèn)為已丟失的報(bào)文，TCP 協(xié)議通過ACK 確認(rèn)機(jī)制，也就是說發(fā)送方發(fā)送一個(gè)數(shù)據(jù)包報(bào)文之后，一定要收到對(duì)方應(yīng)答才會(huì)繼續(xù)發(fā)送。如果傳輸網(wǎng)絡(luò)由于質(zhì)差出現(xiàn)丟包，就會(huì)在一個(gè)RTO 之后重傳，RTO 的值和RTT 有關(guān)，并且RTO 的最小值是200ms。如果想保證流暢性，播放端一定要至少能容忍200ms 以上的抖動(dòng)，但播放端的jitbuffer 太多又無(wú)法滿足低延時(shí)的要求。

使用TCP 傳輸時(shí)無(wú)效傳輸無(wú)法避免。TCP 是采用socket buffer 進(jìn)行通信，數(shù)據(jù)也是從應(yīng)用層先進(jìn)入socket buffer 再分發(fā)。對(duì)于RTMP 或FLV 的分發(fā)來(lái)說，假如某一幀數(shù)據(jù)的一部分已經(jīng)進(jìn)入了socket 緩沖區(qū)，那么就必須將這一幀剩余的數(shù)據(jù)發(fā)送出去，如果剩余的數(shù)據(jù)傳輸時(shí)出現(xiàn)擁塞等無(wú)法發(fā)送，播放端會(huì)解析錯(cuò)誤斷開連接造成用戶體驗(yàn)會(huì)非常差。而網(wǎng)絡(luò)在出現(xiàn)波動(dòng)的時(shí)候，有可能socket buffer 里面的數(shù)據(jù)需要多次重傳才能傳送到播放端, 而在短延時(shí)直播的場(chǎng)景下，這些socket buffer 里面和應(yīng)用層過期的數(shù)據(jù)再發(fā)送給播放端已經(jīng)沒有意義，也就是說會(huì)產(chǎn)生很多無(wú)效的傳輸。

近些年發(fā)展起來(lái)的WebRTC 協(xié)議，能夠?qū)崿F(xiàn)亞秒級(jí)的延遲，它并不是通過分塊傳輸降低延遲，使用的是UDP/IP協(xié)議傳輸，提供了在Web、iOS、Android、Mac、Windows、Linux 等所有平臺(tái)的API，保證了API 在所有平臺(tái)的一致性，而且大多數(shù)的瀏覽器均支持，不需要額外的插件，支持自適應(yīng)比特流的傳輸來(lái)適應(yīng)復(fù)雜的網(wǎng)絡(luò)狀況。

因?yàn)閃ebRTC 在移動(dòng)端擁塞控制和重傳方面有部分技術(shù)優(yōu)化，卡頓率方面不會(huì)比TCP 差，所以技術(shù)選型對(duì)齊到WebRTC 會(huì)是最終的結(jié)果, 畢竟用戶能夠使用H5 就可以直接推流或者觀看直播, 能夠提高用戶的接受度和使用率。完整地支持WebRTC 要解決加解密、打洞、音頻格式等問題，所以前期考慮只使用WebRTC 中的一部分技術(shù)，完整支持WebRTC 會(huì)是后期的長(zhǎng)遠(yuǎn)工作規(guī)劃。

這里對(duì)比一下WebRTC 中RTP 傳輸使用的NACK 機(jī)制，NACK 的丟包反饋更加及時(shí)，如果網(wǎng)絡(luò)偶然性抖動(dòng)較多時(shí)，NACK 機(jī)制效果會(huì)更好。通過統(tǒng)計(jì)網(wǎng)絡(luò)數(shù)據(jù)分析，全網(wǎng)平均RTT 小于15ms，如果CDN 節(jié)點(diǎn)覆蓋足夠好的情況下，延遲理論上會(huì)非常低。以1.5Mbps 碼率的音視頻流舉例，每秒鐘100 個(gè)數(shù)據(jù)包，包和包之間就是10ms 的間隔。如果第二個(gè)丟包出現(xiàn)的時(shí)候，第三個(gè)包對(duì)方接收到了，就可以立即知道第二個(gè)包是丟掉了，然后立刻返回一個(gè)NACK 進(jìn)行重傳。在這種極限場(chǎng)景下重傳間隔就是25ms，相比之前TCP 的200ms 重傳延遲是一個(gè)質(zhì)的提升，不再需要通過服務(wù)器進(jìn)行路由，減少了延遲和帶寬消耗，實(shí)現(xiàn)直接通信可提高數(shù)據(jù)傳輸和文件共享的速度。

四、應(yīng)用實(shí)踐

(一)解決端口問題

標(biāo)準(zhǔn)WebRTC 的建連流程，最簡(jiǎn)單的服務(wù)器端端口方案是我們可以為每個(gè)客戶端分配一個(gè)端口，服務(wù)器端上使用這個(gè)端口區(qū)分每個(gè)用戶。那么多端口有什么不足呢？很多的網(wǎng)絡(luò)出口防火墻對(duì)能夠通過的UDP 端口是有限制的；對(duì)于服務(wù)器端來(lái)說開辟這么多端口，安全性也有一定的問題；開辟這么多的端口在Server 端上，端口的開銷和性能均有一定的影響。那能否用單端口？首先要解決的一個(gè)問題是：如何區(qū)分每一個(gè)RTP/RTCP 包是屬于哪一個(gè)WebRTC 客戶端。WebRTC 在服務(wù)器SDP Answer 中設(shè)置 ice-ufrag 為roomid/userid，其中RoomID 和UserID 是通話業(yè)務(wù)層分配的內(nèi)容，用于區(qū)分會(huì)話連接以及客戶端。接著做Ice candidate 協(xié)商，客戶端開始做連通性檢測(cè)，也就是stun binding request 里的USERNAME 為SDP local 和remote 的ice-ufrag 指定內(nèi)容。服務(wù)器收到stun binding request 的客戶端ip 和端口，并正?；豷tun binding response。記錄客戶端地址與用戶信息的映射關(guān)系。服務(wù)器收到一個(gè)rtp/rtcp 媒體數(shù)據(jù)包，通過包的源ip 和端口，查詢映射表就可以識(shí)別這個(gè)包屬于哪個(gè)用戶。

(二)視頻秒開

秒開是指用戶點(diǎn)擊播放到看到畫面的時(shí)間非常短，在1秒之內(nèi)。實(shí)現(xiàn)視頻秒開是基于GOP 的視頻緩存策略實(shí)現(xiàn)的。例如RTC 交流場(chǎng)景下，可直接通過PLI 交流，向發(fā)布端索要關(guān)鍵幀，對(duì)于接收端立即完成視頻渲染。但是對(duì)于直播CDN 場(chǎng)景，海量的客戶端向服務(wù)器端索要PLI 是不現(xiàn)實(shí)的。為了解決這個(gè)問題，服務(wù)器端需要加入Gop Cache 數(shù)據(jù)結(jié)構(gòu)，構(gòu)建基于Gop 的緩存結(jié)構(gòu)。在低延遲直播的情況下，需要考慮在Gop 下發(fā)后客戶端能夠快速追上服務(wù)端的發(fā)流，所以在客戶端感知不明顯的情況下會(huì)對(duì)P 禎和B 禎采用1.1 或1.2倍速下發(fā)，直到所有包能夠追上服務(wù)端下推包的進(jìn)程，后續(xù)在合流完成后的整體時(shí)間即可同步，延遲會(huì)降到最低。

(三)RTP 報(bào)文

RTP 數(shù)據(jù)包中，PT 字段是載荷類型，sequence number是包序列號(hào)，發(fā)送端切片的時(shí)候?qū)懞眯蛄刑?hào)，接收端依據(jù)這個(gè)序列號(hào)進(jìn)行數(shù)據(jù)的還原。而且在數(shù)據(jù)報(bào)文發(fā)生重傳的時(shí)候，還依靠這個(gè)序列號(hào)進(jìn)行NACK 的返回。同時(shí)，時(shí)間戳對(duì)流媒體傳輸非常重要，播放器依賴它進(jìn)行解碼和同步。SSRC 用來(lái)識(shí)別不同的身份，同一個(gè)IP 和端口被NAT 重新分配的時(shí)候，SSRC 能夠識(shí)別出這是一個(gè)不同的連接。

以H264 為例[3]，RTP 在封裝的時(shí)候，如果NAL 單元小于MTU，那么我們認(rèn)為一個(gè)RTP 包可以完整封裝一個(gè)NAL單元，如果出現(xiàn)丟幀，那么我們認(rèn)為缺少的是一個(gè)完整的NAL 單元，對(duì)后面NAL 單元的解析不會(huì)出現(xiàn)數(shù)據(jù)錯(cuò)亂。如果一個(gè)NAL 單元大于一個(gè)MTU 的時(shí)候，假設(shè)一個(gè)NAL 單元需要三個(gè)RTP 包封裝，不管丟掉部分還是全部丟掉，接收端都可以標(biāo)識(shí)出這個(gè)NAL 單元，不會(huì)影響其他NAL 單元的解析。所以采用RPT 報(bào)文是可以滿足設(shè)想需求的。

(四)平滑發(fā)送機(jī)制

現(xiàn)在通常采用的混合擁塞算法，基于丟包率和延遲進(jìn)行碼率控制。標(biāo)準(zhǔn)的方案是當(dāng)播放端卡頓時(shí)，發(fā)送端碼率會(huì)降低。當(dāng)推流端上行網(wǎng)絡(luò)出現(xiàn)抖動(dòng)的時(shí)候，CDN 服務(wù)器返回?cái)?shù)據(jù)包通知推流端把碼率降下來(lái)。當(dāng)播放端下行網(wǎng)絡(luò)出現(xiàn)抖動(dòng)的時(shí)候，一種是輸出轉(zhuǎn)碼視頻流，另一種是讓推流端推兩路視頻流，提醒播放卡頓的用戶切換到低碼率。

陜西移動(dòng)互聯(lián)網(wǎng)電視系統(tǒng)結(jié)合當(dāng)前業(yè)務(wù)平臺(tái)系統(tǒng)現(xiàn)狀，分析CDN 服務(wù)器使用的擁塞控制算法取決于sysctl 接口的net.ipv4.tcp_congestion_control。缺省的擁塞控制算法是最后注冊(cè)的算法(LIFO),如果全部編譯成模塊，則將使用reno 算法，如果使用缺省的Kconfig 配置，CUBIC 算法將編譯進(jìn)內(nèi)核，并且內(nèi)核將使用CUBIC 作為默認(rèn)的擁塞控制算法，CUBIC 擁塞控制基礎(chǔ)[4]提升優(yōu)化TCP 快速重傳算法net.ipv4.tcp_congestion_control = cubic，在快速重傳丟失的數(shù)據(jù)包后啟用擁塞避免算法，而不是慢啟動(dòng)算法被調(diào)用，這就是快速恢復(fù)的意義。這一方法使得在中度擁塞的情況下CDN 服務(wù)器能有較高的吞吐率，達(dá)到優(yōu)化出流效率的目的，最終提升終端用戶的體驗(yàn)感和滿意度。

(五)FEC 冗余傳輸

FEC 是通過數(shù)據(jù)報(bào)文冗余傳輸來(lái)提高容錯(cuò)率。關(guān)鍵幀10%冗余率，非關(guān)鍵幀5%，根據(jù)丟包率判斷網(wǎng)絡(luò)狀況，動(dòng)態(tài)調(diào)整冗余度?，F(xiàn)在H264 和AAC 數(shù)據(jù)會(huì)在內(nèi)部先進(jìn)行切片，放到平滑發(fā)送隊(duì)列再發(fā)送給播放端，同時(shí)重傳包也會(huì)進(jìn)入平滑發(fā)送隊(duì)列，并且會(huì)放到平滑發(fā)送隊(duì)列的隊(duì)首位置，完成數(shù)據(jù)報(bào)文冗余傳輸。

陜西移動(dòng)互聯(lián)網(wǎng)電視系統(tǒng)OTTx 業(yè)務(wù)是使用華為MRF 編碼[5]，在中轉(zhuǎn)過程中采用RTP 協(xié)議封裝組播流，生成FEC冗余流，使用戶在終端獲得更流暢的播放體驗(yàn)。FEC 采用帶外承載方式，與組播組使用同一個(gè)IP 地址，以UDP 端口區(qū)分原始組播流和FEC 冗余流，默認(rèn)端口為組播端口減1，播放端獲取的頻道列表信息中有指定的FEC 端口，則必須采用指定端口。FEC 算法采用移動(dòng)集團(tuán)規(guī)范，能夠適配組播流任意位置隨機(jī)丟包恢復(fù)業(yè)務(wù)場(chǎng)景，F(xiàn)EC 冗余度不超過5%，對(duì)于1%的隨機(jī)丟包至少要達(dá)到99%以上的恢復(fù)成功率，對(duì)于2%的隨機(jī)丟包至少要達(dá)到95%以上的恢復(fù)成功率。

(六)探測(cè)活動(dòng)

采用RTCP 報(bào)文的方式實(shí)現(xiàn)對(duì)播放和推流連接的斷開進(jìn)行控制。采用TCP 方式傳輸?shù)臅r(shí)候也有類似的問題，推流端發(fā)送了FIN 結(jié)束報(bào)文，但是CDN 服務(wù)器未必收到，所以要有超時(shí)的機(jī)制來(lái)進(jìn)行管理。我們采用數(shù)據(jù)及時(shí)反饋機(jī)制，下行播放端要求周期性返回，上行推流端必須在8—10 秒內(nèi)完成真實(shí)視頻流數(shù)據(jù)傳輸，否則連接就會(huì)斷開。

五、結(jié)語(yǔ)

對(duì)于CDN 低延遲優(yōu)化要做的另一個(gè)關(guān)鍵點(diǎn)就是優(yōu)化傳輸，其實(shí)無(wú)論對(duì)于文件加速還是流媒體加速，傳輸永遠(yuǎn)都是最重要的環(huán)節(jié)，CDN 這個(gè)分發(fā)網(wǎng)絡(luò)質(zhì)量提升本身就是為了優(yōu)化傳輸而存在的。

完整地支持WebRTC 一定是下一階段實(shí)現(xiàn)的目標(biāo), 畢竟直接通過瀏覽器就可以完成推流和播放，對(duì)于用戶端的接入便捷性有質(zhì)的提升，對(duì)于CDN 來(lái)說，控制接入一定是最重要且必須做的事情。