WebRTC → 深入CDN推流

CDN推流、

阿里云CDN直播架构图解

大部分直播都是通过流式传输完成的，只有一少部分是通过文件加速分发完成的，在直播场景中，不管是推流还是播放，流式分发都是长链的，一场直播可能两三个小时，推流在这期间不会中断；

一般服务器与服务器之间的级联关系就构成了CDN直播网络，常见的架构就是主播推流到一个中间服务器后，中间服务器再通过回源拉流的方式将对应的流转发给发布流信息的最终服务器上，其中最终服务器相当于订阅者，而中间服务器相当于主播端的直接流发布者；
视频直播流会传输音频帧和视频帧，对于音频帧来讲，它每一帧都可以独立解码，播放器从服务器获取到任何一帧音频帧之后，都可以独立渲染，听到声音。

而视频帧分为视频关键帧和视频非关键帧两类，视频关键帧可以独立解码渲染，可以直接看到画面，其他非关键帧则做不到，它的解码依赖于前面的视频帧。视频关键帧的优点在于独立解码，但是缺点是携带的信息很多、很大。反之，视频非关键帧则很小，几K或者1K就可以解决。对于视频直播的任何一次播放，都是从视频关键帧开始发送，否则会先出现花屏，体验很差。

直播与视频转码的逻辑浅析

完整视频转码的工作流程
- 原视频文件->解封装->解码->处理->编码->封装->新视频文件
直播的处理流程
- 简化版：直播流数据获取 -> 直播转码 -> 直播流数据输出
  - 直播转码即视频转码，比如对视频进行水印追加、高清/流畅转换、码率限制、直播录像等
  - 直播转码程序可以是云服务(现有软件、云服务) 、自研程序 、流媒体服务软件(简单的转码可以，如SRS等)
  - 直播转码程序的意义在于一些高级功能，如直播倒计时、信号中断自动补针、导播等
- 直播与视频文件转码的最大区别是封装格式上，直播需要在直播源接收以及直播输出这一头一尾做特殊处理
- 因此在直播系统中是多了两个流媒体服务
  - 一个用于获取直播源数据，转码程序从这个流媒体服务中拉取视频流处理
  - 另一个用于为用户拉取视频流观看，转码程序会不断将处理完的视频数据推送到这个流媒体服务中。
- 流媒体服务浅析
  - 内部逻辑根据不同视频流协议而定，当在直播推流协议和直播观看协议相同时可以直播同一个流媒体服务
  - 一个流媒体服务既可以被推流也可以被拉流，甚至拉流和推流的地址是完全一致的
  - 实际上流媒体服务就是视频流数据的额中转站，流媒体服务会在内存中实时存储视频流的一部分数据，随着时间推移，数据会被循环覆盖
当存在大量观看人数时，就需要视频直播CDN了
- 直播CDN可以看做是流媒体服务，只是其有许多边缘节点，分摊了许多请求压力，这样对于源直播服务压力就小很多了
- 直播CDN中，视频转码软件将视频流数据输出到直播CDN上即可，一般是通过RTMP协议推送到CDN服务上的
- 一般的直播CDN是不支持转码服务的，需要额外的直播转码云服务或自研的转码软件

低延时海量高并发流媒体的主要挑战

需要具备很强的协议兼容能力和架构自适应能力
- 低延时流媒体系统，需要满足包括RTC实时音视频、直播、低延时直播、loT机器人、嵌入式设备等各种场景下的需要高强度要求
需要具备很强的弹性扩缩容能力
- 随着流媒体系统承载的场景越来越丰富，整个系统需要承载的并发也越来越大，包括单频道的百万并发，以及晚高峰的额流量蜂拥等情况
复杂多变的网络互联场景
- 在全球化的影响下，需要考虑到各种情况下的复杂通信的网络情况

浅析CDN及推流相关

CDN(Content Delivery Network)即内容分发网络，是一个策略性部署的整体系统，将源站内容分发至靠近用户的加速节点，使用户可以就近获取内容，解决Internet网络拥挤的情况，提供用户访问的相应速度和成功率，从而提升项目的用户体验；

