cdn直播加速原理vps主机直播

既然是原理，那么其实和内容关系不大，视频、文件、网页都是一样的，目前CDN厂商直播加速比较多，暂时没有遇到视频会议类的客户.

一句话来总结就是：CDN就是通过一切可能的手段和方案，让用户回源和接收数据的速度达到最优，并为服务器提供安全和并发屏障的一种服务

1.用户（UGC）------------>CDN调度（GSLB）------------>推流边缘节点

-GSLB做的工作是为了不跨网和寻找离用户最近的边缘节点，比如用户开通的带宽是电信的，那么GSLB一定会返回电信边缘节点的IP，如果返回联通的，会增加CDN的成本和网络传输速度

-增加父层是为了减少回源，减少源服务器的吞吐量和并发量，行业标准做法，为达到目的可增加多级父

3.播放端------------>CDN调度（GSLB）------------>拉流边缘节点------------>父层------------>源站

直播对内容实时产生实时消费，对时效性要求更高；流媒体内容占用带宽大，对网络质量要求更苛刻；一人生产、多人消费，带宽规模大。直播CDN目前是解决这种大规模分发场景最有效的技术途径，主要特点是就近接入以提供良好的接入网环境，多层汇聚以降低中心资源的分发压力，以此达到直播业务规模化和时效性的要求。

下面从直播CDN的困难、解决方案、系统架构如何设计三个方面来详细说一下，希望可以解决你的问题。

由于直播业务本身对于质量和时效性的要求，CDN就需要在短时间内要找到并建立一条完整可靠的传输链路，对于链路稳定性有一定的要求。传统依赖于旁路更新的、基于链路质量的策略，寻路算法简单，不消耗太多时间，时效性有保障。但随着成本压力越来越大和可用性的要求越来越高，基于链路质量的策略的缺点就逐渐体现出来：

一个是这种旁路策略第一策略时效性上存在一定的延迟，延迟大约2-3分钟，对于偶发性的质量恶化或资源偏压无法快速做出相应的策略调整；

第二是基于一套统一的链路质量数据，无法兼顾资源能效，对于一些能效低的内容无法基于成本考虑做出相应的寻路策略调整，对浮动成本的控制不够精确。

基于资源信息、链路状态、流媒体信息等多维度数据，精确计算每一路流的分发效能，将计算粒度精确到流一级。通过对能效、质量的综合计算，为每一路流动态计算接入和回源策略是解决困难的关键。

调度系统通过收集、结合资源信息、链路状态、流媒体信息等，对直播接入和寻路进行控制，快速精确的调整策略，提供质量优先、成本优先、质量成本平衡等多种策略，对于在质量指标评价体系下提升分发系统的可用性和能效比提供更加精准和细粒度的控制。

延迟不超过50ms，考虑到公网的网络本身的传输延迟，基本上不会有多余的时间进行其他系统调用和计算，需要预先准备好响应的策略，并且调度接入位置要尽量靠近调用侧。设计了策略推送、策略缓存、异步更新三种功能。

由于流媒体信息同步延迟要求100ms，考虑公网网络传输的延迟，定时采集上报的方式无法满足延迟要求，采用事件触发实时API上报的方式同步数据。设备信息、节点信息为接口调用方式取回，对于时效性要求不高，采用任务分派机制，防止数据重复取回。

当系统负载过高时，保护系统服务，提升系统恢复速度，降低系统负载，需要对系统业务流量进行限制。

无法在进行接入和询源调度服务时，需要退化为默认兜底策略，接入退化为DNS解析方式，询源退化为CDN固定询源策略，不再依赖调度系统做策略选择。

信息采集系统作为调度系统的数据底座，主要功能是从运维系统收集设备资源情况、从业务系统收集流媒体信息，经过数据整合之后提供给资源调度使用。

信息采集系统通过主动定时调用运维系统接口采集设备运行数据，包括CPU使用率、内存使用率、磁盘IO、网络IO等信息，用于评价设备的服务能力。采集节点带宽用量等信息，用于评价节点承载能力。

通过主动定时调用监控系统接口采集链路质量数据，包括RTT，丢包率等信息，用于评价网络质量。

通过被动等待CDN业务实例上报流媒体资源位置、下行并发、卡顿率等信息，用于评价服务质量和服务收益。

这些信息被收集上来之后通过分类整合，按照节点、地区、运营商、业务形式等不同维度，形成服务能力、服务质量、服务收益的聚合数据。

资源调度作为调度系统核心业务模块，主要从信息采集收取必要调度依据，通过一套调度策略，输出调度计划提供给接入和询源业务。

资源调度系统主要通过运管平台将个性化调度配置信息落到资源调度系统。通过查询信息采集接口，查询所需要的服务能力、服务质量、服务收益等信息。通过匹配不同的调度策略，生成静态调度计划。

通过查询信息采集接口，查询流媒体资源位置及描述信息。通过匹配调度策略，生成动态调度计划。

我也挺关心这个问题的。我的理解CDN直播应该是边拉（pull）源站资源边播放的过程。因为显然直播嘛，资源在源站上生成之前，在CDN系统里是绝对不会有的。就是典型的未命中场景了。

快的话，应该是会比不缓存快的。因为从客户端到CDN的边缘POP节点，边缘POP节点经过CDN系统内部的逐级互联，再到源站，带宽管够和出现拥塞的概率较低是一方面。另一方面如果不经过CDN，那客户端必须通过共享的带宽上到ISP的骨干网，再到源站，中间任何一个节点出现带宽瓶颈或者拥塞，都会导致末端的感知问题。还有一个就是源站到顶层的cache服务器（CDN系统内最全的内容库所在地）的网络质量很理想的情况下，后续的播放直接到顶层的cache服务器拿就是了，又省了一点时间。

总之，如果你直播，同时打开一个CDN缓存了你直播网站的ISP网络和一个未CDN缓存的网络，那么你的现场最快（废话）-CDN缓存（滞后）-未CDN缓存（更滞后）。

CDN做到加速，原理其实很简单，就是将服务器源站的资源缓存到位于全国各地的CDN节点上，用户请求访问时，就近返回节点上缓存的资源，避免网络拥塞、分担源站压力，保证用户访问资源的速度和体验。