目前，視頻內(nèi)容占據(jù)了所有互聯(lián)網(wǎng)的流量近70%（而且還在不斷攀升），因此視頻流媒體的重要性從未像現(xiàn)在這樣重要?，F(xiàn)下，大部分內(nèi)容由內(nèi)容交付網(wǎng)絡(luò)（CDN）管理。然而，對于涉及實時內(nèi)容的CDN視頻流時，仍存在許多不足之處。

由于CDN要求您通過其數(shù)據(jù)網(wǎng)導(dǎo)入所有的內(nèi)容，因此一些流媒體提供商發(fā)現(xiàn)他們需要使用多個CDN來到達不同的地區(qū)。這意味著管理不同的系統(tǒng)、分散的流媒體以及添加更多的連接來傳輸流會帶來更長時間的延遲以及額外的復(fù)雜性。

這促使實時流媒體市場的許多人開始轉(zhuǎn)向multi-CDN解決方案。事實上，據(jù)預(yù)測，到2025年，multi-CDN市場將增長到240億美元。雖然multi-CDN解決了單個CDN網(wǎng)絡(luò)的一些問題（地區(qū)/區(qū)域可用性、價格等），但實際上它只是實時視頻流的權(quán)宜之計?，F(xiàn)在，純WebRTC分發(fā)服務(wù)是創(chuàng)建實時流媒體的最佳方式。

因此，純CDN解決方案正逐漸退出市場，至少在直播視頻分發(fā)方面是如此。原因如下：

延遲

基于HTTP體系架構(gòu)構(gòu)建的CDN根本不具備處理動態(tài)更新內(nèi)容（如實時視頻）的傳輸?shù)哪芰ΑＫ鼈兊?a href="http://m.makelele.cn/v/tag/773/" target="_blank">工作原理是在區(qū)域數(shù)據(jù)中心緩存數(shù)據(jù)，以便高效地傳遞大量數(shù)據(jù)。這種設(shè)計的重點在于吞吐量和可伸縮性，從而形成了最適合處理靜態(tài)對象（例如網(wǎng)站或預(yù)先錄制的視頻）的網(wǎng)絡(luò)。

緩存會影響延遲，而延遲與傳遞靜態(tài)元素（例如網(wǎng)頁和VOD）無關(guān)緊要。隨著實時視頻體驗變得更具交互性，這意味著它們越來越依賴于低延遲傳輸。即使只有一秒鐘的延遲也會對用戶體驗和應(yīng)用程序的實用性產(chǎn)生負面影響。如果它不是實時流式傳輸，就無法直播。

為了解決這個延遲問題，我們需要使用一種新的方案：WebRTC。WebRTC是圍繞低延遲流媒體設(shè)計的。它可以以小于500毫秒的端到端延遲傳輸實時視頻，這比HLS傳輸快得多，后者即使經(jīng)過修改，也只能在最低的情況下降低到2-3秒。因此，純WebRTC服務(wù)預(yù)計將從多CDN總流量（total Multi-CDN traffic）的1.2%增長到8.3%。

單向流動

除了高延遲之外，CDN實際上是圍繞著將數(shù)據(jù)分發(fā)到客戶端而不是回接收信息而設(shè)計的。隨著現(xiàn)場體驗變得更具交互性，將諸如縮放呼叫、共同查看和粉絲墻體驗等功能集成到這些事件中，無法在多個方向上流傳輸內(nèi)容對CNDs的實用性是一個重大的損害。

CDN中的每個服務(wù)器本質(zhì)上都被用作一個攝取點，它將流推送到CDN以進行大規(guī)模的傳輸。這意味著它可以很好地將數(shù)據(jù)從原點分發(fā)到邊緣，但對于反向傳輸流信息（從邊緣返回原點）則不太好。在這種架構(gòu)下，雙向通信效率不高，因為CDN最適合于廣播只由訂閱者觀看的單個流，而不是雙向聊天，其中訂閱者在訂閱視頻的同時也在廣播視頻。對話在雙方之間來回進行，因此他們都必須發(fā)送和接收視頻。這意味著CDN根本不提供這一功能，而想要構(gòu)建交互式視頻體驗的開發(fā)人員則不得不將完全不同的技術(shù)拼湊在一起，而這些技術(shù)從來都是預(yù)備過的。

