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

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

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

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

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

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

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

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

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

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

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

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

3.1 質(zhì)量

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

3.2 業(yè)務定制能力

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

3.3 成本

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

3.4 網(wǎng)絡安全

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

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

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

5、自建分發(fā)網(wǎng)絡的經(jīng)驗與教訓

5.1 成本

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

5.2 機房節(jié)點選擇

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

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

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

5.4 網(wǎng)絡攻擊

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

5.5 小運營商用戶接入

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

6、小結(jié)

我們在自建CDN或采用商用CDN時，需要結(jié)合質(zhì)量、成本的綜合考量、以及對業(yè)務個性化定制的支持能力來進行綜合評判。