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

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

1、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）

2、直播协议HLS、RTMP与HTTP FLV的简单对比

3、总结

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

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

推荐阅读：

WebSocket+MSE——HTML5 直播技术解析

让Chrome看不了WWDC直播的HLS技术详解

技术干货|HLS 协议详解及优化技术解析