HTTP-FLV，即将音视频数据封装成FLV，然后通过HTTP协议传输给客户端。
这里首先要说一下，HLS其实是一个“文本协议”，而并不是一个流媒体协议。那么，什么样的协议才能称之为流媒体协议呢？
流（stream）： 数据在网络上按时间先后次序传输和播放的连续音/视频数据流。
之所以可以按照顺序传输和播放连续是因为在类似 RTMP，FLV协议中， 每一个音视频数据都被封装成了包含时间戳信息头的数据包。而当播放器拿到这些数据包解包的时候能够根据时间戳信息把这些音视频数据和之前到达的音视频数据连续起来播放。MP4，MKV等等类似这种封装，必须拿到完整的音视频文件才能播放，因为里面的单个音视频数据块不带有时间戳信息，播放器不能将这些没有时间戳信息数据块连续起来，所以就不能实时的解码播放。
延迟分析
理论上（除去网络延迟外），FLV可以做到仅仅一个音视频tag的延迟。
相比RTMP的优点：可以在一定程度上避免防火墙的干扰 （例如， 有的机房只允许 80 端口通过）。
可以很好的兼容HTTP 302跳转，做到灵活调度。
可以使用HTTPS做加密通道。
很好的支持移动端（Android，IOS）。
抓包分析
打开网宿的HTTP-FLV流：
HTTP/1.1 200 OK
Expires: Wed, 21 Sep 2016 07:16:02 GMT
Cache-Control: no-cache
Content-Type: video/x-flv
Pragma: no-cache
Via: 1.1 yc16:3 (Cdn Cache Server V2.0)
Connection: close
发现响应头中出现Connection: close 的字段，表示网宿采用的是短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。
如果HTTP Header中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。而HTTP-FLV这种流，服务器是不可能预先知道内容大小的，这时就可以使用Transfer-Encoding: chunked模式来传输数据了。
如下的响应就是采用的Chunked的方式进行的传输的响应头：
HTTP/1.1 200 OK
Server: openresty
Date: Wed, 21 Sep 2016 07:38:01 GMT
Content-Type: video/x-flv
Transfer-Encoding: chunked
Connection: close
Expires: Wed, 21 Sep 2016 07:38:00 GMT
Cache-Control: no-cache