CDN也是现在视频流媒体的支柱，大多数流媒体服务依赖CDN进行日常运营，从而确保高QoS(Quality of Service，服务质量：衡量视频传输基础设施的性能，包括第三方或者内部 CDN、跟踪数据（如总体吞吐量、延迟、错误率以及缓存命中率)/QoE(Quality of Experience，体验质量：终端用户主观感知到的应用程序或者服务的整体可接受性。它包括完整的端到端系统效应（客户、终端、网络、服务基础设施等），有可能受到用户期望和环境影响)和高效的全球流媒体，同时确保使其流媒体成本得以控制；

使用CDN做流媒体服务的理由
- 可以提高视频流的可靠性
  - 可以通过在不同位置的多个服务器缓存(存储)内容并防止单点故障，从而实现提高视频流服务的可靠性和可用性
- 跨多个地区的额可靠流媒体
  - CDN服务器在不同地理位置的多个服务器上缓存内容，减少每个请求的往返时间
- 可拓展的视频流
  - 使用CDN时，可以轻松拓展服务，尤其在一些流量高峰期的情况下会起到至关重要的作用
  - 流量高峰问题、直播流畅体验问题都可以在CDN中得到很好的解决
    - CDN作为内容分发网络，借助负载均衡系统将内容推送到接近用户的边缘节点，使得用户就近取得资源大大增加了用户的访问速度和访问的稳定性
    - CDN其基本的思路就是尽可能的避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使得内容传输更快、更稳定
- 减少启动、缓冲的时间
  - 为了应对直播业务对质量和实时性的要求，CDN需要在短时间内找到并建立一条完整的传输链路，对于链路稳定性由一定的要求
  - 当内容缓存在靠近用户的CDN位置时，播放器接收视频需要的时间会明显减少
  - 当不使用CDN时，播放器必须联系原始服务器(有可能在不同的地区)以获取清单和片段，从而增加了往返的时间；
- 可以减少DDoS攻击
  - CDN 可以在恶意流量到达源服务器并使其不堪重负之前阻止它，从而帮助抵御分布式拒绝服务 (DDoS)攻击。
  - 此外，大多数CDN允许您设置规则以拒绝来自特定客户端或 IP 地址集的请求（即阻止或黑名单流量）
- 减少源服务器的负载，节省开发成本
- 流媒体分析和日志报告
CDN直播中常用的流媒体协议
- RTMP(Real Time Messaging Protocol)是基于tcp的，由Adobe公司为Flash播放器和服务器之间音视频传输开发的开放协议 → 流式传输
  - 📢：RTMP协议目前主流浏览器都是不支持的(禁用了Flash)
  - RTMP协议深度解析：从原理到实践，掌握实时流媒体传输技术
- HLS(Http Live Streaming)是基于HTTP的流媒体协议，基于HLS的直播流URL是一个m3u8的文件，里面包含了若干个小视频TS文件 → 文件加速传输
- FLV()是基于HTTP流，是在RTMP和客户端之间套了一层转码的过程，可以更好的穿透防火墙 → 流式传输
CDN直播业务大致流程
- 主播推流
  - 一般采集多种数据(屏幕、摄像头、拓展内容)，采集后一般还有其他的额外功能如美颜、水印、滤镜等推流前的处理，然后使用OBS或者其他的推流软件推到CDN的节点中
  - 一般会存在一个调度服务器，然后由调度服务器给主播或观众返回对应的推流和拉流域名，实际最终交互都是和CDN进行交互，调度服务器只是起了中间作用(找到用户最近的CDN节点)
  - 主播开始推流后，客户端会向服务器发起RTMP的握手请求，握手成功后开始检查鉴权，鉴权通过后边缘的服务器会主动向直播中心进行推流，除了一些不可控的外界因素(网络抖动、节点负载异常等)外都会正常将流推到直播中心
