直播 CDN 分发网络(基本业务)

传统直播一般是基于 CDN 网络进行分发，可支持大规模并发(并发数取决于 CDN 网络容量)。与传统 CDN 的大文件，小文件分发不同，由于主播分布区域分散，一般除了提供播放端的下行分发网络外，还提供上行主播推流汇聚网络。只有一些直播内容资源集中的业务方，会要求直播 CDN 直接回自己的源站，如电视台。

上行汇聚

目前传统直播 CDN 上行一般使用 RTMP 协议，当然也有一些使用 UDP(UDP 方式由于需要 SDK 配合，目前行业内有人在做，但是需要绑定 SDK)。另外国外还有使用 http-ts 的方式进行推流的，可参见 nginx-rtmp 项目大神开源的 nginx-ts-module。当然，目前使用这种方式，关键问题还是在于端的支持问题，而该开源项目目前只支持 HLS 和 Dash 的播放。

除了主播推流以外，还有一种方式即从汇聚点到业务方源站去拉流的方式

下行分发

目前下行分发一般使用的协议，rtmp，http-flv，hls 三种协议。这三种协议的优劣，网上已经有很多文章了，一般从终端兼容性，延迟，首屏几个维度去考虑，这里就不在进行比较。

rtmp 和 http-flv

由于 rtmp 协议在发送数据前交互次数较多，比较追求首屏的直播平台一般都会选择 http-flv 协议作为下行分发协议，线上环境测试效果平均会增加 100-200 ms 左右的时间，网络越差，这个值越大。

rtmp 和 http-flv 的延迟可以做到 3s 以内，但是由于网络环境的复杂，过低的延迟会导致卡顿率的提升，所以一般 CDN 会用户接入时，给用户多发几秒钟的数据(一般是 5-8s)，填充播放端缓冲区，来抗网络端的抖动。细节技术会在后面的文章中介绍

hls

hls 对 Android 端和 IOS 端支持较好，并且对 P2P 的支持也较好，一般对延迟要求不高的直播平台(如体育赛事)会选用这个协议。

hls 的延迟一般和切片大小有关，一般切片是 6-8s 一个片，这个大小对一般主播推流 GOP 适配最好。过高会导致延迟加大，过低，可能切片里就没有关键帧。一般 m3u8 文件里会有 3 个 ts 文件，播放器会在下完两个片以后，开始播放，并且同时下第三个片。因此一般 hls 的时延在 15s 左右。

当然如果用户调小 GOP(1s)，CDN 端将切片方式配置为按 GOP 切片的方式，HLS 实际也可以做到 5s 以内延迟的。当然坏处就是会导致卡顿率变高

其它协议

dash 和 hds

类似 hls 的还有 dash 和 hds。dash 在国外用得比较多，实际原生的 nginx-rtmp 就支持 dash，只不过国内用得比较少。hds 是 adobe 自己搞的切片协议，一般鲜有开源项目支持(SRS 支持，但是应该没有商用 CDN 使用)

http-fmp4

由于 Adobe 宣布退出 Flash，目前也有平台在研究一些替代技术，如 B 站开源的 flv.js，就是在页面上使用 js 将 flv 转封装为 fmp4，然后可以使用 H5 进行观看

目前个人也在研究在 CDN 端加入 http-fmp4 的支持，其实问题还是挺多的。fmp4 虽然可以支持流式播放，但是与 flv 和 ts 这种天生就为流式传输而生的协议不同，fmp4 实际上还是问题比较多的。

fmp4 的视频头是放在 moov 中的(stsd box 下)，在直播中会遇到变码率的情况，重发视频头，这种对于 fmp4 实际上是不支持的
一个 moof 放几帧数据的问题，由于 mp4 的 box 是按照 box 长度 + box 标签 + box 内容，所以必须知道后面所有数据帧的长度，才能打包一个 moof。这样势必就需要收到好多帧，才能打一个 moof 包，这种方式实际对直播来说是不好的(dash 不存在这个问题)。当然也可以一个数据帧打一个 moof 包，但是取决于是否接受每帧前面加一个 moof 的开销

补充：nginx-rtmp 中的 dash 打包也是使用的 fmp4 方式，一般是一个 GOP 或者 10M 数据打成一个 moof

UDP

udp 方式，和前面提到的上行使用 UDP 分发一样，下行使用 UDP 同样存在着标准化问题，同样存在 SDK 配合问题。当然，对于直播来说，追求卡顿率，延迟的极致，UDP 后续必然是一种趋势。后面我们会在互动直播中详细讨论

转码

CDN 一般会提供转码服务，一般按照分类可分为在线转码和离线转码两部分

在线转码

一般我们会把截图，水印，直播转码归为在线转码，直播转码又分为主动转码和被动转码两种

