直播技術之推流和傳輸

直播技術之推流和傳輸

推流和傳輸。推流是直播的第一千米，直播的推流對這個直播鏈路影響很是大，若是推流的網絡不穩定，不管咱們如何作優化，觀衆的體驗都會很糟糕。因此也是咱們排查問題的第一步，如何系統地解決這類問題須要咱們對相關理論有基礎的認識。

推送協議

下面就先介紹一下都有哪些推送協議，他們在直播領域的現狀和優缺點。

• RTMP
• WebRTC
• 基於 UDP 的私有協議
• HLS
• FLV

RTMP

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

RTMP 是目前主流的流媒體傳輸協議，普遍用於直播領域，能夠說市面上絕大多數的直播產品都採用了這個協議。

優勢

• CDN 支持良好，主流的 CDN 廠商都支持
• 協議簡單，在各平臺上實現容易

缺點

• 基於 TCP ，傳輸成本高，在弱網環境丟包率高的狀況下問題顯著
  
• 不支持瀏覽器推送
• Adobe 私有協議，Adobe 已經再也不更新
• 海量併發時也容易出現一些不可預期的穩定性問題

WebRTC

WebRTC，名稱源自網頁即時通訊（英語：Web Real-Time Communication）的縮寫，是一個支持網頁瀏覽器進行實時語音對話或視頻對話的 API。它於 2011 年 6 月 1 日開源並在 Google、Mozilla、Opera 支持下被歸入萬維網聯盟的 W3C 推薦標準。

目前主要應用於視頻會議和連麥中，協議分層以下：

優勢

• W3C 標準，主流瀏覽器支持程度高
• Google 在背後支撐，並在各平臺有參考實現
• 底層基於 SRTP 和 UDP，弱網狀況優化空間大
• 能夠實現點對點通訊，通訊雙方延時低

缺點

• ICE,STUN,TURN 傳統 CDN 沒有相似的服務提供

基於 UDP 的私有協議

有些直播應用會使用 UDP 作爲底層協議開發本身的私有協議，由於 UDP 在弱網環境下的優點經過一些定製化的調優能夠達到比較好的弱網優化效果，但一樣由於是私有協議也勢必有現實問題：

優勢

更多空間進行定製化優化

缺點

• 開發成本高
• CDN 不友好，須要自建 CDN 或者和 CDN 達成協議
• 獨立做戰，沒法和社區一塊兒演進

其餘協議

FLV

FLV協議由Adobe公司主推，格式極其簡單，只是在大塊的視頻幀和音視頻頭部加入一些標記頭信息，因爲這種極致的簡潔，在延遲表現和大規模併發方面都很成熟。惟一的不足就是在手機瀏覽器上的支持很是有限，可是用做手機端APP直播協議卻異常合適。

HLS

蘋果推出的解決方案，將視頻分紅5-10秒的視頻小分片，而後用m3u8索引表進行管理，因爲客戶端下載到的視頻都是5-10秒的完整數據，故視頻的流暢性很好，但也一樣引入了很大的延遲（HLS的通常延遲在10-30s左右）。相比於FLV， HLS在iPhone和大部分android手機瀏覽器上的支持很是給力，因此經常使用於QQ和微信朋友圈的URL分享

傳輸網絡

咱們推送出去的流媒體須要傳輸到觀衆，整個鏈路就是傳輸網絡，類比貨運物流就是從出發地到目的地見的全部路程了，若是道路的容量不夠，會引起堵車也就是網絡擁塞，這時咱們會改變路程也就是所謂的智能調度，可是傳輸網絡會站在全局的角度進行調度，因此會比原子世界的調度有更好的效果，能夠想象有一個上帝在天空中俯視出發地和目的地間的全部的路況信息，並且仍是實時的，而後給出你一條明路，何等的神奇。

這裏先回顧一下傳統的內容分發網絡。

爲何要有內容分發網絡，內容分發網絡的由來

互聯網起源於美國軍方的一個內部網絡，Tim Berners-Lee 是互聯網發明者之一，他很早就預見到在不久的未來網絡擁塞將成爲互聯網發展的最大障礙，因而他提出了一個學術難題，要發明一種全新的、從根本上解決問題的方法來實現互聯網內容的無擁塞分發，這項學術難題最終催生出一種革新性的互聯網服務——CDN 。當時 Berners-Lee 博士隔壁是 Tom Leighton 教授的辦公室，一位麻省理工學院應用數學教授，他被 Berners-Lee 的挑戰激起了興趣。Letghton 最終解決了這個難題並開始本身的商業計劃，成立了 Akamai 公司，成爲世界上第一家 CDN 公司。

傳統 CDN 的架構

上圖是一個典型的 CDN 系統的三級部署示意圖，節點是 CDN 系統中的最基本部署單元，分爲三級部署，中心節點、區域節點和邊緣節點，最上面一級是中心節點，中間一級是區域節點，邊緣節點地理位置分散，爲用戶提供就近的內容訪問服務。

下面介紹一下 CDN 節點的分類，主要分紅兩大類，骨幹節點和 POP 節點，骨幹節點又分爲中心節點和區域節點。

• 骨幹節點

  • 中心節點

  • 區域節點

• POP節點

  • 邊緣節點

邏輯上來說，骨幹節點主要負責內容分發和邊緣節點未命中時進行回源，POP 節點主要負責提供給用戶就近的內容訪問服務。但若是 CDN 網絡規模較大，邊緣節點直接向中心節點回源會給中間層的核心設備形成的壓力過大，在物理上引入區域節點，負責一個地理區域的管理，保存部分熱點數據。

直播傳輸網絡有別於傳統 CDN 的痛點

