七牛云于 6 月底發(fā)布了一個針對視頻直播的實時流網(wǎng)絡(luò) LiveNet 和完整的直播云解決方案，很多開發(fā)者對這個網(wǎng)絡(luò)和解決方案的細節(jié)和使用場景非常感興趣。

　　結(jié)合七牛實時流網(wǎng)絡(luò) LiveNet 和直播云解決方案的實踐，我們用八篇文章，更系統(tǒng)化地介紹當(dāng)下大熱的視頻直播各環(huán)節(jié)的關(guān)鍵技術(shù)，幫助視頻直播創(chuàng)業(yè)者們更全面、深入地了解視頻直播技術(shù)，更好地技術(shù)選型。

　　本系列文章大綱如下：

　　（一）采集（回復(fù) 0001閱讀采集篇）

　?。ǘ┨幚恚ɑ貜?fù) 0002閱讀處理篇）

　?。ㄈ┚幋a和封裝（回復(fù) 0003閱讀編碼和封裝篇）

　?。ㄋ模┩屏骱蛡鬏?/p>

　?。ㄎ澹┈F(xiàn)代播放器原理

　?。┭舆t優(yōu)化

　?。ㄆ撸㏒DK 性能測試模型

　　在上一期的處理篇中，我們介紹了講解編碼和封裝。 本篇是《解密視頻直播技術(shù)》系列之五：推流和傳輸。推流是直播的第一公里，直播的推流對這個直播鏈路影響非常大，如果推流的網(wǎng)絡(luò)不穩(wěn)定，無論我們?nèi)绾巫鰞?yōu)化，觀眾的體驗都會很糟糕。所以也是我們排查問題的第一步，如何系統(tǒng)地解決這類問題需要我們對相關(guān)理論有基礎(chǔ)的認(rèn)識。

　　推送協(xié)議

　　下面就先介紹一下都有哪些推送協(xié)議，他們在直播領(lǐng)域的現(xiàn)狀和優(yōu)缺點。

RTMP

WebRTC

基于 UDP 的私有協(xié)議

　　1、RTMP

　　RTMP 是 Real Time Messaging Protocol（實時消息傳輸協(xié)議）的首字母縮寫。該協(xié)議基于 TCP，是一個協(xié)議族，包括 RTMP 基本協(xié)議及 RTMPT/RTMPS/RTMPE 等多種變種。RTMP 是一種設(shè)計用來進行實時數(shù)據(jù)通信的網(wǎng)絡(luò)協(xié)議，主要用來在 Flash/AIR 平臺和支持 RTMP 協(xié)議的流媒體/交互服務(wù)器之間進行音視頻和數(shù)據(jù)通信。支持該協(xié)議的軟件包括 Adobe Media Server/Ultrant Media Server/red5 等。

　　RTMP 是目前主流的流媒體傳輸協(xié)議，廣泛用于直播領(lǐng)域，可以說市面上絕大多數(shù)的直播產(chǎn)品都采用了這個協(xié)議。

　　優(yōu)點

CDN 支持良好，主流的 CDN 廠商都支持

協(xié)議簡單，在各平臺上實現(xiàn)容易

　　缺點

基于 TCP ，傳輸成本高，在弱網(wǎng)環(huán)境丟包率高的情況下問題顯著

不支持瀏覽器推送

Adobe 私有協(xié)議，Adobe 已經(jīng)不再更新

　　2、WebRTC

　　WebRTC，名稱源自網(wǎng)頁即時通信（英語：Web Real-Time Communication）的縮寫，是一個支持網(wǎng)頁瀏覽器進行實時語音對話或視頻對話的 API。它于 2011 年 6 月 1 日開源并在 Google、Mozilla、Opera 支持下被納入萬維網(wǎng)聯(lián)盟的 W3C 推薦標(biāo)準(zhǔn)。

　　目前主要應(yīng)用于視頻會議和連麥中，協(xié)議分層如下：

　　優(yōu)點

W3C 標(biāo)準(zhǔn)，主流瀏覽器支持程度高

Google 在背后支撐，并在各平臺有參考實現(xiàn)

底層基于 SRTP 和 UDP，弱網(wǎng)情況優(yōu)化空間大

可以實現(xiàn)點對點通信，通信雙方延時低

　　缺點

ICE,STUN,TURN 傳統(tǒng) CDN 沒有類似的服務(wù)提供

　　3、基于 UDP 的私有協(xié)議

