直播CDN架构内幕

直播整体介绍

文章主要从直播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、带宽、机房带宽)
    • 节点覆盖问题

播放异常情况

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

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

相关工具:

  • rtmpdump: rtmp协议流分析,可以将rtmp数据下载下来。
  • flvparse:分析flv格式的数据
  • ffprope: 可以查看每帧的具体信息,时间戳,帧大小,帧类型等信息
  • 压测工具:st-load
  • 播放器类: ffplay,vlc,cutv