什么是流媒体协议?

这是我们的系列文章的另一部分 “什么是...?" 文章, 旨在提供定义, 历史, 以及围绕在线视频行业的重要术语和问题的背景.

选择一个流媒体技术涉及多个考虑因素, 包括对该技术使用的流媒体协议的优缺点的理解. 本文定义了一个流协议，然后讨论了当今领先的流技术所使用的协议的相对优点.

什么是通信协议?

通信协议是否有规则管理数据的沟通方式, 定义诸如文件头和数据的语法之类的元素, 身份验证, 错误处理. 发送一个简单的数据很容易涉及几十个协议包通过互联网，了解它们是如何协同工作的是很重要的.

简单来讲, 国际标准化组织(ISO) 创建了开放系统互连模型，该模型为通信功能定义了七个逻辑层. 所有的流协议都在应用层, 这意味着它们可以使用它下面的任何一层来传输数据包之类的管道功能. 这使得每一层中的协议能够专注于特定的功能, 而不必重新创建整个函数堆栈.

OSI模型

例如，实时流协议(RTSP) 应用程序级流协议是否可以在传输层中使用多个协议来传输其数据包, 包括通用数据报协议(UDP) 和传输控制协议(TCP). 有时，应用程序级协议是专门为特定的传输协议编写的, 就像实时传输协议(RTP)，它通常建立在UDP传输上.

希望, 这个简短的概述将帮助您了解流协议的位置以及它们如何与其他流协议交互, 低级协议. 这是我们所能得到的技术，伙计们，所以从现在开始，应该会一帆风顺.

一开始就有HTTP，它很好

有了这个背景, 让我们开始研究用于视频流的应用层协议, 从他们的祖父开始, HTTP. 你们可能知道, HTTP代表超文本传输协议, 哪个是网络的通用语. HTTP管理web服务器和浏览器之间的通信，是用于将网站上的所有内容分发给远程查看者的协议, 包括HTML文本, GIF和JPG图形, PDF文件和其他基于web的(相对于 FTP)下载.

早期通过HTTP传输视频的实验不太令人满意，原因有很多, 其中最重要的是当时28/56Kbps调制解调器的有限带宽. 第一个发布在网络上的视频文件是通过下载和播放的方式传递的, 这意味着它们必须在播放之前完全下载. 然后苹果开创了渐进式下载, 视频下载后可以从哪里开始播放, 这有点帮助, 但没有提供像前瞻性搜索或随机访问这样的功能.

http传输视频的另一个大缺点是成本和服务质量问题. HTTP交付在可用带宽允许的情况下尽可能快地完成. 如果查看器通过高速连接连接, 整个视频文件以最快的速度发送了出去. 如果观众在几分钟后停止观看，那么大部分转移就被浪费了.

此外，这种传送模式很难同时服务于多个观看者. 当观看者A点击视频时，服务器开始以最快的速度发送视频. 当观众B, C, D, E点开了视频, 在向观看者A的传输完成之前，出站带宽可能不足以为它们提供任何视频.

流媒体协议的兴起

随着流媒体重要性的增加, 为了解决这些问题，创建了几个流协议, 包括前面提到的RTSP, 微软媒体服务(MMS) 和 Macromedia’’然后 Adobe’s) 实时消息协议 (RTMP). 在高层次上，这些协议共享几个公共元素.

首先是流媒体服务器的存在, 或者一个只负责提供流媒体内容的软件程序. 这些流媒体服务器与传统的HTTP服务器一起工作，这样当浏览者点击HTTP服务器上的链接时, 它启动了流媒体服务器和播放器之间的连接，直到观看者停止观看. 因为这种联系, 这些协议被认为是“有状态的”,，与HTTP相比, 哪个是无状态的，服务器和玩家之间没有连接.

这种连接解决了HTTP传递的大多数缺点. 流式传输协议允许查找视频文件中的随机点, 自适应流媒体, 多个编码文件可以根据可用带宽和CPU能力分发给播放器. 服务器可以及时测量视频流到播放器上, 所以如果观众停止观看, 额外的带宽很少被浪费. 因为出站流量是被测量的, 流媒体服务器可以更有效地为多个用户服务, 提高整体服务质量.

