CDN基础知识——rtmp，flv（http-flv），hls协议详解

最近在搞CDN方面的知识，因此学习音视频推拉流。建议先从个协议开始学起。

1. 推拉流

1.1 什么是推流

推流，指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。

“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。

最后通过一定的Qos算法将音视频流数据推送到网络端，通过CDN进行分发。

Qos算法：https://www.cnblogs.com/jianhaoscnu/p/13380927.html

在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。

另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。

视频一开始会由两个端采集，一个是视频输入口，是一个音频输入口。然后，采集的数据会分别进行相关处理，简而言之就是，将视频/音频流，通过一定的手段转换为比特流。最终，将这里比特流以一定顺序放到一个盒子里进行存放，从而生成我们最终所看到的，比如，mp4/mp3/flv 等等音视频格式

1.2 什么是拉流

拉流是指服务器已有直播内容，根据协议类型（如RTMP、RTP、RTSP、HTTP等），与服务器建立连接并接收数据，进行拉取的过程。

拉流端的核心处理在播放器端的解码和渲染，在互动直播中还需集成聊天室、点赞和礼物系统等功能。

拉流端现在支持RTMP、HLS、HDL（HTTP-FLV）三种协议，其中，在网络稳定的情况下，对于HDL协议的延时控制可达1s，完全满足互动直播的业务需求。

RTMP 是 Adobe 的专利协议，开源软件和开源库都支持的比较好，延时一般在1-3秒。

HLS 是苹果提出的基于HTTP的流媒体传输协议，优点是跨平台性比较好，HTML5可以直接打开播放，移动端兼容性良好，但是缺点是延迟比较高。

对于 WEB H5 端拉流直播 建议还是使用 HLS ，兼容性较好，延迟其实还好。

2. 协议介绍：

国内常见的直播协议有几个：RTMP、HLS、HTTP-FLV

2.1 HLS

HLS 全称是 HTTP Live Streaming。这是 Apple 提出的直播流协议。目前，IOS 和 高版本 Android 都支持 HLS。

HLS 主要的两块内容是 .m3u8 文件和 .ts 播放文件。接受服务器会将接受到的视频流进行缓存，然后缓存到一定程度后，会将这些视频流进行编码格式化，同时会生成一份 .m3u8 文件和其它很多的 .ts 文件。

其中 .m3u8 作为索引文件（确保包的顺序）

跨平台性比较好，HTML5可以直接打开播放，移动端兼容性良，就是延迟比较高。

HLS 支持的功能，并不只是分片播放（专门适用于直播），它还包括其他应有的功能。

• 使用 HTTPS 加密 ts 文件
• 快/倒放
• 广告插入
• 不同分辨率视频切换

HLS 的弊端：

由于 HLS 是基于 HTTP 的，所以，它关于 HTTP 的好处，我们大部分都了解，比如，高兼容性，高可扩展性等。不过正由于是 HTTP 协议，所以会在握手协议上造成一定的延迟性。HLS 首次连接时，总共的延时包括：

• TCP 握手，
• m3u8 文件下载，
• m3u8 下的 ts 文件下载。

总而言之，HLS 之所以能这么流行，关键在于它的支持度是真的广，所以，对于一般 H5 直播来说，应该是非常友好的。

2.2 RTMP：

RTMP，全称 Real Time Messaging Protocol，即实时消息传送协议

Adobe公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的私有协议,未完全公开。

纯 RTMP 使用 TCP 连接，默认端口为 1935（有可能被封）。

既然是 Adobe 公司开发的（算吧），那么，该协议针对的就是 Flash Video，即FLV。

不过，在移动端上，Flash Player 已经被杀绝了，那为啥还会出现这个呢？

因为它主要是针对 PC 端的。

RTMP 出现的时候，还是 零几 年的时候，IE 还在大行其道，Flash Player 也并未被各大浏览器所排斥。那时候 RTMP 毋庸置疑的可以在视频界有自己的一席之地。

RTMP 由于借由 TCP 长连接协议，所以，客户端向服务端推流这些操作而言，延时性很低。

它会将上传的流分成不同的分片，这些分片的大小，有时候变，有时候不会变。

默认情况下就是，64B 的音频数据 + 128B 的视频数据 + 其它数据（比如 头，协议标签等）。

但 RTMP 具体传输的时候，会将分片进一步划分为包，即，视频包，音频包，协议包等。因为，RTMP 在进行传输的时候，会建立不同的通道，来进行数据的传输，这样对于不同的资源，对不同的通道设置相关的带宽上限。

该协议是一个基于TCP的协议族，是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。

支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。

现在推流协议各大云厂商基本都是直接支持 rtmp 。

拉流用 rtmp 的话就不太现实了，现在对 flash 支持都不友好了。

2.3 HDL (HTTP-FLV)

HTTP-FLV 和 RTMPT 类似，都是针对于 FLV 视频格式做的直播分发流。

但，两者有着很大的区别：

• 相同点：
  • 两者都是针对 FLV 格式
  • 两者延时都很低
  • 两者都走的 HTTP 通道
• 不同点：
  • HTTP-FLv
    • 直接发起长连接，下载对应的 FLV 文件
    • 头部信息简单
  • RTMPT
    • 握手协议过于复杂
    • 分包，组包过程耗费精力大

因为 RTMP 发的包很容易处理，通常 RTMP 协议会作为视频上传端来处理，然后经由服务器转换为 FLV 文件，通过 HTTP-FLV 下发给用户。

总结

• RTMP协议比较全能，既可以用来推送又可以用来直播，其核心理念是将大块的视频帧和音频帧“剁碎”，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。

• HTTP-FLV协议由Adobe公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种极致的简洁，在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适。

• HLS协议：苹果推出的解决方案，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS的一般延迟在10-30s左右）。相比于FLV， HLS在iPhone和大部分android手机浏览器上的支持非常给力，所以常用于QQ和微信朋友圈的URL分享。

RTMP ，HLS，HTTP-FLV 协议对比

	优点	缺点	延时	特点	适合端
RTMP	延时低	高并发下不稳定	iOS 平台要开发支持相关协议的播放器 使用非标准TCP端口	1S～3S	TCP 长连接
HLS	跨平台 可通过html5解封包播放	延时高	> 10S	HTTP 短连接	PC端 ， 移动端
HTTP-FLV	延时低 可通过html5解封包播放	需要集成SDK才能播放	1S～3S	TCP 长连接	PC端

参考链接：
https://driverzhang.github.io/post/%E7%9B%B4%E6%92%AD%E5%8D%8F%E8%AE%AErtmphlshttp-flv/