在選擇自建CDN或者商用CDN時(shí)，需要結(jié)合業(yè)務(wù)實(shí)踐，從成本、質(zhì)量、業(yè)務(wù)定制化能力等維度進(jìn)行綜合評(píng)判。本文來自歡聚時(shí)代直播部負(fù)責(zé)人林正顯在LiveVideoStackCon 2017大會(huì)上的分享，并由LiveVideoStack整理而成。

大家好，我是來自歡聚時(shí)代的林正顯。今天主要為大家分享的是自建或商用CDN的選擇與發(fā)展。

以下是本次分享的內(nèi)容大綱，我將會(huì)從這幾個(gè)方面分享過去的一些開發(fā)經(jīng)驗(yàn)與體會(huì)。

1、YY分發(fā)網(wǎng)絡(luò)的發(fā)展歷史

YY語音成立于2008年，初期主要是借助團(tuán)隊(duì)語音網(wǎng)絡(luò)向游戲團(tuán)戰(zhàn)用戶提供語音多播服務(wù)。起初實(shí)現(xiàn)的是應(yīng)用層多播(ALM)，其特點(diǎn)是頻道(房間)高度分散化，一個(gè)頻道對(duì)應(yīng)一個(gè)多播組。而同頻道內(nèi)不同用戶分布在不同地域，不同運(yùn)營(yíng)商下。此時(shí)我們的主要任務(wù)是基于運(yùn)營(yíng)商網(wǎng)絡(luò)開發(fā)一層封裝并在其上疊加一個(gè)自己的分發(fā)網(wǎng)絡(luò)而非基于IP多播。大家知道運(yùn)營(yíng)商對(duì)IP多播有諸多限制，且IP多播無法保證傳輸?shù)目煽啃?。但由于頻道分散化與多個(gè)地域運(yùn)營(yíng)商等問題，保證強(qiáng)語音實(shí)時(shí)交互必定需要做出很多努力;根據(jù)ITU標(biāo)準(zhǔn)，大于四百毫秒的延時(shí)體驗(yàn)顯然是不及格的，我們期待將延時(shí)控制在較為理想的兩百毫秒以內(nèi)，由此需要解決的挑戰(zhàn)有跨運(yùn)營(yíng)商的通訊問題、傳輸與分發(fā)延時(shí)問題和通信成本問題。

每個(gè)運(yùn)營(yíng)商都會(huì)布局自家服務(wù)器，而服務(wù)器之間的聯(lián)絡(luò)依靠運(yùn)營(yíng)商線路直連。這里需要解決的問題是，一些情況下一個(gè)頻道可能只有幾個(gè)人且分布在不同運(yùn)營(yíng)商;如果為了保證幾個(gè)人的服務(wù)調(diào)用多臺(tái)服務(wù)器，此時(shí)服務(wù)器之間的轉(zhuǎn)發(fā)量可能大于下發(fā)量。不僅使成本激增，也難以保證數(shù)據(jù)在不同運(yùn)營(yíng)商之間傳輸?shù)馁|(zhì)量，可能會(huì)出現(xiàn)高達(dá)百分之幾十的丟包。為了改變這種成本與質(zhì)量的雙重壓力，我們需要對(duì)其作出進(jìn)一步優(yōu)化。

大約在2011年，我們就面臨著有關(guān)視頻分發(fā)的需求，當(dāng)時(shí)為了快速實(shí)現(xiàn)秀場(chǎng)直播與游戲直播的產(chǎn)品形式，我們使用了一種現(xiàn)在看來問題明顯的架構(gòu)，也就是單獨(dú)搭建一個(gè)視頻分發(fā)網(wǎng)絡(luò)。這樣能夠確保音頻的優(yōu)先級(jí)，保證音頻業(yè)務(wù)的質(zhì)量和穩(wěn)定性，并趕上視頻直播的時(shí)間點(diǎn)需求，但由于當(dāng)時(shí)采取音視頻分開上傳的方案，客戶端的音視頻同步成為一個(gè)難以解決的問題。

此后我們出于成本和質(zhì)量的雙重考慮，對(duì)分發(fā)系統(tǒng)進(jìn)行了兩大改進(jìn)：一是基于Overlay+智能路由網(wǎng)絡(luò)，搭建一個(gè)“網(wǎng)中網(wǎng)”并對(duì)線路算法進(jìn)行改進(jìn)，從而實(shí)現(xiàn)多級(jí)中繼的自適應(yīng)算法;二是引入P2P，從而在保證數(shù)據(jù)傳輸質(zhì)量的同時(shí)有效降低成本。

