一、前述
HttpFlv（http+flv ）：将音视频数据封装成FLV格式，然后通过 HTTP 协议传输给客户端。
HLS（HTTP Live Streaming）：工作原理简单来说就是把一段视频流，分成一个个小的基于HTTP的文件来下载。当媒体流正在播放时，客户端可以根据当前网络环境，方便地在不同的码率流中做切换，以实现更好的观影体验。
hls的出现是为了解决苹果原生环境中的流媒体播放，这个协议可以方便的让Mac和iPhone播放视频流，不依赖Adobe，更不用去管什么标准委员会。
就苹果来说，HLS经过10年的发展，RFC 8216发布了HLS的第七个版本。Adobe早已是昨日黄花，未来已来，这是一个Html5的世界。在视频播放领域，全民直播已经开启，这是一个实时性需求强于稳定性的播放环境。苹果也跟曾经的Adobe一样，猜中了故事的开始，却踩空了这个故事的结局。
二、三个协议基本认识
两端加一服
在开始之前，先把流媒体服务器中的双端关系说一下。在一个完整的流媒体服务框架中，角色就是：两端加一服。推流端、拉流端、媒体服务器。
同时按照应用场景不同，协议又分：
1.推流协议；
2.拉流播放协议；
RTMP可以用在双端，但HLS只能用在拉流端
2.1为什么RTMP比HLS快？
首先，这个问题发生在拉流端，协议也都是拉流协议。分别对RTMP和HLS的拉流播放进行抓包：
RTMP:
HttpFlv：
通过报文数据我们能看出：
• 在RTMP下，从Handshake到VideoData用了700ms的时间；
• 在HLS下，从Get m3u8到response ts Data只有300ms！
问题来了，HLS的响应效率这么高，怎么就比RTMP还慢了呢？这都要从HLS的实现方案说起。
2.2HLS的方案模拟
在上图的生产换金钟，一RTMP协议推流，HLS拉流。端到端的时间消耗是：
- RTMP推流端的联通成本是700ms，注意此时的700ms包含了connect和send Video Data;
- 推流端联通之后的时间成本，主要是采集编码封包的成本，不需要再次connect；
- HLS的请求响应成本是300ms；
- flvto ts的成本，用ffmpeg切一个10秒的码率500的视频，算上磁盘的写入时间最多200ms；
所以说HLS慢的原因只有一个，就是等数据。
以demo中的这个m3u8来说，在直播的环境里，媒体服务器要等到这12秒的数据推上来，才有可能输出。即使切片成本降为0，拉流端看到的数据也是12秒之前的内容。
优化方案：缩短ts间隔与个数，HLS也能做到3秒+的延迟。但这个结果也拼不过RTMP这种不需要切片的解决方案。
三、三个协议怎么选
