第一篇章 流媒體原理
1.1 流媒體概念
1.2 流式傳輸特點
1.3 流媒體系統構成
1.4 流媒體涉及技術
1.5 流媒體應用
1.6 國内外大型流媒體系統
1.7 總結
流媒體相關術語
第二篇章 流媒體系統
2.1 編碼工具
2.2 流媒體伺服器
2.3 CDN分發網絡
2.4 網絡協定
2.5 播放器
總結：從一個直播APP看流媒體系統的應用
第三篇章 流媒體協定
3.1 HTTP
3.2 RTMP
3.3 FLV
3.4 HLS
3.5 Websocket
3.5 URL
（by 又拍雲@陳仁餘 觀止雲PM羌人彧）
傳輸協定作為流媒體系統中最重要組成部分之一，在流媒體應用中扮演着關鍵性作用。本章着重對我們目前業務中常用的基于HTTP的流協定（如HLS、HTTP-FLV）、RTMP等主要流媒體協定以及相關的Websocket 、URL進行詳細介紹。
在流媒體相關工作中，我們經常會聽到有人問起，這麼多流媒體協定我該選用哪個？需要說明的是，各種流媒體協定都有其生存的理由，比如監控行業、電信行業IPTV就不能沒有RTSP，因為這裡面所有的監控應用程式太多基于RTSP；比如目前的直播主協定就是RTMP，主要是因為CDN對RTMP支援的最好；再比如Apple終端市場占有率太高，就不能夠不去考慮HLS。
每一種流媒體協定都有其應用場景，每一種流媒體協定都有其發展的曆史原因，每一種流媒體協定都有其自身的優勢和不足。是以，我們需要對各種協定的原理、構成、特性都有所了解，才能在自身應用場景中選擇出最佳方案。
▼▼▼
HTTP
通過前面文章，我們知道目前網際網路上傳輸媒體内容的重要方式之一就是通過HTTP來傳輸的。例如各大視訊網站上的HLS點播内容，以及部分直播平台的直播流采用http-flv，H5頁面上采用hls等。這些都屬于基于HTTP流媒體傳輸範疇。
總結起來說，基于HTTP的媒體分發可以分為三種方式：
❶ HTTP漸進式：如YouTube、優酷等大型視訊網站的點播分發。它的核心差別是媒體檔案不分片，直接以完整檔案形态進行分發，通過支援Seek,終端播放器可從沒下載下傳完成部分中任意選取一個時間點開始播放，如此來滿足不用等整個檔案下載下傳完快速播放的需求，一般MP4和FLV格式檔案支援較好，打開一個視訊拖拽到中部，短暫緩沖即可播放，點選暫停後檔案仍将被持續下載下傳就是典型的漸進式下載下傳。
❷ HLS類“僞”HTTP流：HLS（Apple）、HDS(Adobe)、MSS(Microsoft) 、DASH（MPEG組織）均屬于“僞”HTTP流，之是以說他們“僞”，是因為他們在體驗上類似“流”，但本質上依然是HTTP檔案下載下傳。以上幾個協定的原理都一樣，就是将媒體資料（檔案或者直播信号）進行切割分塊，同時建立一個分塊對應的索引表，一并存儲在HTTP Web伺服器中，用戶端連續線性的請求這些分塊小檔案，以HTTP檔案方式下載下傳，順序的進行解碼播放，我們就得到了平滑無縫的“流”的體驗。
❸ HTTP流：http-flv這樣的使用類似RTMP流式協定的HTTP長連接配接，需由特定流媒體伺服器分發的，是真正的HTTP流媒體傳輸方式，他在延時、首畫等體驗上跟RTMP等流式協定擁有完全一緻的表現，同時繼承了部分HTTP的優勢。
以下主要介紹HTTP流媒體傳輸的一些基本知識，以及對最常用的HLS和HTTP-FLV進行簡單分析，此二協定後續文章會專門論述。
HTTP流媒體傳輸的基礎
網際網路上最初隻能傳輸一些文本類的資料，自從HTTP協定發明之後，就可以傳輸超文本的音頻視訊等等内容，這主要就是靠HTTP協定中的MIME。通過它，浏覽器就會根據協定中的Content-Type header去選擇相應的應用程式去處理相應的内容。如此，才使得流媒體内容通過HTTP協定傳輸成為可能。
和流媒體相關的Type清單：
（可點選檢視大圖）
HTTP流媒體傳輸技術
01
HTTP request & response
和流媒體相關的http方法主要是GET。GET請求的首部大緻如下：
（可點選檢視大圖）
HTTP的響應頭大概是這樣:
（可點選檢視大圖）
02
http協定中content-length 和chunked
我們打開網宿的http-flv流舉例：
http://175.25.168.16/pl3.live.panda.tv/live_panda/d4e0a83a7e0b0c6e4c5d03774169fa3e.flv?wshc_tag=0&wsts_tag=57e233b1&wsid_tag=6a27c14e&wsiphost=ipdbm
發現響應頭中出現Connection: close 的字段，表示網宿采用的是短連接配接，則直接可以通過伺服器關閉連接配接來确定消息的傳輸長度。
（可點選檢視大圖）
正常的流媒體請求都采用長連接配接即keepalived的方式來傳輸資料。Content-length：用于描述HTTP消息實體的傳輸長度。主要表示壓縮後的message-body的長度。以下這種就是content-length的方式。 如果head中有Content-Length，那麼這個Content-Length既表示實體長度，又表示傳輸長度。
（可點選檢視大圖）
還有一種方式是采用Chunked編碼的方式來傳輸流媒體的内容。例如http-flv這種流，伺服器是不可能預先知道内容大小的，這時就可以使用Transfer-Encoding：chunk模式來傳輸 資料了。
如下的響應就是采用的Chunked的方式進行的傳輸的響應頭：
（可點選檢視大圖）
03
HTTP協定中代理的應用
▣ http-flv,hls+：如果80端口被占用，客戶通路flv或hls+的時候,代理到本地的流媒體伺服器監聽的端口(例如8080)。
▣ nightclub熱更新系統也采用代理的方式。熱更新的時候講新進來的請求代理轉發到後端新版本程式監聽的端口上，進而可以實作無縫更新。對外都是1935端口(NC監聽的)，隻是真正服務的端口會變化。
▣ HTTP代理還可以做鑒權等功能
04
302跳轉功能
▣ 302跳轉可以實作主機排程的功能。将請求重定向到合适的伺服器上達到排程的效果
▣ 可以通過重定向完成負載均衡的功能
▣ 可以通過302重定向解決一些新老版本的相容性問題
HTTP-FLV和HLS
這兩種協定是目前HTTP媒體傳輸最常用，大家也接觸最多的協定。它們相比RTMP和RTSP這種傳統的流媒體傳輸協定來說，最大的優點就是它外面封裝的是HTTP協定，相容性很好。可以穿過一些防火牆，還支援靈活的排程，防盜鍊等等功能。後續文章将專門對它們分别論述，此處僅提及概念。
http-flv一般的實作是：伺服器響應http請求的時候不回複content-length字段；這樣用戶端就會一直接受資料，進而實作了流媒體的傳輸。當然，flv在播放的時候是需要通過flash插件來播放的。
HLS是媒體資料由伺服器端切片器切割存儲為為連續的、時長很短（約10s）的媒體檔案（MPEG 2-TS格式）,同時建立.m3u8索引檔案。用戶端讀取索引檔案，然後按順序下載下傳和播放.ts檔案實作HLS直播流。
HLS相比于http-flv的優點就是不需要任何插件，html5可以直播播放，safari，EDGE等浏覽器都可以直接播放HLS的視訊流。
其它幾種類似HLS的協定，HDS(Adobe)、MSS(Microsoft) 、DASH（MPEG組織）原理都一樣，隻是切片檔案的封裝格式和索引檔案上有差别而已。
總結
HTTP在流媒體應用場景中，主要展現在傳輸和控制層面。HTTP對流媒體資料進行封裝，再通過底層TCP協定來進行傳輸，同樣再通過成熟的HTTP協定對流媒體進行精确控制、排程等，進而完善了流媒體在網際網路中的傳播。
和RTMP、RTSP等真正的流式協定比起來，HTTP流媒體分發方式主要優勢在于內建了HTTP的諸多優點，比如協定簡單性能高，WEB伺服器在部署、CDN緩存支援、防火牆穿透等方面都對現有平台相容性極好。同樣，它也有不少缺點，比如大部分HTTP流實時性相對就差，碎片檔案多導緻性能低下，碼流控制機制較為缺乏等。