2、YY分發(fā)網(wǎng)絡(luò)的發(fā)展現(xiàn)狀

YY分發(fā)網(wǎng)絡(luò)發(fā)展到現(xiàn)在，其本質(zhì)是一個(gè)規(guī)模龐大的實(shí)時(shí)多播網(wǎng)絡(luò)。傳輸對(duì)延時(shí)的影響較小，而終端編解碼、去抖動(dòng)等環(huán)節(jié)對(duì)延時(shí)的影響則更明顯。根據(jù)2011年的數(shù)據(jù)，我們的全網(wǎng)平均傳輸延時(shí)僅為74毫秒，基于此網(wǎng)絡(luò)，我們支持了很多實(shí)時(shí)業(yè)務(wù)如游戲語音、狼人殺、多人音視頻會(huì)話等等。而對(duì)秀場(chǎng)的支持主要通過增大緩沖來實(shí)現(xiàn)。當(dāng)然，現(xiàn)有的YY網(wǎng)絡(luò)中純音頻分發(fā)用戶仍然占很大比例，基于團(tuán)隊(duì)語音的團(tuán)戰(zhàn)場(chǎng)景較為普遍。即使我們正在實(shí)現(xiàn)音視頻分發(fā)網(wǎng)絡(luò)的逐漸融合，但音頻優(yōu)先級(jí)仍然是需要我們保證的。

3、自建與商用的多維度考量

介紹完YY分發(fā)網(wǎng)絡(luò)的發(fā)展歷史，下面我想談一下自建與商用的考量維度。在選擇自建或商用分發(fā)網(wǎng)絡(luò)時(shí)我們主要從以上四個(gè)維度考量：質(zhì)量是分發(fā)網(wǎng)絡(luò)需要保證的首要條件;而業(yè)務(wù)定制能力主要為滿足客戶的個(gè)性化業(yè)務(wù)定制需求，如果CDN無法支持那么就需要我們自己構(gòu)建，隨之而來的大量成本投入顯然不是我們期待的結(jié)果;緊接著的成本問題與安全問題也是需要我們重點(diǎn)考量的維度，不容忽視。

3.1 質(zhì)量

卡頓率與延時(shí)是我們考量質(zhì)量維度時(shí)最重要的兩個(gè)參數(shù)。前者是指觀眾看不到視頻或聽不到聲音的比例，后者是打開視頻直播的速度。YY對(duì)卡頓率的定義和一般CDN廠商的定義有些許不同，我們以5分鐘作為統(tǒng)計(jì)周期，如果在此周期內(nèi)產(chǎn)生卡頓則定義此用戶為壞用戶;將一個(gè)周期內(nèi)的壞用戶數(shù)與此周期內(nèi)所有種子用戶數(shù)的比值定義為卡頓率，我們一直借助這樣一個(gè)十分苛刻的指標(biāo)衡量整個(gè)YY網(wǎng)絡(luò)質(zhì)量的好壞。而由于YY有大量的業(yè)務(wù)場(chǎng)景是連麥互動(dòng)，我們對(duì)延時(shí)的統(tǒng)計(jì)包括兩部分：主播與主播之間的延時(shí)和主播與觀眾之間的延時(shí)。主播與觀眾的傳輸處理基本一致，主要區(qū)別在于觀眾的抖動(dòng)緩沖更長(zhǎng)。

3.2 業(yè)務(wù)定制能力

