HTTP-FLV

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