由于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ù)哪芰?。它們的工作原理是在區(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)越依賴于低延遲傳輸。即使只有一秒鐘的延遲也會(huì)對(duì)用戶體驗(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ā)到客戶端而不是回接收信息而設(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ì)話在雙方之間來(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è)試圖訪問(wèn)流的客戶機(jī)建立單獨(dú)的連接。這被稱為“最后一英里”，是CDN視頻流解決方案帶寬消耗的主要來(lái)源。一些網(wǎng)絡(luò)已經(jīng)找到了解決這個(gè)問(wèn)題的方法來(lái)降低數(shù)據(jù)傳輸成本。
一些提供商使用WebRTC來(lái)提高CDN容量。使用WebRTC的話，將有高達(dá)70%的峰值流量可以被卸載，這有助于CDN供應(yīng)商避免基礎(chǔ)設(shè)施升級(jí)，并使CDN分銷商能夠利用現(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流到客戶端，而是在流相同文件的所有客戶端之間創(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è)用戶都不必從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)題。此外，還有另一類新興的純WebRTC基礎(chǔ)提供商，他們根本不使用CDN，事實(shí)上它們已經(jīng)完全取代了CDN。
同步化
實(shí)時(shí)延遲還釋放了與視頻流的其他數(shù)據(jù)正確同步的能力。這開(kāi)啟了添加聊天功能、實(shí)時(shí)覆蓋疊加和交互式圖形、虛擬黑板、實(shí)時(shí)下注和拍賣出價(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è)客戶端之間的數(shù)據(jù)提要，從而實(shí)現(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實(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)解決。
