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

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

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

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

延遲

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

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

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

單向流動(dòng)

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

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

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

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

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

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

同步化

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

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

在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實(shí)時(shí)流傳輸局限性的討論可能會(huì)給你一種印象：即它們應(yīng)該被純WebRTC解決方案所取代。然而，它們?cè)谝曨l流媒體中仍然扮演著非常有價(jià)值的角色。CDN對(duì)于交付視頻點(diǎn)播內(nèi)容以及靜態(tài)對(duì)象（如網(wǎng)站和靜態(tài)圖像）仍然很有用。

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

責(zé)任編輯：lq