直播CDN架构内幕

思心 2019年06月24日

直播整体介绍

文章主要从直播CDN的业务介绍，CDN整体技术架构，故障排查，CDN系统质量评估来做介绍分析

直播从技术架构上讲主要分以下三类：

传统三层的CDN架构：1推流边缘—2推流区域—3源站----2拉流区域----1拉流边缘
p2p直播：上行和传统直播架构差不多，下游主要通过p2p的方式将直播流进行分块再切片，然后通过矿机的方式分发piece片，拉流sdk端再进行还原
互动直播：后面有时间另外分析

以下主要是分析的传统直播的架构

直播业务整体介绍：

从业务功能属性上：

转码（直播视频主要以h264，音频aac为主），主要是降低视频码率
截图（主要用以房间的缩略图显示，一般一分钟或者五分钟粒度更新）
水印（水印其实也算转码的一部分，主要以直播画面某个角落显示存在）
直播转点播录制（有些直播需求，需要后续提供回看功能）
事件通知（开停播通知，方便统计主播在线时长以及app端开播通知）
禁播（主要用来鉴黄和暴力场面的时候进行实时禁播）

从直播平台类型上区分：

秀场：9158，奇秀，花椒等
游戏：网易CC，战旗，虎牙，龙珠等
体育：企鹅直播，盛力世家等
电视直播：百视通，云图，CCTV5等
企业直播：狮吼
教育：这类直播主要以很多在线教育类的培训机构和公司为主
其实现在很多大型的直播平台基本是综合直播，或者以某类主播为主其他主播
综合类直播平台：斗鱼，快手，熊猫，YY等

直播CDN技术架构

一套完整的CDN直播系统主要包过以下模块服务：

接入端sdk(pc,安卓，ios，H5)，为保证安全防止攻击或者盗流量，一般CDN接入的时候会采用防盗链，vhost黑白名单以及ip限制等防护措施
流媒体服务集群：
- 下面架构图主要是传统直播架构图，集群主要按照边缘-区域-源站部署。源站一般来说两个或者三个做主备，边缘主要分布在全国各个省市比较多；区域一般主要作为二级节点缓解源站的压力，主要部署在全国几个大区
- 互动直播架构跟此架构还有点差异，暂不分析
- p2p直播上行和传统直播架构差不多，主要区别在下行，一般都是音视频数据流切块，然后再切片。将片分发到不同的集群节点上，最后客户通过sdk接入的方式从不同的节点上取的当前流的片，获取片后进行还原。
调度服务：
转码服务(截图，转码，水印)
运营平台(流量计费，配置管理，API服务等)
- API服务：主要用来接收来自流媒体服务的开停播通知，禁播接口，鉴黄接口，提供等
- 配置管理：主要用来部署流媒体集群，以及后续的热更新配置下发
- 流量计费：可以按域名或者三元组粒度实时显示当前带宽状况
监控平台：agent采集节点负载信息，以及能查看当前流状态，链路节点信息方便快速定位问题，和实时告警等
数据库：主要用来保存流状态，打点，日志，以及集群的节点负载信息等，方便监控，计费和调度服务使用

以下是大致的完整架构图：

常见直播CDN服务器：

nginx-rtmp，srs, Live555, red5, FMS(adobe 收费), Open Streaming Server, crtmpserver等

参考链接：https://zhuanlan.zhihu.com/p/31602400

目前国内各大CDN厂商用的主要这两个居多：nginx-rtmp，srs

直播CDN调度方式主要以下三种

外部调度：http-302调度，http-dns调度，dns调度

调度方式	优点	缺点
DNS 调度	简单易用、用户无感知，兼容性好	调度策略非实时生效，调度不够精确，容易被劫持
http-302	实时调度、准确性高	客户端兼容性差，对延时敏感业务不适用
http-DNS	快速生效，稳定可靠，防劫持	精准度只能到省

调度方式各有各的优缺点，一般来说可以根据不同的业务来用不同的调度方式，或者配合使用

直播CDN协议介绍

直播CDN相关的协议主要rtmp、http-flv、hls、dash，除了rtmp，其余三种都是基于http协议的。

dash和hls有点类似都是将直播流切成小文件块Segments，然后通过一个个的http请求分别下载，这种方式其实是可以走点播小文件的方式分发，一般来说这类的直播延时比较高，抗抖动性效果比较好,而且支持多码率，dash目前国内支持的比较少，大厂好像只有网宿支持
http-flv 也是基于http，主要是将每帧数据封装成flv tag的方式进行传输

一般直播上游主要用的是：rtmp，下游是上面几种协议，以下是常见的协议对比：

直播CDN系统的质量评估

衡量一个系统常见指标主要从安全性、高可用性、可靠性。来判断一个系统是否稳定可靠。然而衡量一个直播CDN系统除以上几个点之外，另外还有以下几个指标：

