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

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

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

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

从业务功能属性上：

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

从直播平台类型上区分：

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

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

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

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

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

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

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

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

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

• http-flv 也是基于http，主要是将每帧数据封装成flv tag的方式进行传输

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

衡量一个系统常见指标主要从安全性、高可用性、可靠性。来判断一个系统是否稳定可靠。然而衡量一个直播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协议

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

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

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

• 推流域名是否能正常解析
• 主播推流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、带宽、机房带宽）
  • 节点覆盖问题

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

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