隨着 Live 時代的到來，直播成爲當前 CDN 廠商的又一個主要的戰場，那麼 Live 時代 CDN 須要支持什麼樣的服務呢？

• 流媒體協議的支持，包括 RTMP，HLS ，HTTP-FLV 等。
• 首屏秒開，從用戶點擊到播放控制在秒級之內
• 1~3 延遲控制，從推流端到播放端，延遲控制在 1~3 秒之間
• 全球全網智能路由，能夠利用整個 CDN 網絡內的全部節點爲某一單一用戶服務，不受地域限制。隨着全球一體化進程不斷推動，跨區域、跨國家、跨洲的直播正變爲常態，極可能主播在歐美，而用戶在亞洲。
• 天級別的節點按需增長，中國公司出海已成大勢，CDN 須要更多的海外節點，現在比拼的更多的是海外節點能夠快速部署，從提出節點增長需求到節點入網提供服務，須要達到一天以內，對 CDN 運維和規劃提出很是高的要求。原有的月級別規劃和入網知足不了先進的要求。

傳統 CDN 的鏈路路由

CDN 基於樹狀網絡拓撲結構，每一層都有 GSLB (Global Server Load Balancing) 用於同一層內的多個 CDN 節點負載均衡，這樣有什麼好處呢？

前面提到的衆多 CDN 的應用場景中，網頁加速、視頻加速、文件傳輸加速，都是同時依賴 GSLB 和 Cache 系統的，Cache 系統是整個 CDN 系統中的成本所在，設計樹形結構能夠最大化的節省 Cache 系統的資本投入。由於只有中心節點須要保持機會全部的 Cache 副本，向下逐級減小，到了邊緣節點只須要少許的熱點 Cache 就能夠命中大部分 CDN 訪問請求，這樣極大的下降了 CDN 網絡的成本，也符合當時 CDN 用戶的需求，可謂共贏。

可是到了 Live 時代，直播業務是流式業務，不多涉及到 Cache 系統，基本都是播完就能夠釋放掉存儲資源，即便由於政策緣由有存儲的需求也都是冷存儲，對於存儲的投入相對很是低廉，並且不要求存儲在全部節點中，只要保證數據可回溯，可用便可。

咱們看看樹狀網絡拓撲，用戶的鏈路選擇數量是有限的，以下圖，用戶在某一個區域內可選擇的鏈路數是：2 * 5 = 10

用戶在某一區域內，則 GSLB （一般在邊緣節點這一層是 Smart DNS）會把用戶路由到該區域內的某個邊緣節點，上一層又會路由到某個區域節點（這裏的 GSLB 一般是內部的負載均衡器），最後又回溯到中心節點，中心節點會連接源站。

這裏的假設是：

• 用戶能訪問的最快節點必定是該區域內的邊緣節點，若是該區域沒有邊緣節點則最快的必定是邏輯相鄰的區域內的邊緣節點。
• 邊緣節點能訪問的最快節點必定是該區域內的區域節點，必定不會是其餘區域的節點。
• 區域節點到中心節點必定是最快的，這個鏈路的速度和帶寬都是最優的。

但實際真的如此麼？引入瞭如此多的假設真的正確麼？

實際上就算理論上咱們能夠證實以上假設有效，可是節點規劃和區域配置大都依賴於人的設計和規劃，咱們知道人可能是不靠譜的，並且就算當時區域規劃正確，誰能保證這些靜態的網絡規劃不會由於鋪設了一條光纖或者由於某些 IDC 壓力過大而發生了改變呢？因此咱們能夠跳出樹狀網絡拓撲結構的桎梏，探索新的適合直播加速的網絡拓撲結構。

爲了擺脫有限的鏈路路由線路限制，激活整理網絡的能力，咱們能夠把上述的節點變成網狀網絡拓撲結構：

咱們看到一旦咱們把網絡結構改爲了網狀結構，則用戶的可選擇鏈路變爲：無向圖的指定兩點間的全部路徑，學過圖論的同窗都知道，數量驚人。

系統能夠經過智能路由選擇任何一個最快的鏈路而不用依賴於系統部署時過期的人工規劃，不管是某些鏈路間增長了光纖或者某個 IDC 壓力過大均可以實時的反映到整理網絡中，幫助用戶實時推倒出最優鏈路。這時咱們能夠去掉前面的一些假設，經過機器而不是人類來時實時規劃網絡的鏈路路由，這種實時大規模的計算任務天生就不是人類的強項，咱們應該交給更適合的物種。

CDN 的擴容

前面提到中國公司的出海已成大勢，CDN 海外節點的需求愈來愈大，遇到這種狀況須要 CDN 廠商在新的區域部署新的骨幹網和邊緣節點，須要作詳細的網絡規劃。時代發生變化，原來 CDN 用戶都是企業級用戶，自己業務線的迭代週期較長，有較長時間的規劃，留給 CDN 廠商的時間也比較多。而互聯網公司講究的是速度，雙週迭代已成常態，這裏面涉及到成本和響應速度的矛盾，若是提早部署節點能夠更好的爲這些互聯網公司服務，可是有較高的成本壓力，反之則沒法響應這些快速發展的互聯網公司。

理想狀況是，用戶提出需求，CDN 廠商內部評估，當天給出反饋，當天部署，客戶當天就能夠測試新區域的新節點。怎麼解決？

答案是基於網狀拓撲結構的對等網絡，在網狀拓撲結構中每一個節點都是 Peer ，邏輯上每一個節點提供的服務對等，不須要按區域設計複雜的網絡拓撲結構，節點上線後不須要複雜的開局過程，直接上線註冊節點信息，就能夠對用戶提供服務了,結合虛擬化技術先後時間理論上能夠控制在一天以內。