首屏：指从主播推流到第一个观众播放的时间
卡顿率：一般不同客户区分粒度不一样，主要五分钟卡顿率和全天卡顿率
（以每次用户播放为分母，播放时长内卡顿一次，就计算为卡顿用户，所以日报会高于5分钟的数据统计）
延时：（播放过程中往往随着网络抖动，时延会慢慢增大，也有些是协议本身导致时延增大例如hls）
故障处理速度（出现问题不可避免，故障处理速度能反应出CDN团队对解决问题的能力，尽可能减少损失。）

直播系统性能优化：

主要从衡量直播系统的几个指标，带宽成本进行优化：

首屏优化：首屏时间计算=推流编码时间 + (主播-推流边缘)+ CDN链路时间 + (拉流边缘-播放器) + 播放器解码时间
优化思路：减少CDN内部时间
- 回源的时候改用http回源，http只要交互一次
- rtmp 三次握手改成一次握手，rtmp本身基于TCP协议，内部链路的时候可以改成一次握手
- vhost rewrite的功能.这主要是针对特定区域,主播和观众用同一个机房或者同机器可以覆盖的情况下，直接从推流节点去拉流，没必要再去回源，减少链路回源时间
成本优化：合并回源主要针对多进程和同机房同一路流的情况
- 多进程的合并回源：同台机器不同进程上，nginx-rtmp其实是每个进程都去回源，可以合并成一个进程回源
- 同机房合并回源：同机房内的不同机器节点，同一路流的时候，是每台机器都去回源，合并成一路去回源
  备注：合并回源的思路，根据三元组hash的方式[vhost/app/stream_name]，将不同的流hash到某一个进程/某一台机器回源来达到减少回源带宽，从而减少内部的回源成本
智能切换：主要针对链路节点挂了，或者网络抖动比较厉害的情况下自动切换机制
- 节点失效：下游回源或者上游转推的某一个切点失效的情况下，能自动去备源去推/拉数据，防止单点故障，保障服务的高可用
- 节点抖动频繁：CDN系统某个节点频繁抖动的时候，很容易导致下游观看的时候，buffer缓冲区空的情况，导致卡顿现象
  - 策略：可以根据出入的帧率差的情况，差值超过一定阈值判断为一次抖动并且记录一段时间内的抖动次数。特定时间内超过抖动次数进行主动切换。
    避免频繁抖动导致的卡顿，同时避免来回主动切换的情况
主动丢包：网络抖动的时候，很容易导致服务端数据堆积比较严重，适当的主动丢包可以减少观众延时。
- 丢帧策略：1）按优先级丢包，nginx-rtmp默认的丢包策略，先丢非关键帧，再丢关键帧，最后丢音频帧
  1) 按gop的方式丢帧，当buffer 缓冲区达到缓存关键帧个数，进行主动丢包，一直丢包知道后面来了关键帧不再丢。
协议优化：由于tcp重传，流量控制，拥塞机制的缺陷，很多厂商在底层进行协议算法优化，或者改成udp协议
- BBR算法
- 基于UDP的quic协议和kcp协议

常见直播CDN故障排查

直播系统常见的问题主要有以下几大类：

推流流失败
黑屏
卡顿
播放异常等情况

推拉流失败

推流失败的情况一般排查思路：主播推流域名–>推流参数设置–>主播推流机器性能–>推流节点服务是否正常

推流域名是否能正常解析
主播推流url拼写错误
Hosts配置域名被绑定（去除hosts绑定)
obs等推流工具参数设置问题，如编码没有选X264
主播端网络不稳定(手机推流，上行带宽差)
对应推流点服务是否正常
可以通过nc等工具检测服务的ip：port是否能通
Ping查看网络延迟情况等
主播机器性能故障（占cpu进程多，解码能力不足，有上传进程）
推流链接是否有误，ffmpeg或者obs推流看是否能推流

拉流失败基本思路：拉流域名参数url鉴权是局部还是大范围(网络抖动)边缘节点服务挂掉高负载

Url问题
flash问题 (更新flash播放器，换播放器检测)
hosts绑定域名指定ip
浏览器问题 (换浏览器播放)
覆盖问题 (覆盖调整)
内部链路问题
推流问题是否正常

黑屏

metadata信息是否正常，是否有视频sequence header
是否有视频帧数据
音视频时间戳是否单增
是否是视频数据（还有就是黑屏数据）

卡顿

主要分推流卡顿和拉流卡顿：看是全局卡顿还是部分卡顿。全局卡顿主要看上行和源站，局部卡顿看拉流区域和边缘节点情况

推流卡顿：
- 主播网络问题，主播推流机器是否负载过高
- 连接的推流点不合理。可能是调度问题
- 内部链路问题。
- 节点高负载（cpu、内存、io、带宽、机房带宽）
拉流卡顿：
- 丢包
- 高负载（cpu、内存、io、带宽、机房带宽）
- 节点覆盖问题

播放异常情况

主要是画面花屏，时间戳问题

画面花屏一般主要是传输过程中由丢帧导致，这类情况需要从全链路不同角色节点去排查
时间戳问题：一般会导致音视频不同步，这类一般是流媒体服务内部的问题，需要开发定位查询