需求比協議重要，理解你的需求在前，選擇應用的協議在后！
第一、是什么？
解釋這個問題有很大的難度，你所處的角度不同，決定了所需答案的不同。不管怎么樣，協議是為了解決問題而生的，它有著天然的指向性。同時，也有著它自身的局限。這三個協議的背后，有著一段凄美的愛情故事。我說說，你聽聽，在想當初….
千禧年的鐘聲敲響了，人們邁進了一個新的世紀。當時的移動和聯通還不能互發信息，手機是什么樣咱們心里也多少有點兒數。就在這樣的環境里，就在這樣一個網絡生存條件下，一小撮內心躁動的人開始不安了！它就是Macromedia。
對，就是它。不知道沒關系，這個公司就活到2005年。這是一個短命的公司，但它拿出了一個長命協議，影響了之后的網上生活，也為全民直播奠定了基礎。這就是RTMP，一個實時消息傳輸協議，一個讓在線看片成為可能得協議，一個讓東京.熱了的協議….
就這樣，一個新的時代開始了！
當時間撥到了2012年， Adobe 正式發布 RTMP specification v1.0 的時候。本以為拿著媒體服務的金鑰匙，可以在未來世界縱橫馳騁。但Adobe錯了，未來已來，但那是一個Html5的世界，一個不需要Flash的世界。
在這種大背景下，RTMP被替換是遲早的，不是它不帥，只是這個世界變化快！
HttpFlv的出現最早是2008年，從它的協議本身我們能看到Adobe的影子，就是flv協議本身。也可以說，httpflv是爭奪與放棄之間妥協的產物。人們再也不愿意看到Adobe，但又不得不面對海量Flv歷史文檔。在仇恨與無奈的交織中，httpflv誕生了。
HttpFlv 就是 http+flv ，將音視頻數據封裝成FLV格式，然后通過 HTTP 協議傳輸給客戶端。理解HttpFlv協議，這就話就是關鍵。
但聰明地你馬上就會發現，雖然傳輸協議變了，但在flv數據格式下，脫離FlashPlayer還是無稽之談。但在2016年，這一切都發生了改變，因為flv.js問世了！
Bilibili，也就是傳說中的B站，不僅貢獻了彈幕，為我們提供了另一種觀影交互體驗。更重要的，Flv.js的誕生，讓我們在視頻播放領域徹底告別Adobe時代。一個全新、干凈的HTML5就這樣向我們走來了。
關于HLS
現實世界就是這么殘酷，伴隨協議更迭的，是一個巨頭倒下，另一個巨頭崛起的故事。談HLS 就不得不談蘋果，談蘋果就不得不提喬幫主。
我總是不想刻意拔高一個人，但這逼 …. 哎，不說了。就記住吧，悲劇的開端，往往是榮耀的起點。是悲劇還是榮耀，只取決于你！
好，返回頭繼續說HLS，HLS就是“HTTP Live Streaming”的縮寫，它誕生自2009年，QuickTime和iPhone3GS黃金搭檔下的一個標準，一個意在顛覆流媒體產業的新協議。
它的工作原理簡單來說就是把一段視頻流，分成一個個小的基于HTTP的文件來下載。當媒體流正在播放時，客戶端可以根據當前網絡環境，方便地在不同的碼率流中做切換，以實現更好的觀影體驗。
HLS的出現是為了解決蘋果原生環境中的流媒體播放，這個協議可以方便地讓Mac和iPhone播放視頻流，不依賴Adobe，更不用去管什么標準委員會。依賴自己，永遠是最大力量的保障。
但幸運之神就是這么奇怪，當它給你打開一扇門的時候，也在不經意間給你關上了一個。就蘋果來說，HLS經過10年的發展，RFC 8216發布了HLS的第七個版本。Adobe早已是昨日黃花，未來已來，這是一個Html5的世界。在視頻播放領域，全民直播已經開啟，這是一個實時性需求強于穩定性的播放環境。蘋果也跟曾經的Adobe一樣，猜中了故事的開始，卻踩空了這個故事的結局。
這也許就是商業世界最精彩的地方，即便你沖到萬億市值，對于未來而言，你我依然一無所知！
HLS 就先說到這，貼兩張 WIKI的截圖鎮樓，下一章的內容馬上開始。
第二、為什么
我始終認為，認識一個新的事務，不管它是無形的技術還是有型的實體，都要從正反兩面去觀察。在聚光燈下，它標榜的是什么？謝幕之后，它的無奈又是什么。只有這樣，才能保持我們的謙卑與疑惑，理性地分析，得到一個較為全面的認識。
在本小節，我將通過解答一個問題的過程，建立對這三個協議的基本認識。
在開始之前，我先把流媒體服務中的雙端關系說一下。在一個完整的流媒體服務框架中，角色就是"兩端加一服"。推流端、拉流端加上媒體服務器。
同時按照應用場景的不同，協議又分：
- 推流協議；
- 拉流播放協議；
大部分教程在介紹這三個協議的時候，都忽略了一點，就是協議的應用場景到底是什么？ RTMP 可以用在雙端，但 HLS 只能用在拉流端，記住這層關系。
帶著問題找答案：為什么RTMP比HLS快？
首先，這個問題發生在拉流端，協議也都是拉流協議。分別對RTMP和HLS的拉流播放進行抓包，能得到以下兩張截圖。
通過報文數據我們能看出：
? 在RTMP下，從Handshake到第一個VideoData用了700ms的時間；
? 在HLS下，從Get m3u8到response ts Data只有300ms！
問題來了，HLS的響應效率這么高，怎么就比RTMP還慢了呢？這都要從HLS的實現方案說起。
在上圖的生產環境中，以RTMP協議推流，HLS拉流。端到端的時間消耗是：
- RTMP 推流端的聯通成本是 700ms ，注意此時的 700 毫秒包含了 connect 和 send Video Data ；
- 推流端聯通之后的時間成本，主要是采集編碼封包的成本，不需要再次connect；
- HLS的請求響應成本是300ms；
- flvto ts的成本，用ffmpeg切一個10秒的碼率500的視頻，算上磁盤的寫入時間最多 200ms；
所以說，HLS的慢的原因只有一個，就是等數據！
以 demo 中的這個 m3u8 來說，在直播的環境里媒體服務器要等到這 12 秒的數據推上來，我才有可能輸出。即使切片成本降為零，拉流端看到的數據也是12秒之前的內容。
能不能優化？能！
縮短ts間隔與個數，HLS也能做到3秒+的延遲。但這個結果也拼不過RTMP這種不需切片的解決方案。
第三、怎么選
當您真正了解這三個協議之后，對于選擇的問題我相信您已經有了自己的答案。我寫這篇博客的初衷，也是想以歷史背景入手，避免一上來就拋概念、甩結果。
希望我寫的這些內容對您能有幫助，視頻解決方案很復雜，它涉及的內容太多，在學習之初建立起清晰的脈絡至關重要。為他人易，為自己難！祝大家在多媒體服務上，選你所選，愛你所愛。
參考：
https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol
https://en.wikipedia.org/wiki/HTTP_Live_Streaming
http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
https://datatracker.ietf.org/doc/rfc8216/
https://www.villainhr.com/page/2017/08/05/RTMP%20H5%20%E7%9B%B4%E6%92%AD%E6%B5%81%E6%8A%80%E6%9C%AF%E8%A7%A3%E6%9E%90
