目前，視頻內容占據了所有互聯網的流量近70%（而且還在不斷攀升），因此視頻流媒體的重要性從未像現在這樣重要。現下，大部分內容由內容交付網絡（CDN）管理。然而，對于涉及實時內容的CDN視頻流時，仍存在許多不足之處。

由于CDN要求您通過其數據網導入所有的內容，因此一些流媒體提供商發現他們需要使用多個CDN來到達不同的地區。這意味著管理不同的系統、分散的流媒體以及添加更多的連接來傳輸流會帶來更長時間的延遲以及額外的復雜性。

這促使實時流媒體市場的許多人開始轉向multi-CDN解決方案。事實上，據預測，到2025年，multi-CDN市場將增長到240億美元。雖然multi-CDN解決了單個CDN網絡的一些問題（地區/區域可用性、價格等），但實際上它只是實時視頻流的權宜之計。現在，純WebRTC分發服務是創建實時流媒體的最佳方式。

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

延遲

基于HTTP體系架構構建的CDN根本不具備處理動態更新內容（如實時視頻）的傳輸的能力。它們的工作原理是在區域數據中心緩存數據，以便高效地傳遞大量數據。這種設計的重點在于吞吐量和可伸縮性，從而形成了最適合處理靜態對象（例如網站或預先錄制的視頻）的網絡。

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

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

單向流動

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

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

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

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

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

雖然這些點對點的網狀網絡對于VOD傳輸是有效的，但是對于低延遲的實時流媒體則不是有效的。首先，他們仍然使用HLS段作為流的源，這將導致高延遲的問題。其次，這種網狀網絡并沒有解決雙向流的問題。此外，還有另一類新興的純WebRTC基礎提供商，他們根本不使用CDN，事實上它們已經完全取代了CDN。

同步化

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

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

在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

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

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

責任編輯：lq