- 直播中心接受流
  - 推流到CDN，对于云存储来说就是文件上传的过程
- 边缘节点为用户提供分发
  - 拉流的过程中，用户会向边缘节点发起一个播放流的请求，边缘节点进行查流，看自己是否存在流，如果没有回递归到直播中心进行拉流，如果流还是不存在，则返回404；

深入分析CDN推流技术

CDN直播技术利用的原理就是：内容分发、动态调整(负载均衡)、实时监控
CDN直播的技术的优势是：低延时、高并发、稳定性和节省宽带

CDN推流原理解析

要想用于推流，推流端需要将音视频数据使用传输协议进行封装，变成流数据，通常的流传输协议有RTSP、RTMP、HLS等，RTMP传输的延时一般在1-3秒，适用于实时性非常高的场景；

按需深入分析

如何解决调度延迟控制(延迟最好不超过50ms)
- 基本原则：需要预先准备好相应策略，且调度接入位置要尽量靠近用户侧，因此一般可以包含策略推送、策略缓存和异步更新三种功能
- 策略推送：在资源调度系统生成好调度策略后，通过推送的方式直接推送到接入层，接入层不主动调用其他系统，直接使用推送的调度计划给业务方，接入层没有业务处理延迟
- 策略缓存：在接入层接收到调度计划之后做内存缓存，本地不落磁盘，只有推送或异步更新触发缓存更新，调度请求直接返回缓存数据
- 异步更新：是在接口主动定时向资源调度发起请求获取调度数据，防止推送失败
CDN常用架构 CDN架构设计比较复杂，主要包括源站、缓存服务器、智能DNS。客户端等几个部分；
- 频道与流管理服务
  - 该服务中需要存在RTC调度、Live调度、MCU调度和同意媒体调度服务
- 源站：指发布内容的原始站点
  - 添加、删除和更改网站的文件都是在源站上进行的
  - 缓存服务器抓取的对象也全部来自于源站
  - 对于直播而言，源站为主播客户端
- 缓存服务器：是直接提供给用户访问的站点资源，由一台或多台服务器组成
  - 用户发起请求时，他的访问请求被智能DNS定位到离用户最近的缓存服务器，定位是循序渐进的，直到源站；
- 智能DNS：是整个CDN技术的核心
  - 主要根据用户的来源和当前缓存服务器的负载情况等，将其访问请求指向离用户较近且负载较小的缓存服务器
  - 通过智能CDN解析，可以让用户访问服务商下负载较小的服务器，可以消除网络访问慢的问题，达到加速的作用
- 客户端：即发起访问的普通用户
  - 对于直播来说就是观众客户端
CDN整体架构图解
- 主播开始进行直播，向智能DNS发送解析请求；
- 智能DNS返回最优CDN节点IP地址；
- 主播端采集音视频数据，发送给CDN节点，CDN节点进行缓存等处理；
- 观众端要观看此主播的视频，向智能DNS发送解析请求；
- 智能DNS返回最优CDN节点IP地址；
- 观众端向CDN节点请求音视频数据；
- CDN节点同步其他节点的音视频数据；
- CDN节点将音视频数据发送给观众端；
CDN架构常见问题及解决方案
- 网络延时：
  - 延时表现有：
    - 主播端采集和对视频的编码耗时
    - 观众端对视频进行解码的耗时
    - 网络传输中的延时
  - 大致计算逻辑：
    - 流从主播端到观众端需要经历的CDN节点间对应的耗时之和
    - 还包括传输过程中的逻辑交互，如包的重传及确认、缓存相关的逻辑处理耗时等
- 网络抖动
  - 是指数据报的到达顺序、间隔和发出时间不一致导致的播放卡顿现象
  - 一般是在数据包正常发送过程中遇到了网络抖动拥塞导致当前包的延时发送和到达，从而导致了卡顿的现象产生
  - 低延时的核心问题是避免网络拥塞，一旦网络中存在大量Buffer，就会导致延时变大，此时就需要通过拥塞控制算法来解决。拥塞控制算法的核心目标是：让发送速率逼近可用速率，同时保持尽可能低的队列占用率