　　有些直播應(yīng)用會使用 UDP 做為底層協(xié)議開發(fā)自己的私有協(xié)議，因為 UDP 在弱網(wǎng)環(huán)境下的優(yōu)勢通過一些定制化的調(diào)優(yōu)可以達到比較好的弱網(wǎng)優(yōu)化效果，但同樣因為是私有協(xié)議也勢必有現(xiàn)實問題：

　　優(yōu)點

更多空間進行定制化優(yōu)化

　　缺點

開發(fā)成本高

CDN 不友好，需要自建 CDN 或者和 CDN 達成協(xié)議

獨立作戰(zhàn)，無法和社區(qū)一起演進

　　傳輸網(wǎng)絡(luò)

　　我們推送出去的流媒體需要傳輸?shù)接^眾，整個鏈路就是傳輸網(wǎng)絡(luò)，類比貨運物流就是從出發(fā)地到目的地見的所有路程了，如果道路的容量不夠，會引發(fā)堵車也就是網(wǎng)絡(luò)擁塞，這時我們會改變路程也就是所謂的智能調(diào)度，但是傳輸網(wǎng)絡(luò)會站在全局的角度進行調(diào)度，所以會比原子世界的調(diào)度有更好的效果，可以想象有一個上帝在天空中俯視出發(fā)地和目的地間的所有的路況信息，而且還是實時的，然后給出你一條明路，何等的神奇，但這些我們在 LiveNet 中都已經(jīng)實現(xiàn)了。

　　這里先回顧一下傳統(tǒng)的內(nèi)容分發(fā)網(wǎng)絡(luò)。

　　1、為什么要有內(nèi)容分發(fā)網(wǎng)絡(luò)，內(nèi)容分發(fā)網(wǎng)絡(luò)的由來

　　互聯(lián)網(wǎng)起源于美國軍方的一個內(nèi)部網(wǎng)絡(luò)，Tim Berners-Lee 是互聯(lián)網(wǎng)發(fā)明者之一，他很早就預(yù)見到在不久的將來網(wǎng)絡(luò)擁塞將成為互聯(lián)網(wǎng)發(fā)展的最大障礙，于是他提出了一個學(xué)術(shù)難題，要發(fā)明一種全新的、從根本上解決問題的方法來實現(xiàn)互聯(lián)網(wǎng)內(nèi)容的無擁塞分發(fā)，這項學(xué)術(shù)難題最終催生出一種革新性的互聯(lián)網(wǎng)服務(wù)——CDN 。當(dāng)時 Berners-Lee 博士隔壁是 Tom Leighton 教授的辦公室，一位麻省理工學(xué)院應(yīng)用數(shù)學(xué)教授，他被 Berners-Lee 的挑戰(zhàn)激起了興趣。Letghton 最終解決了這個難題并開始自己的商業(yè)計劃，成立了 Akamai 公司，成為世界上第一家 CDN 公司。

　　2、傳統(tǒng) CDN 的架構(gòu)

　　上圖是一個典型的 CDN 系統(tǒng)的三級部署示意圖，節(jié)點是 CDN 系統(tǒng)中的最基本部署單元，分為三級部署，中心節(jié)點、區(qū)域節(jié)點和邊緣節(jié)點，最上面一級是中心節(jié)點，中間一級是區(qū)域節(jié)點，邊緣節(jié)點地理位置分散，為用戶提供就近的內(nèi)容訪問服務(wù)。

　　下面介紹一下 CDN 節(jié)點的分類，主要分成兩大類，骨干節(jié)點和 POP 節(jié)點，骨干節(jié)點又分為中心節(jié)點和區(qū)域節(jié)點。

骨干節(jié)點

中心節(jié)點

區(qū)域節(jié)點

POP節(jié)點

邊緣節(jié)點

　　邏輯上來講，骨干節(jié)點主要負責(zé)內(nèi)容分發(fā)和邊緣節(jié)點未命中時進行回源，POP 節(jié)點主要負責(zé)提供給用戶就近的內(nèi)容訪問服務(wù)。但如果 CDN 網(wǎng)絡(luò)規(guī)模較大，邊緣節(jié)點直接向中心節(jié)點回源會給中間層的核心設(shè)備造成的壓力過大，在物理上引入?yún)^(qū)域節(jié)點，負責(zé)一個地理區(qū)域的管理，保存部分熱點數(shù)據(jù)。

　　3、直播傳輸網(wǎng)絡(luò)有別于傳統(tǒng) CDN 的痛點

