目前，国内主流的直播协议有HLS、RTMP、HTTP FLV，适用于不同的直播场景。
一、HLS、RTMP与HTTP FLV
1.HLS
HLS 全称是 HTTP Live Streaming, 是一个由 Apple 公司实现的基于 HTTP 的媒体流传输协议. 它跟 DASH 协议的原理非常类似. 通过将整条流切割成一个小的可以通过 HTTP 下载的媒体文件, 然后提供一个配套的媒体列 表文件, 提供给客户端, 让客户端顺序地拉取这些媒体文件播放, 来实现看上去是在播放一条流的效果。
△HLS 原理架构图
HLS 协议基于 HTTP，主要内容是关于 M3U8 这个文本协议的。其实生成和解析都非常简单， HLS 的请求流程是：
- http 请求 m3u8 的 url。
- 服务端返回一个 m3u8 的播放列表，这个播放列表是实时更新的，一般一次给出5段数据的 url。
- 客户端解析 m3u8 的播放列表，再按序请求每一段的 url，获取 ts 数据流。
HLS 的优势
- 客户端支持简单, 只需要支持 HTTP 请求即可, HTTP 协议无状态, 只需要按顺序下载媒体片段即可.
- 使用 HTTP 协议网络兼容性好, HTTP 数据包也可以方便地通过防火墙或者代理服务器, CDN 支持良好.
- Apple 的全系列产品支持, 由于 HLS 是苹果提出的, 所以在 Apple 的全系列产品包括 iphone, ipad, safari 都不需要安装任何插件就可以原生支持播放 HLS, 现在, Android 也加入了对 HLS 的支持.
- 自带多码率自适应, Apple 在提出 HLS 时, 就已经考虑了码流自适应的问题.
HLS 的劣势
- 相比 RTMP 这类长连接协议, 延时较高, 难以用到互动直播场景.
- 对于点播服务来说, 由于 TS 切片通常较小, 海量碎片在文件分发, 一致性缓存, 存储等方面都有较大挑战.
2. RTMP
RTMP协议是一个互联网TCP/IP五层体系结构中应用层的协议。RTMP协议中基本的数据单元称为消息。当RTMP协议在互联网中传输数据的时候，消息会被拆分成更小的单元，称为消息块。RTMP传输媒体数据的过程中，发送端首先把媒体数据封装成消息，然后把消息分割成消息块，最后将分割后的消息块通过TCP协议发送出去。接收端在通过TCP协议收到数据后，首先把消息块重新组合成消息，然后通过对消息进行解封装处理就可以恢复出媒体数据。
RTMP的优势
- 速度快，误码率低，延迟低
- RTMP 是专为流媒体服务而生，协议在制定的时候就考虑到很多底层的优化
- 消息块的传输能够提供更加稳定的直播环境，在硬件上要求会更高，但是却能够缓解http的繁琐的传输介质。
RTMP的劣势
- 不支持Html5传播、浏览器推送
- 基于TCP协议,虽然开发难度大，推广度还不够，对于开发人员来说门槛比较高。
- 对硬件要求相较于HLS较高
3.HTTP FLV
HTTP FLV是一种将直播流模拟成FLV文件，通过HTTP协议进行下载的模式来实现流媒体传输的协议。
HTTP FLV 结合了 RTMP 的低延时，以及可以复用现有HTTP分发资源的流式协议。它的实时性和RTMP相等，与RTMP相比又省去了部分协议交互时间，首屏时间更短，可拓展的功能也更多。
HTTP FLV的优势
- 可以在一定程度上避免防火墙的干扰
- 可以很好的兼容HTTP 302跳转，做到灵活调度
- 可以使用HTTPS做加密通道
- 很好的支持移动端（Android，IOS）
二、直播协议HLS、RTMP与HTTP FLV的简单对比
|
协议 |
传输方式 |
视频封装格式 |
延时 |
数据分段 |
HTML5直播 |
应用场景 |
|
HLS |
HTTP流 |
Ts文件 |
10-30s |
切片 |
支持 |
H5直播，游戏直播 |
|
RTMP |
tcp流 |
flv tag |
2s |
连续流 |
不支持 |
互动直播 |
|
http flv |
HTTP流 |
flv |
2s |
连续流 |
支持 |
互动直播 |
三、总结
RTMP格式目前在国内是用比较多，国内CDN厂商也多支持RTMP协议。HLS作为苹果提出的直播协议，在iOS端占据了不可撼动的地位，同时又便于传播。HTTP FLV使用类似RTMP流式协议的HTTP长连接，需由特定流媒体服务器分发的，兼顾两者的优点。
又拍云一站式直播解决方案基于又拍云CDN，支持 RTMP、HTTP-FLV 和 HLS协议，并且通过智能调度、链路保障、追帧处理、丢帧处理以及业界首创的 HLS+ 技术，将RTMP、HTTP FLV直播延迟控制在1秒内，将HLS协议控制在4秒左右。