直播的截图，一般用于一些审核业务，如直播鉴黄。还有直播平台上，主播封面的贴图等(这种贴图一般会定时更新)
水印，就是在主播的视频中加入直播平台的标签，类似于电视台的台标。这种方式可能是按需的，如一些主播使用直播平台提供的直播工具，在推流出来前就可以打上水印，但是一些主播使用 OBS 推流，就需要 CDN 来加水印。可以通过加参数的方式，告诉 CDN 是否需要加水印
主动转码，即用户推流到 CDN 后就按照客户需求将源流转为几路子码流，播放端可以根据网络情况选择播放码率(如标清，高清，超清等)。这种方式，由于子流已经转出，能够保证首路播放的首屏时间。但是，并不是所有主播都有人观看，实际大的直播平台，有很大比例的主播是没有观众的，转码又是一种很耗资源的业务，因此主动转码对 CDN 的计算资源消耗是很大的
被动转码，即有观看子码流再转码，这种方式会大大降低计算资源的消耗，一般大的直播平台都会选用被动转码的方式，因为对于大主播，第一个人的首屏影响可以忽略不计

对于直播转码一般还会有阶梯转码，如根据主播码率决定要转几档。对于被动转码，可以选择只转出常用的几种码率，对于不常用的码率选择按需的方式。这些都是 CDN 对直播资源的优化处理方式

离线转码

离线转码在直播中主要是对直播录制文件的处理

直播转点播，和直播不同，点播一般更常用的协议是 mp4 和 hls，而直播一般录制使用的是 flv 和 hls。因此需要在录制后将录制文件转封装成 mp4 或 hls
轮播，类似于电视台体育赛事录播功能，将直播内容进行剪辑后，在某个时间段(一般是主播下播时间)循环播放，一般使用录制文件转推直播流的方式
延播，一些直播内容，业务方需要进行审核，审核完成以后再直播出来，如果有问题，及时掐断，有问题的内容就不会再播放出来。这个时间一般在 10 分钟以上，一般直播引擎使用内存进行数据 cache，因此对这种长时间的延播，一般也是使用定时将录制文件重新转成直播流的方式

FLV+H.265(HEVC)

官方标准 FLV 实际是不支持 H.265 的，但是目前很多直播平台为降低带宽成本，CDN 也应业务需求推出了 FLV+H.265 的支持，一般定义的 CodecID 是 12，转码需要对 ffmpeg 进行修改，参考

实测效果，H.265 的转码比 H.264 大很多，对终端的要求也比较高，目前应用还不是很广泛，应该还处于技术孕育阶段

录制

直播的录制一般可以使用 flv 和 hls 两种，nginx-rtmp 的 record 模块支持 flv 的录制，hls 模块支持 hls 的录制(配置不清除分片)。

为什么不用 mp4，主要取决于 mp4 的封装结构和直播特性的兼容问题：

一般支持 mp4 的 fast-open，会把 moov 头放在文件前面，mdat 放在后面。由于 mp4 对各平台 H5 支持的缘故，现在视频平台一般会把 mp4 作为点播的源的封装格式。播放器只要下载完 moov 头，就可以根据 moov 中 stco 标记的每一帧的位置对视频进行拖动

但是，在直播中，数据帧是实时增加的，这样就导致 moov 头会一直变，而无法确认后面数据帧的偏移位置，这样就无法确认 moov 头到底有多大，那紧接着 moov 的 mdat 在整个 mp4 中的偏移量就无法确定，那如何去确认 moov 中 stco 的偏移量

因此 CDN 一般录制更常用的就是对流式传输比较亲和的 flv 和 hls。当然，mp4 也可以像 HLS 一样分片存，但是我们更倾向于后两种方式。而对直播转点播 mp4，通常都是在完成直播后再全部转封装为 mp4，或者播放超过一段时间后转一个 mp4 文件，如 1 小时。

时移

目前时移多使用 HLS 的方式，也有人用 flv 的，但是需要对 flv 进行大文件分片。在直播中，时移一般需要配合录制一起使用

鉴权

鉴权分为上行鉴权和下行鉴权

直播的鉴权一般有以下几种：

referer 鉴权，这种主要是下行 http 用，根据 referer 白名单或黑名单方式。比较容易破解
签名算法的方式，上行和下行皆可使用。一般是直播平台根据用户的 key 和 timestamp 参数，加上用户的 secret 算出一个 signature，和用户带上来的 signature 进行比较。timestamp 保证 signature 在一定时间(一般是分钟级别)范围内有效。当然直播平台不可能把 key 放到客户端代码中，一般直播平台会有一套从服务端获取 signature 的方法。
回源鉴权，上行和下行皆可使用。当请求到 CDN 后，CDN 向业务平台 API 服务器进行请求，由业务平台判断是否放行。下行为保证首屏，一般会使用异步的方式，即向向业务平台 API 服务器发送鉴权请求的同时先放行播放端。拿到鉴权结果后，如果是禁播，再通过禁播接口对观众进行断流处理

一般 CDN 可以支持以上一种或多种鉴权进行使用

其它业务

其它业务还包括断流，禁播，开停播通知，观看人数统计等

欢迎访问我的 git doc