　　隨著 Live 時代的到來，直播成為當(dāng)前 CDN 廠商的又一個主要的戰(zhàn)場，那么 Live 時代 CDN 需要支持什么樣的服務(wù)呢？

流媒體協(xié)議的支持，包括 RTMP，HLS ，HTTP-FLV 等。

首屏秒開，從用戶點擊到播放控制在秒級以內(nèi)

1~3 延遲控制，從推流端到播放端，延遲控制在 1~3 秒之間

全球全網(wǎng)智能路由，可以利用整個 CDN 網(wǎng)絡(luò)內(nèi)的所有節(jié)點為某一單一用戶服務(wù)，不受地域限制。隨著全球一體化進程不斷推進，跨區(qū)域、跨國家、跨洲的直播正變?yōu)槌B(tài)，很可能主播在歐美，而用戶在亞洲。

天級別的節(jié)點按需增加，中國公司出海已成大勢，CDN 需要更多的海外節(jié)點，如今比拼的更多的是海外節(jié)點可以快速部署，從提出節(jié)點增加需求到節(jié)點入網(wǎng)提供服務(wù)，需要達到一天之內(nèi)，對 CDN 運維和規(guī)劃提出非常高的要求。原有的月級別規(guī)劃和入網(wǎng)滿足不了先進的要求。

　　4、傳統(tǒng) CDN 的鏈路路由

　　CDN 基于樹狀網(wǎng)絡(luò)拓撲結(jié)構(gòu)，每一層都有 GSLB (Global Server Load Balancing) 用于同一層內(nèi)的多個 CDN 節(jié)點負載均衡，這樣有什么好處呢？

　　前面提到的眾多 CDN 的應(yīng)用場景中，網(wǎng)頁加速、視頻加速、文件傳輸加速，都是同時依賴 GSLB 和 Cache 系統(tǒng)的，Cache 系統(tǒng)是整個 CDN 系統(tǒng)中的成本所在，設(shè)計樹形結(jié)構(gòu)可以最大化的節(jié)省 Cache 系統(tǒng)的資本投入。因為只有中心節(jié)點需要保持機會所有的 Cache 副本，向下逐級減少，到了邊緣節(jié)點只需要少量的熱點 Cache 就可以命中大部分 CDN 訪問請求，這樣極大的降低了 CDN 網(wǎng)絡(luò)的成本，也符合當(dāng)時 CDN 用戶的需求，可謂雙贏。

　　但是到了 Live 時代，直播業(yè)務(wù)是流式業(yè)務(wù)，很少涉及到 Cache 系統(tǒng)，基本都是播完就可以釋放掉存儲資源，即使因為政策原因有存儲的需求也都是冷存儲，對于存儲的投入相對非常低廉，而且不要求存儲在所有節(jié)點中，只要保證數(shù)據(jù)可回溯，可用即可。

　　我們看看樹狀網(wǎng)絡(luò)拓撲，用戶的鏈路選擇數(shù)量是有限的，如下圖，用戶在某一個區(qū)域內(nèi)可選擇的鏈路數(shù)是：2 * 5 = 10

　　用戶在某一區(qū)域內(nèi)，則 GSLB （通常在邊緣節(jié)點這一層是 Smart DNS）會把用戶路由到該區(qū)域內(nèi)的某個邊緣節(jié)點，上一層又會路由到某個區(qū)域節(jié)點（這里的 GSLB 通常是內(nèi)部的負載均衡器），最后又回溯到中心節(jié)點，中心節(jié)點會鏈接源站。

　　這里的假設(shè)是：

用戶能訪問的最快節(jié)點一定是該區(qū)域內(nèi)的邊緣節(jié)點，如果該區(qū)域沒有邊緣節(jié)點則最快的一定是邏輯相鄰的區(qū)域內(nèi)的邊緣節(jié)點。

邊緣節(jié)點能訪問的最快節(jié)點一定是該區(qū)域內(nèi)的區(qū)域節(jié)點，一定不會是其他區(qū)域的節(jié)點。

區(qū)域節(jié)點到中心節(jié)點一定是最快的，這個鏈路的速度和帶寬都是最優(yōu)的。

　　但實際真的如此么？引入了如此多的假設(shè)真的正確么？

　　實際上就算理論上我們可以證明以上假設(shè)有效，但是節(jié)點規(guī)劃和區(qū)域配置大都依賴于人的設(shè)計和規(guī)劃，我們知道人多是不靠譜的，而且就算當(dāng)時區(qū)域規(guī)劃正確，誰能保證這些靜態(tài)的網(wǎng)絡(luò)規(guī)劃不會因為鋪設(shè)了一條光纖或者因為某些 IDC 壓力過大而發(fā)生了改變呢？所以我們可以跳出樹狀網(wǎng)絡(luò)拓撲結(jié)構(gòu)的桎梏，探索新的適合直播加速的網(wǎng)絡(luò)拓撲結(jié)構(gòu)。