在CDN模型中，請求的數(shù)據(jù)需要從原點傳輸?shù)竭吘?。一旦中繼到最近的邊緣服務(wù)器，它就必須與每個試圖訪問流的客戶機建立單獨的連接。這被稱為“最后一英里”，是CDN視頻流解決方案帶寬消耗的主要來源。一些網(wǎng)絡(luò)已經(jīng)找到了解決這個問題的方法來降低數(shù)據(jù)傳輸成本。

一些提供商使用WebRTC來提高CDN容量。使用WebRTC的話，將有高達70%的峰值流量可以被卸載，這有助于CDN供應(yīng)商避免基礎(chǔ)設(shè)施升級，并使CDN分銷商能夠利用現(xiàn)有預(yù)算做更多事情。

例如，Peer5、StreamRoot和StriveCast已經(jīng)創(chuàng)建了點對點共享網(wǎng)絡(luò)，以轉(zhuǎn)移它們在CDN上的總帶寬消耗。他們不必將所有的內(nèi)容一對一地從edge流到客戶端，而是在流相同文件的所有客戶端之間創(chuàng)建數(shù)據(jù)通道連接。這樣，視頻通過高效的分塊傳輸HLS協(xié)議從源服務(wù)器發(fā)送到邊緣服務(wù)器。一旦訂閱者拉出那些HLS （.ts）段，它就可以在WebRTC數(shù)據(jù)通道上建立一個P2P連接來將那些段轉(zhuǎn)發(fā)給那個對等者。然后，該對等端可以與另一方建立連接。然后重復(fù)這個連接過程，這樣他們就可以共享相同的視頻文件了。這意味著每個用戶都不必從CDN（為數(shù)據(jù)傳輸收費的網(wǎng)絡(luò)）中冗余地拉出所有的數(shù)據(jù)段。

雖然這些點對點的網(wǎng)狀網(wǎng)絡(luò)對于VOD傳輸是有效的，但是對于低延遲的實時流媒體則不是有效的。首先，他們?nèi)匀皇褂肏LS段作為流的源，這將導(dǎo)致高延遲的問題。其次，這種網(wǎng)狀網(wǎng)絡(luò)并沒有解決雙向流的問題。此外，還有另一類新興的純WebRTC基礎(chǔ)提供商，他們根本不使用CDN，事實上它們已經(jīng)完全取代了CDN。

同步化

實時延遲還釋放了與視頻流的其他數(shù)據(jù)正確同步的能力。這開啟了添加聊天功能、實時覆蓋疊加和交互式圖形、虛擬黑板、實時下注和拍賣出價、GPS數(shù)據(jù)和許多其他的功能。例如，一個體育廣播可以有一個實時的圖形顯示功能，它可以與屏幕上發(fā)生的最新狀態(tài)保持同步。正確的同步與實時延遲相結(jié)合，也可以防止惱人的劇透，從而確保不會破壞其他人的觀看體驗。它還可以確保聊天中的評論與當前顯示的內(nèi)容一致。

對于這些用例，數(shù)據(jù)可以通過WebRTC數(shù)據(jù)通道或單獨的websocket通道發(fā)送，這可以使用SharedObjects方法實現(xiàn)。SharedObjects管理多個客戶端之間的數(shù)據(jù)提要，從而實現(xiàn)數(shù)據(jù)的一致傳輸。這樣可以確保廣播者，訂戶和任何其他功能之間的完全交互。

在GitHub上可以找到更多示例：

SharedObject：https://github.com/red5pro/streaming-html5/tree/master/src/page/test/sharedObject

SharedObject

iOS：https://github.com/red5pro/streaming-ios/tree/master/R5ProTestbed/Tests/SharedObject

Android：https://github.com/red5pro/streaming-android/tree/master/app/src/main/java/red5pro/org/testandroidproject/tests/SharedObjectTest

所有這些關(guān)于CDN實時流傳輸局限性的討論可能會給你一種印象：即它們應(yīng)該被純WebRTC解決方案所取代。然而，它們在視頻流媒體中仍然扮演著非常有價值的角色。CDN對于交付視頻點播內(nèi)容以及靜態(tài)對象（如網(wǎng)站和靜態(tài)圖像）仍然很有用。

然而，當涉及到動態(tài)更新的元素（如實時視頻流）時，CDN永遠無法正確處理它們。與許多其他技術(shù)要素一樣，市場的需求也擴大并發(fā)生了變化。CND正在試圖適應(yīng)這種情況，但它們基于HTTP的基本架構(gòu)造成了高延遲、單向流限制和同步問題。這些問題，會由新的直播架構(gòu)模型來解決。

責任編輯：lq