- 网络丢包
  - tcp是面向连接的，可靠的、基于字节流的传输通信协议，服务端和客户端都可以发起断开连接的请求；其定义的是数据传输和连接方式的规范
    - 基于tcp的直播方案在丢包2%的时候就会明显的卡顿，达到30%经常已经断开连接，无法进行直播
    - 基于UDP的SD-RTN方案可以针对用户的网络使用更多的策略模型和技术，可以实现在丢包30%时依然可以进行正常的直播
  - HTTP是互联网上应用最广泛的网络协议，其是建立在tcp协议之上的一种应用，是定义传输数据的内容的规范
- 复杂场景 → 连麦的技术解决方案
  - 多路RTMP流实现有连麦的时候，主播和连麦者都分别推一路RTMP流到CDN，CDN再将这两路RTMP流分发给观众端，观众端再将两路RTMP流合成一个画面；
    - 优点：实现简单
    - 缺点：
      - 延时成倍增加，这样在实时交互的场景中是无法接受的
      - 主播与连麦者交互时声音会产生干扰，形成回音
      - 观众端需要接受两路流，宽带和流量消耗较大，且接收到两路RTMP流后需要进行合流解码播放，消耗CPU等资源较严重
  - 主播与连麦者P2P 主播将自己和连麦者的视频进行合并，然后在推到CDN上，CDN再发送给观众，此时观众接受到的也是一路RTMP流
    - 优点：
      - 主播和连麦者之间采用P2P连接，延迟较小
      - 可以解决声音干扰的问题，消除回音
    - 缺点：
      - P2P在某些网络下无法进行穿透，导致主播和部分连麦者无法进行连麦交互
      - 对主播端的网络和设备有较高要求
        
        主播需要上传两路流：一路P2P与连麦者进行交互，一路使用RTMP推到CDN
        
        且需要实时下载连麦者P2P发送过来的一路流
        
        还需要进行多路视频的编码、解码等操作
      - 只能有一个连麦者，不支持一对多连麦
  - 服务器端合流主播和连麦者都将视频推送到CDN中，然后CDN内部对这几路视频进行合流，再将其发送给观众端
    - 优点：
      - 主播和连麦者分别将各自的视频采用RTMP推送到CDN，可以保证延迟较小
      - 两路流的合并工作在CDN上进行，因此对于主播端的网络和设备性能要求不用很高
      - 没有声音干扰问题
      - 可以支持多个连麦者进行一对多连麦场景
    - 缺点：
      - 由于多路流的后续合并操作都在CDN中进行，因此对CDN的要求较高，且实现逻辑较复杂，暂时没有现有的CDN支持这种方案
      - SD-RTN技术架构方案图解
      - SD-RTN本质上是一个实时传输网络，是基于实时传输设计的UDP协议，用户的数据在网络单元内部和传输线路上都是以实时交换的方式进行传输的，UDP实现的传输方案不会因为前一个包的丢失或延迟导致后续报的延迟送达，而丢包问题可以采用对延迟更友好的方式修复或补偿出来，从而保证最低延迟，另外SD-RTN是基于自定义路由，选择最优传输路线，直接在端到端之间进行传输，从而降低了延迟，同时安全性也更高，适用于极低延时的互动场景；
        
        其延时可以从基于tcp的方案的数秒降低到数百毫秒，CDN的延时也在数秒左右
      - CDN是存储转发结构，设计目的是在各个边缘节点缓存待分发内容，结构上是源站到观众是伞状多级缓存放大方式；是将内容缓存在服务器中，再将内容就近下发，因此更适合于做内容分发，一对多，对延迟要求不高的场景

WebRTC → 深入CDN推流

CDN推流、

低延时海量高并发流媒体的主要挑战

浅析CDN及推流相关

深入分析CDN推流技术

CDN推流原理解析

按需深入分析

推荐文献