从Html5直播到互动直播，看直播协议的选择

目前，国内主流的直播协议有HLS、RTMP、HTTP FLV，适用于不同的直播场景。

一、HLS、RTMP与HTTP FLV

1.HLS

HLS 全称是 HTTP Live Streaming, 是一个由 Apple 公司实现的基于 HTTP 的媒体流传输协议. 它跟 DASH 协议的原理非常类似. 通过将整条流切割成一个小的可以通过 HTTP 下载的媒体文件, 然后提供一个配套的媒体列表文件, 提供给客户端, 让客户端顺序地拉取这些媒体文件播放, 来实现看上去是在播放一条流的效果。

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的简单对比

三、总结

RTMP格式目前在国内是用比较多，国内CDN厂商也多支持RTMP协议。HLS作为苹果提出的直播协议，在iOS端占据了不可撼动的地位，同时又便于传播。HTTP FLV使用类似RTMP流式协议的HTTP长连接，需由特定流媒体服务器分发的，兼顾两者的优点。

又拍云一站式直播解决方案基于又拍云CDN，支持 RTMP、HTTP-FLV 和 HLS协议，并且通过智能调度、链路保障、追帧处理、丢帧处理以及业界首创的 HLS+ 技术，将RTMP、HTTP FLV直播延迟控制在1秒内，将HLS协议控制在4秒左右。