第二個(gè)我們遇見的比較麻煩的問題是業(yè)務(wù)定制能力。與一般的由CDN純文件分發(fā)切入的直播方案不同，YY通過實(shí)時(shí)多播系統(tǒng)切入直播。我們沒有對(duì)RTMP或FLV的種種系統(tǒng)邊界限定，業(yè)務(wù)場(chǎng)景也是千奇百怪。例如直播抓娃娃，用戶通過手機(jī)控制抓娃娃機(jī)，通過直播畫面確定爪子位置。一般在此應(yīng)用場(chǎng)景中我們需要控制從開始點(diǎn)擊到圖像傳遞到客戶端的延時(shí)不超過三百毫秒，并且希望用戶抓到娃娃后在娃娃機(jī)端同步反饋一個(gè)用于確認(rèn)抓取結(jié)果的狀態(tài)碼，同時(shí)保證此狀態(tài)碼的送達(dá)與直播畫面的同步性,如果系統(tǒng)顯示抓取成功而直播畫面還停留在抓取階段無疑是體驗(yàn)糟糕的。這種實(shí)時(shí)交互的場(chǎng)景在我們的核心業(yè)務(wù)中占比很大，提升此類場(chǎng)景用戶體驗(yàn)的關(guān)鍵是確?？刂屏骱兔襟w流之間的配合與同步，如在AI地圖場(chǎng)景中主播走到的位置與地圖呈現(xiàn)給觀眾的位置必須同步且統(tǒng)一，而向左或向右走的指示也需準(zhǔn)確無誤。總體而言，YY的這些玩法較少見于以CDN為基礎(chǔ)的較為大眾化領(lǐng)域，這就導(dǎo)致當(dāng)我們嘗試將系統(tǒng)遷至CDN時(shí)無法尋找到一個(gè)較為優(yōu)質(zhì)的解決方案。例如在過去的嘗試中我們發(fā)現(xiàn)，CDN推的一路視頻流難以與經(jīng)由我們自己信令網(wǎng)絡(luò)傳輸?shù)目刂屏魍?或者面對(duì)在YY較為普遍的多人連麥實(shí)時(shí)語音應(yīng)用場(chǎng)景，當(dāng)直播間內(nèi)用戶同時(shí)進(jìn)行發(fā)言時(shí)，CDN無法將同步顯示每一個(gè)人的發(fā)言狀態(tài)與混合多路語音的直播數(shù)據(jù)一起推給觀眾?？梢哉f，簡(jiǎn)單的CDN無法滿足我們的業(yè)務(wù)需求。

3.3 成本

想必對(duì)任何一家公司而言，成本都是無法逃避的關(guān)鍵命題。由于我們的整體業(yè)務(wù)較為單一，自建分發(fā)網(wǎng)絡(luò)的帶寬利用率偏低，實(shí)際應(yīng)用中主要表現(xiàn)在白天流量處于低谷而晚上流量處于高峰;除此之外在2012年我們探索P2P時(shí)發(fā)現(xiàn)，國(guó)內(nèi)用戶的上行帶寬遠(yuǎn)低于下行帶寬，全國(guó)人均上行帶寬為1～2mbps。如果一個(gè)視頻流的碼率高達(dá)8～9mbps，即便我們把用戶上行帶寬都榨光，也沒法支撐全部流量。上行帶寬有限的時(shí)候，碼率越高，P2P的節(jié)省率越低。早期探索CDN時(shí)我們也犯了不少錯(cuò)誤，例如開發(fā)第一版產(chǎn)品時(shí)我們將服務(wù)于主播的資源與服務(wù)于觀眾的資源混為一談，相比于單純使用CDN做觀眾流的分發(fā)，前者算出來的單用戶成本偏高。我們需要將網(wǎng)絡(luò)成本分為主播端網(wǎng)絡(luò)成本和觀眾端網(wǎng)絡(luò)成本;對(duì)主播網(wǎng)絡(luò)而言由于轉(zhuǎn)碼、私有協(xié)議、HLS等都在主播端確定，其成本遠(yuǎn)高于觀眾端。除此之外我們也會(huì)考量每MB成本與每用戶成本，如果以前者作為標(biāo)準(zhǔn)那么YY的成本計(jì)算值偏高，因?yàn)樾枰?jì)算IDC、寬帶、CDN等的采購(gòu)成本;而如果以每個(gè)用戶的成本作為標(biāo)準(zhǔn)那么一個(gè)2MB的下行視頻僅需800K流量，其余數(shù)據(jù)則通過P2P，我們應(yīng)當(dāng)以每用戶成本作為標(biāo)準(zhǔn)進(jìn)行成本計(jì)算。除此之外，我們還發(fā)現(xiàn)，當(dāng)通過YY網(wǎng)絡(luò)將同一條流推送到不同的CDN，并讓各CDN給出每個(gè)用戶的下行流量時(shí)，其結(jié)果是有一定差距的，大家在進(jìn)行成本計(jì)算時(shí)需要注意這一事項(xiàng)。

3.4 網(wǎng)絡(luò)安全

安全問題不容忽視。根據(jù)上圖我們可以看到自建機(jī)房受到的攻擊的數(shù)量之多，類型之復(fù)雜觸目驚心。其中syn攻擊與UDP攻擊的數(shù)量很大。在服務(wù)前期由于沒有對(duì)整個(gè)網(wǎng)絡(luò)進(jìn)行很好的保護(hù)，服務(wù)質(zhì)量得不到很好的保障。

4、YY分發(fā)網(wǎng)絡(luò)的后續(xù)計(jì)劃

