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