　　為了擺脫有限的鏈路路由線路限制，激活整理網(wǎng)絡(luò)的能力，我們可以把上述的節(jié)點變成網(wǎng)狀網(wǎng)絡(luò)拓撲結(jié)構(gòu)：

　　我們看到一旦我們把網(wǎng)絡(luò)結(jié)構(gòu)改成了網(wǎng)狀結(jié)構(gòu)，則用戶的可選擇鏈路變?yōu)椋簾o向圖的指定兩點間的所有路徑，學(xué)過圖論的同學(xué)都知道，數(shù)量驚人。

　　系統(tǒng)可以通過智能路由選擇任何一個最快的鏈路而不用依賴于系統(tǒng)部署時過時的人工規(guī)劃，無論是某些鏈路間增加了光纖或者某個 IDC 壓力過大都可以實時的反映到整理網(wǎng)絡(luò)中，幫助用戶實時推倒出最優(yōu)鏈路。這時我們可以去掉前面的一些假設(shè)，通過機器而不是人類來時實時規(guī)劃網(wǎng)絡(luò)的鏈路路由，這種實時大規(guī)模的計算任務(wù)天生就不是人類的強項，我們應(yīng)該交給更適合的物種。

　　5、CDN 的擴容

　　前面提到中國公司的出海已成大勢，CDN 海外節(jié)點的需求越來越大，遇到這種情況需要 CDN 廠商在新的區(qū)域部署新的骨干網(wǎng)和邊緣節(jié)點，需要做詳細的網(wǎng)絡(luò)規(guī)劃。時代發(fā)生變化，原來 CDN 用戶都是企業(yè)級用戶，本身業(yè)務(wù)線的迭代周期較長，有較長時間的規(guī)劃，留給 CDN 廠商的時間也比較多。而互聯(lián)網(wǎng)公司講究的是速度，雙周迭代已成常態(tài)，這里面涉及到成本和響應(yīng)速度的矛盾，如果提前部署節(jié)點可以更好的為這些互聯(lián)網(wǎng)公司服務(wù)，但是有較高的成本壓力，反之則無法響應(yīng)這些快速發(fā)展的互聯(lián)網(wǎng)公司。

　　理想情況是，用戶提出需求，CDN 廠商內(nèi)部評估，當(dāng)天給出反饋，當(dāng)天部署，客戶當(dāng)天就可以測試新區(qū)域的新節(jié)點。怎么解決？

　　答案是基于網(wǎng)狀拓撲結(jié)構(gòu)的對等網(wǎng)絡(luò)，在網(wǎng)狀拓撲結(jié)構(gòu)中每個節(jié)點都是 Peer ，邏輯上每個節(jié)點提供的服務(wù)對等，不需要按區(qū)域設(shè)計復(fù)雜的網(wǎng)絡(luò)拓撲結(jié)構(gòu)，節(jié)點上線后不需要復(fù)雜的開局過程，直接上線注冊節(jié)點信息，就可以對用戶提供服務(wù)了,結(jié)合虛擬化技術(shù)前后時間理論上可以控制在一天之內(nèi)。

　　6、回歸本質(zhì)：LiveNet

　　我們知道最早的互聯(lián)網(wǎng)就是網(wǎng)狀拓撲結(jié)構(gòu)，后來才慢慢加入了骨干網(wǎng)來解決各種各樣的問題，我們是時候該回歸本質(zhì)，擁抱下一代 Live 分發(fā)網(wǎng)絡(luò)：LiveNet ?？偨Y(jié)前面的討論，我們發(fā)現(xiàn) Live 時代我們需要的內(nèi)容分發(fā)網(wǎng)絡(luò)是：

對 Cache 的要求沒有以前那么高

對實時性的要求非常高

對節(jié)點運維的要求高，要更智能，盡量減少人工干預(yù)

對擴容這種運維事件響應(yīng)度要求非常高

　　要做到如上幾點，我們需要：

去中心化，網(wǎng)狀拓撲

全球全網(wǎng)調(diào)度

節(jié)點無狀態(tài)，節(jié)點對等

智能運維