我們的后續(xù)計(jì)劃是在邏輯上將網(wǎng)絡(luò)分割成主播網(wǎng)與觀眾網(wǎng)，主播連接到主播分發(fā)網(wǎng)并接入互動(dòng)的數(shù)據(jù);隨后直播音視頻數(shù)據(jù)通過一個(gè)可選的內(nèi)容處理平臺(tái)進(jìn)行轉(zhuǎn)碼、超分辨率、廣告插入等處理后再推至我們自建的觀眾分發(fā)網(wǎng)絡(luò)或商用CDN，使得服務(wù)能夠從容應(yīng)對(duì)流量短時(shí)間激增的突發(fā)狀況。我們顯然不能單純地為了應(yīng)對(duì)突發(fā)流量而時(shí)時(shí)刻刻維護(hù)一個(gè)規(guī)模龐大的自建網(wǎng)絡(luò)，使用CDN作為預(yù)備擴(kuò)容的臨時(shí)服務(wù)器可以合理的成本從容應(yīng)對(duì)流量激增風(fēng)險(xiǎn)。除此之外，兩個(gè)邏輯網(wǎng)絡(luò)的維護(hù)與升級(jí)互相不影響，便利性更佳，有效避免觀眾分發(fā)網(wǎng)絡(luò)的版本更新可能會(huì)為主播端帶來的不利影響。當(dāng)然此方案也有一定壞處，其一是從觀眾切到主播的體驗(yàn)尚待進(jìn)一步優(yōu)化，其二是多視頻流的直播間推到CDN時(shí)，混流導(dǎo)致視頻質(zhì)量下降，且用戶難以單獨(dú)屏蔽單條流。對(duì)于現(xiàn)在的多主播連麥直播，數(shù)據(jù)通過多條未混合的流傳輸給觀眾，因?yàn)楹狭?、混流等?huì)導(dǎo)致媒體質(zhì)量的下降。由此我們一直堅(jiān)持多主播上行多條流下行的架構(gòu)，而這在CDN是無法實(shí)現(xiàn)的，如果不進(jìn)行混流操作就貿(mào)然使用CDN那么多條流的同步是十分糟糕的。

5、自建分發(fā)網(wǎng)絡(luò)的經(jīng)驗(yàn)與教訓(xùn)

5.1 成本

成本是一個(gè)永遠(yuǎn)繞不開的話題，也是我們除了質(zhì)量最多考量的維度。我們可通過借助一些高效的音視頻編解碼方案在保證質(zhì)量的同時(shí)顯著控制成本，可通過使用更高效的音視頻編解碼解決方案如用H.265代替H.264，也可通過使用P2P或多業(yè)務(wù)互補(bǔ)從而提高業(yè)務(wù)帶寬利用率等。除了以上的通用解決方案，在觀眾端的一些優(yōu)化例如通過人工智能深度學(xué)習(xí)等技術(shù)將低分辨率視頻轉(zhuǎn)換成高分辨率視頻的超采樣分辨率技術(shù)或阿里正在探索的基于主觀視覺感受的窄帶高清編碼等。自建網(wǎng)絡(luò)存在一個(gè)邊際成本問題，也就是隨著自建網(wǎng)絡(luò)規(guī)模的增大，每個(gè)用戶的成本會(huì)隨之降低。如果自有流量未達(dá)到500G～1T的水平則很難控制自建網(wǎng)絡(luò)的成本，只有高于此水平才能有效平衡成本與其他要素的關(guān)系。我想對(duì)于包括YY在內(nèi)的任何一家企業(yè)而言，質(zhì)量第一，成本第二。我們期待的是使用可以控制的合理投入實(shí)現(xiàn)延時(shí)與卡頓率更低的高質(zhì)量音視頻傳播技術(shù)保障。

5.2 機(jī)房節(jié)點(diǎn)選擇

