要求比协议更重要。先了解你的需求，选择以后要应用的协议！
#首先，它是什么？
这个问题很难解释，你不同的角度决定了你需要不同的答案。无论如何，协议是为解决问题而生的，具有天然的方向性。同时，它也有自己的局限性。这三份协议的背后，都有一段美好的爱情故事。我说，你听着，想着原著.
千禧年的钟声已经敲响，人们进入了一个新的世纪。当时，中国移动和中国联通不能互相发送消息，我们多少知道手机是什么样子的。在这样的环境下，在这样的网络生存条件下，一小撮内心躁动不安的人开始感到不安！它就是Macromedia。
Macromedia
是的，就是这样。不知道也没关系，公司会活到2005年。这是一家短命的公司，却搞出了一个长命的协议，影响了后来的网络生活，为全国直播奠定了基础。这就是RTMP，一个实时消息传输协议，一个让在线看电影成为可能的协议，一个让东京热起来的协议。
就这样，一个新的时代开始了！
当时间设定为2012年时，Adobe正式发布了RTMP规范1.0版
当时。我以为有了媒体服务的金钥匙，我就可以在未来的世界里自由遨游。但Adobe错了，未来已经到来，但这是一个Html5的世界，一个没有Flash的世界。
在这种背景下，RTMP被取代只是时间问题，并不是因为它不帅，而是因为这个世界瞬息万变！
HttpFlv最早出现在2008年。从它的协议本身，我们可以看到Adobe的影子，也就是flv协议本身。也可以说，httpflv是在争夺和放弃之间妥协的产物。人们不想再看Adobe了，但他们不得不面对海量的Flv历史文档。在仇恨与无奈的交织中，httpflv诞生了。
HttpFlv是HttpFlv，它将音视频数据封装成Flv格式，然后通过HTTP协议传输给客户端。理解HttpFlv协议是关键。
但潇洒地说，你很快就会发现，虽然传输协议变了，但脱离flv数据格式的FlashPlayer依然是无稽之谈。但是到了2016年，这一切都变了，因为flv.js出来了！
传奇人物哔哩哔哩哔哩哔哩不仅促成了弹幕，也为我们提供了另一种互动观影体验。更重要的是，Flv.js的诞生让我们告别了视频广播领域的Adobe时代。一款全新干净的HTML5正向我们走来。
注：音视频流媒体服务开发训练营学习地址关注+后台私信“流媒体”获取训练营学习地址
#关于HLS
现实世界就是这么残酷。随着协议的变化，这是一个巨人倒下，另一个巨人崛起的故事。当你谈论HLS时，你必须谈论苹果，当你谈论苹果时，你必须提到乔。
我一直不想刻意提拔一个人，但这让我.嘿，别说了。只要记住，悲剧的开始往往是荣耀的起点。悲剧还是荣耀只取决于你！
好了，回到标题继续说HLS，意思是“HTTP Live”
流媒体”，诞生于2009年，是QuickTime和iPhone3GS黄金合作下的一个标准，是一个意在颠覆流媒体行业的新协议。
它的工作原理很简单，就是把一个视频流分成基于HTTP的小文件下载。在播放媒体流时，客户端可以根据当前的网络环境方便地在不同的比特率流之间切换，从而达到更好的观看体验。
HLS的出现是为了解决苹果原生环境下的流媒体播放问题。该协议使得Mac和iPhone可以轻松播放视频流，而无需依赖Adobe，更不用说任何标准委员会了。自力更生永远是最大力量的保证。
RFC 8216
但是财神爷就是这么奇怪，当它为你打开一扇门的时候，也会在不经意间为你关上一扇门。就苹果而言，HLS已经发展了10年，RFC。
816发布了HLS第七版。
本。Adobe早已是昨日黄花，未来已来，这是一个Html5的世界。在视频播放领域，全民直播已经开启，这是一个实时性需求强于稳定性的播放环境。苹果也跟曾经的Adobe一样，猜中了故事的开始，却踩空了这个故事的结局。这也许就是商业世界最精彩的地方，即便你冲到万亿市值，对于未来而言，你我依然一无所知！
HLS 就先说到这，贴两张 WIKI的截图镇楼，下一章的内容马上开始。
HLS Usage
HLS Clients
# 第二、为什么
我始终认为，认识一个新的事务，不管它是无形的技术还是有型的实体，都要从正反两面去观察。在聚光灯下，它标榜的是什么？谢幕之后，它的无奈又是什么。只有这样，才能保持我们的谦卑与疑惑，理性地分析，得到一个较为全面的认识。
在本小节，我将通过解答一个问题的过程，建立对这三个协议的基本认识。
两端加一服
在开始之前，我先把流媒体服务中的双端关系说一下。在一个完整的流媒体服务框架中，角色就是"两端加一服"。推流端、拉流端加上媒体服务器。
同时按照应用场景的不同，协议又分：
* 推流协议；
* 拉流播放协议；
大部分教程在介绍这三个协议的时候，都忽略了一点，就是协议的应用场景到底是什么？ RTMP 可以用在双端，但 HLS 只能用在拉流端，记住这层关系。
# 带着问题找答案：为什么RTMP比HLS快？
首先，这个问题发生在拉流端，协议也都是拉流协议。分别对RTMP和HLS的拉流播放进行抓包，能得到以下两张截图。
RTMP
HttpFlv
通过报文数据我们能看出： 在RTMP下，从Handshake到第一个VideoData用了700ms的时间； 在HLS下，从Get
m3u8到response ts Data只有300ms！
问题来了，HLS的响应效率这么高，怎么就比RTMP还慢了呢？这都要从HLS的实现方案说起。
HLS拉流方案
在上图的生产环境中，以RTMP协议推流，HLS拉流。端到端的时间消耗是：
* RTMP 推流端的联通成本是 700ms ，注意此时的 700 毫秒包含了 connect 和 send Video Data ；
* 推流端联通之后的时间成本，主要是采集编码封包的成本，不需要再次connect；
* HLS的请求响应成本是300ms；
* flvto ts的成本，用ffmpeg切一个10秒的码率500的视频，算上磁盘的写入时间最多 200ms；
所以说，HLS的慢的原因只有一个，就是 等数据 ！
Get Frist m3u8
以 demo 中的这个 m3u8 来说，在直播的环境里媒体服务器要等到这 12
秒的数据推上来，我才有可能输出。即使切片成本降为零，拉流端看到的数据也是12秒之前的内容。
能不能优化？能！ 缩短ts间隔与个数，HLS也能做到3秒+的延迟。但这个结果也拼不过RTMP这种不需切片的解决方案。
# 第三、怎么选
当您真正了解这三个协议之后，对于选择的问题我相信您已经有了自己的答案。我写这篇博客的初衷，也是想以历史背景入手，避免一上来就抛概念、甩结果。
希望我写的这些内容对您能有帮助，视频解决方案很复杂，它涉及的内容太多，在学习之初建立起清晰的脉络至关重要。为他人易，为自己难！祝大家在多媒体服务上，选你所选，爱你所爱。