　　以上這些就是 LiveNet 設(shè)計時候的斟酌，讓運維更自動化，系統(tǒng)運行高度自治，依賴機器計算而不是人工判斷，下面分別介紹一下。

　　1）去中心，網(wǎng)狀拓撲

　　網(wǎng)狀拓撲結(jié)構(gòu)是設(shè)計的根本和基礎(chǔ)，只有看清了我們對 Cache 需求的降低，網(wǎng)狀拓撲結(jié)構(gòu)才更有優(yōu)勢。

　　2）全球全網(wǎng)調(diào)度

　　基于全球一張網(wǎng)，不在受限于區(qū)域網(wǎng)絡(luò)調(diào)度，將調(diào)度的范圍從區(qū)域網(wǎng)絡(luò)擴展到全球，全網(wǎng)內(nèi)的節(jié)點都可以響應(yīng)用戶的請求，參與鏈路路由，不再先由人工假設(shè)選定一部分節(jié)點進行路由，去掉人工干預(yù)，讓整個系統(tǒng)更智能。

　　3）節(jié)點無狀態(tài)，節(jié)點對等

　　LiveNet 節(jié)點無狀態(tài)和節(jié)點對等都方便了運維，去掉了區(qū)域概念后的全球一張網(wǎng)讓整個拓撲結(jié)構(gòu)變的異常復(fù)雜，如果各個節(jié)點間有先后依賴關(guān)系，勢必讓運維成為噩夢，需要專有的服務(wù)編排系統(tǒng)，同時也給擴容帶來困難，需要運維人員設(shè)計復(fù)雜的擴容方案，需要預(yù)演多次才敢在復(fù)雜的網(wǎng)絡(luò)拓撲中擴容。當(dāng)時如果節(jié)點本身對等且無狀態(tài)，則運維和擴容都變的容易很多。

　　但整個系統(tǒng)在運行過程中還是會一些狀態(tài)和數(shù)據(jù)需要保持，比如某些 Live 內(nèi)容需要落地回放的需求，這些通過久經(jīng)考驗的七牛云存儲來存儲。

　　4）智能運維

　　智能運維建立在以上的「網(wǎng)狀拓撲結(jié)構(gòu)的對等網(wǎng)絡(luò)」的基礎(chǔ)上會變的容易的多。可以方便的下線有問題的節(jié)點而不影響整個 LiveNet 網(wǎng)絡(luò)，可以方便快速的上線新節(jié)點，提升系統(tǒng)容量。通過節(jié)點的數(shù)據(jù)分析可以更好的了解整個網(wǎng)絡(luò)的整體狀態(tài)。

　　下面列舉部分 LiveNet 采用的智能運維方案，讓內(nèi)容分發(fā)網(wǎng)絡(luò)再次升級，以符合 Live 時代的要求。

監(jiān)控節(jié)點健康狀況，實時下線有問題的節(jié)點

Failover 機制，保證服務(wù)一直可用

快速擴容

　　7、LiveNet VS P2P

　　最后我們和 P2P 網(wǎng)絡(luò)做一個對比：

　　我們發(fā)現(xiàn) P2P 方案，節(jié)點的可控性和鏈路的穩(wěn)定性上還有很大提升空間，比較適合在實時性要求不高的場景使用、適合長尾需求，在 Live 的場景下面多是對實時性要求比較高的重度用戶，無法忍受頻繁的 FailOver 和節(jié)點質(zhì)量參差不齊帶來的網(wǎng)絡(luò)抖動，但是如果是文件分發(fā)就比較適合用這種混合方案，可以有效降低 CDN 廠商成本，利用共享經(jīng)濟提高資源利用率。

　　這篇介紹了推送和傳輸網(wǎng)絡(luò)部分，我們已經(jīng)把流媒體送到了觀眾的終端中，下一步就是把它展現(xiàn)在屏幕上了，想了解這部分內(nèi)容請繼續(xù)關(guān)注我們的下一篇內(nèi)容。

　　【沒看過癮？直接來上免費公開課】

　　為了讓大家能夠?qū)⒓夹g(shù)理論快速應(yīng)用到實踐開發(fā)中，七牛云聯(lián)合慕課網(wǎng)、StuQ 特別制作了一期課程，專門針對移動直播應(yīng)用開發(fā)，供大家學(xué)習(xí)參考。

　　慕課網(wǎng)：

　　https://www.imooc.com/learn/707

　　StuQ ：

　　https://www.stuq.org/course/detail/1077

　　點擊「閱讀原文」學(xué)習(xí)《2 小時搞定移動直播 App 開發(fā)》