江苏龙网

  1. 主页 > 生活百科 > >

CDN视频流中的3个问题以及解决方法

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视频流中的3个问题以及解决方法】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 。
 
同步化 


推荐阅读


上一篇：您一定得见识一下.Net中这几款HTTP请求库

下一篇：3千字Apollo配置中心的总结，让配置“智能”起来