HTTP -回到未来

随着时间的推移, 因为Flash视频开始主导流媒体视频领域, RTMP成为主流的流媒体协议, 至今仍被广泛使用. 然而，随着微软基于http的引入光滑的流和苹果的 HTTP直播(HLS), 基于http的流媒体技术由于多种原因开始复苏, 两者都与RTMP的负面影响和HTTP技术的创新有关，这些创新解决了RTMP的许多负面影响.

RTMP的缺点包括:

RTMP报文可能会被某些防火墙拦截, 但如果遇到这些问题，Adobe Media Server有解决方案.
RTMP数据包不能利用isp网络中可用的标准HTTP缓存机制, 公司, 以及其他组织, 怎样才能提高配送效率和服务质量.
持久的服务器到玩家的连接意味着成本的增加, 因为流媒体服务器要花钱.
与基于http的流相比，所需的服务器也可能限制可伸缩性, 因为HTTP服务器比RTMP服务器多得多.

我说"感知",因为在撰写本文时(2012年8月), RTMP仍然被像彭博和街上.com，这往往会让人怀疑RTMP无法通过防火墙严密的查看器. ESPN 和 MTV 也可以使用RTMP，这会使您质疑可伸缩性和成本问题.

抛开这些疑虑, 技术专家普遍认为，基于http的技术在交付高质量流方面更有效. 另外，Adobe引入了 HTTP动态流(HDS) 在2010年，为那些寻求基于http的流式传输到桌面的用户提供了一个基于flash的替代方案. 突然之间, changing to HTTP-based online video delivery no longer involved a seismic shift to a totally new technology; Flash users could continue to leverage their investment in Flash development 和 infrasture 和 leverage the benefits of HTTP流媒体.

如前所述，HTTP流的一些创新也解决了该技术以前的限制. 像之前一样, there is no persistent connection between the server 和 the player; the video resides on any HTTP server 和 the technology remains stateless. 然而, 现在所有基于http的流都被分解成块, 单独的文件或较大文件中的段. 而不是用单个请求检索单个大文件, 基于http的技术根据需要检索连续的短块.

这有很多好处. 首先，几乎没有浪费，因为视频是在观看的同时传送的. 这有效地测量了视频, 使单个HTTP服务器能够有效地服务更多流. Seeking is no problem; if the viewer drags the playhead forward, 玩家可以检索适当的块. 这些技术还可以实现流之间的高效切换, 所以所有列出的技术(平滑流, HLS, 和HDS)自适应流.

由于这些技术是通过HTTP交付的，因此它们回避了RTMP所面临的问题. 基于HTTP的技术是防火墙友好的，并且可以利用HTTP缓存机制. 因为不需要流媒体服务器, 它们的实现成本更低，并且可以更便宜、更有效地扩展以服务可用用户.

最后点

同样，RTMP分发仍然被许多网站广泛而有益地使用. 然而, 虽然有些网站可能没有什么改变的动力, 在这一点上，如果你正在考虑流媒体技术, 压倒性的观点是通过HTTP交付. 当然，为了适应苹果设备(和Android 3).0或更高)，HLS是您唯一的选择.

认识到大多数视频内容都是通过普通的HTTP渐进式下载传递的，这一点也很有用. 确定, 有局限性, 比如缺乏自适应流媒体, 但你不能说结果太糟糕了 YouTube该公司大约70%的视频都是通过网络传输的，而且完全是渐进式下载. 然而，这种方法阻止了YouTube部署数字版权管理通过HDS提供的技术, 光滑的流, 和HLS来保护他们的视频, 拥有品牌内容的网站使用这些技术的关键原因是什么.

最后，本文的重点是一般的互联网流媒体. 特别是对于内部网使用，基于流服务器的协议，如 IP多播像这样的应用点对点传输提供大量的价值和更多的承诺. So don’t throw out the baby with the bathwater; 流媒体 servers aren’t “bad” 和 HTTP isn't "good.相反，要选择最适合工作的工具.