機(jī)房節(jié)點(diǎn)選擇問題非常關(guān)鍵。YY的機(jī)房并非集中化部署而是分布在全國(guó)各地，集中化部署服務(wù)器的好處在于有效減少機(jī)房之間的通訊流量，但數(shù)據(jù)傳輸質(zhì)量肯定是無法得到有效保證;而如果服務(wù)器部署過于分散，服務(wù)器分布在每個(gè)城市甚至每個(gè)小區(qū)，那么服務(wù)器間的通訊流量就會(huì)非常大并導(dǎo)致整體成本的進(jìn)一步提升。我們需要盡可能避免這兩種極端，也就是采取同省、同市接近用戶部署的策略從而在控制機(jī)房間流量的同時(shí)保證接入的質(zhì)量。我們盡可能以較為合適的密度在全國(guó)各地布置機(jī)房節(jié)點(diǎn)，并在機(jī)房落地前進(jìn)行包括丟包、延時(shí)在內(nèi)的嚴(yán)苛質(zhì)量測(cè)試，以及上線之后對(duì)機(jī)房節(jié)點(diǎn)進(jìn)行持續(xù)監(jiān)控并統(tǒng)計(jì)質(zhì)量數(shù)據(jù)的變化。有時(shí)某個(gè)機(jī)房會(huì)出現(xiàn)測(cè)試性能優(yōu)良而在投入使用后出現(xiàn)很多問題的現(xiàn)象，這仍待我們進(jìn)一步優(yōu)化。早期YY選擇IDC時(shí)IDC將我們的帶寬與其他業(yè)務(wù)帶寬混在一起，由于和其他客戶共用帶寬，帶寬資源受到限制，一旦出現(xiàn)流量激增則傳輸質(zhì)量無法得到保證。隨著YY的業(yè)務(wù)日漸壯大我們淘汰了質(zhì)量不佳的IDC，這也是我們?cè)谝酝鶎?shí)踐探索時(shí)收獲到的教訓(xùn)。

5.3 網(wǎng)絡(luò)容量規(guī)劃

第三個(gè)需要強(qiáng)調(diào)的是網(wǎng)絡(luò)容量規(guī)劃問題。我們需要妥善處理業(yè)務(wù)的需求起落帶來的網(wǎng)絡(luò)流量伸縮問題，在彈性和成本之間保持動(dòng)態(tài)平衡。如果使用完全自建的分發(fā)網(wǎng)絡(luò)那么需要流出足夠的緩沖支撐突發(fā)流量，從成本角度考量并不劃算。因而我們思考，能否采用云主機(jī)的服務(wù)形式進(jìn)行彈性部署，從而在確保面對(duì)突發(fā)流量增長(zhǎng)時(shí)整體服務(wù)的穩(wěn)定性的同時(shí)控制服務(wù)器采購(gòu)、上下限的資源成本。除此之外，我們也希望實(shí)現(xiàn)自建平臺(tái)與CDN、多CDN平臺(tái)之間的分擔(dān)與互備，進(jìn)一步確保服務(wù)的穩(wěn)定與可靠。

5.4 網(wǎng)絡(luò)攻擊

網(wǎng)絡(luò)攻擊是一件非常重大的事情。我們單個(gè)機(jī)房曾遭受上百Gbps級(jí)別的流量攻擊以至于機(jī)房癱瘓，這也促成我們建立了包括DDOS攻擊防御在內(nèi)的全方面安全防衛(wèi)系統(tǒng)，此系統(tǒng)對(duì)我們YY整個(gè)業(yè)務(wù)的茁壯成長(zhǎng)起到了至關(guān)重要的作用。對(duì)于自建分發(fā)網(wǎng)絡(luò)而言，安全系統(tǒng)是性命攸關(guān)的。

5.5 小運(yùn)營(yíng)商用戶接入

覆蓋性問題同樣需要我們考慮。對(duì)三大運(yùn)營(yíng)商的覆蓋毋庸置疑，但對(duì)類似于教育網(wǎng)等小運(yùn)營(yíng)商用戶的覆蓋與質(zhì)量保證是需要我們優(yōu)化的。保證小運(yùn)營(yíng)商用戶的服務(wù)體驗(yàn)是一件很大的挑戰(zhàn)，很多小運(yùn)營(yíng)商用戶都是經(jīng)過NAT后再接入大的運(yùn)營(yíng)商網(wǎng)絡(luò)，其連接質(zhì)量就難以獲得保證。我們需要判斷用戶自身所處網(wǎng)絡(luò)屬性，也可使用BGP、多線機(jī)房等進(jìn)行接入;除此之外，自建網(wǎng)絡(luò)時(shí)利用CDN甚至第三方接入也是有可能的，這也是我們正在探索的方向;而為了給海外用戶提供服務(wù)，YY使用公網(wǎng)環(huán)境進(jìn)行傳輸，處理思路與小運(yùn)營(yíng)商接入相似

6、小結(jié)

我們?cè)谧越–DN或采用商用CDN時(shí)，需要結(jié)合質(zhì)量、成本的綜合考量、以及對(duì)業(yè)務(wù)個(gè)性化定制的支持能力來進(jìn)行綜合評(píng)判。