买方指南:运输协议

本文刊登在…的二/三月号 流媒体 杂志，年度 流媒体行业资料手册. 在这些买方指南文章中, 我们并不声称涵盖某一特定类别的所有产品或供应商, 而是为我们的读者提供他们需要的信息来做出明智的购买决定, 有时使用特定的供应商或产品作为这些功能和服务的范例.

对终端用户来说，流媒体可能看起来像魔术. 然而, 对于内容创建者, 要使流媒体视频神奇地从播放服务器传输到观看者的桌面，必须遵循一个非常具体的过程.

在今年的原始资料的其他文章中，您将阅读有关编解码器和格式的内容. 但是一个同样重要的——经常被误解的——传输考虑是选择哪种协议在互联网上传输视频内容. 今天的流媒体传输使用三种基本传输协议:HTTP、RTMP和RTSP. 每种协议都有其优缺点和合适的流媒体应用程序.

HTTP

让我们从使用最广泛的传输协议开始:HTTP(超文本传输协议). 几乎每个web用户都熟悉这个协议. 它是web浏览器用来移动文本的默认协议, 图片, 或者将整个网页的内容从服务器传送到用户的桌面.

HTTP的好消息是，并非所有内容都必须驻留在一个地方. 可以将HTTP看作是来自多个服务器的高速公路——其中一个包含文本, 另一个图片, 第三个音频内容—到用户的桌面浏览器(仓库). 派一辆大卡车到每个地点把所有的货物集中起来送到仓库可能更划算. 缺点是需要花费相当多的时间(在it术语中)来完成此工作.

HTTP的另一个优点是，HTTP传输服务器比RTMP或RTSP更普遍, 考虑到HTTP提供的内容的绝对数量. 反过来，这使得HTTP比其他选项更便宜、更容易操作.

这个说, HTTP一刀切的方法不一定是流媒体的最佳选择，因为实时流媒体需要某种形式的优先于所有其他类型的流量. 因为视频和音频对时间非常敏感, 他们需要准时到达，并按照特定的顺序对观众有用.

不幸的是, HTTP is designed to deliver all the content from various locations in a nonparticular order; then, 作为底层网页的一部分，代码会计算出在哪里放置内容. 这就是为什么有些内容加载速度比其他内容快的原因. 图像服务器可能没有文本服务器那么忙, 反之亦然, 哪个会影响页面的哪个部分首先加载. 如果您使用HTTP来传递流媒体，这种方法可能是一个大问题.

HTTP传递的另一个问题是，它历来要求在查看文件之前将整个文件加载到浏览器中. 这已经通过使用内联加载和使用渐进式下载来解决图像和音频的各种方法. 然而，由于视频文件的大小，视频加载一直很棘手.

为了弥补这一不足, 有许多解决方案可以将一个大的视频文件分解成许多较小的文件. 例如，内容分发网络(CDN)运营商 Akamai 将文件分割成10秒的块. 而不是要求整个电视剧集在播放开始之前交付, 接收播放器可以在最小数量的片段到达后立即开始观看片段. (苹果和Akamai都使用10秒的块 Adobe 和微软使用2秒的分组.)

当然，如果下一个片段延迟，播放也会延迟. 为了解决这个问题, 其他传输解决方案可以选择以较低的质量或分辨率请求片段-相应地需要较少的带宽-以确保以较低质量平滑播放.

现在, HTTP文件传递是一种最好的方法, 单向的过程, 只有在文件传输完成后才能进行返回通信. This is the reason for the fragmenting file approach; by breaking the video file into smaller segments, http兼容的视频播放器可以在接收到每个块后或在未接收到段的经过时间后发送回信息. 然后，它可以请求以不同的比特率重传同一段或新段.

RTSP

与此形成鲜明对比的是, RTSP(实时流媒体协议)是一种“网络控制协议”，专门设计用于传输流媒体. 与HTTP, 当分段按顺序发送时，哪个效果最好, RTSP允许观看者从流的一个点跳到另一个点, 包括快进或倒带等玩法模式, 使用类似录像机的控制. 观看也可以在第一个比特到达RTSP播放器的那一刻开始, 这意味着2秒或10秒的段延迟不会影响RTSP传输.

同样值得知道的是，RTSP可以支持多播. 您可以使用此协议向多个用户交付单个提要, 而不必为它们中的每个提供单独的流. HTTP cannot do this; it is a true one-to-one delivery system.

出于这些原因, RTSP通常被视为流媒体的同义词, 而HTTP被认为只是一个文件传输协议. 虽然这在技术上是准确的, HTTP碎片化方法在解决文件传输问题方面非常有效, 对于最终用户来说，差异几乎是无法区分的.

RTSP是流媒体服务器系统的核心，例如 QuickTime流媒体服务器, Windows Media服务, RealNetworks的螺旋, 达尔文 (苹果维护的开源版本)，甚至 Skype 和 Spotify.

Adobe使用RTSP的一个变体, 一个专有的消息传递协议，称为RTMP(实时消息传递协议)，用于其传递 Flash媒体服务器 (FMS)到用户的Flash Player在浏览器内播放.

RTMP

对于计划流式传输Flash视频的用户，Adobe FMS提供了RTSP、HTTP和RTMP选项. 除非有特殊原因使用RTSP, 采用RTMP标准来确保数据流完全兼容是有意义的, 从头到尾.

与RTSP一样，RTMP被定义为有状态协议. 从客户端玩家第一次连接到断开连接的时间, 流服务器跟踪客户端的动作或“状态”的命令，如播放或暂停.

当客户端和服务器之间建立会话时, 服务器开始以稳定流的形式发送视频和音频内容. 此行为将持续并重复，直到服务器或玩家客户端关闭会话. 最近的改进还适应了服务器-客户机连接中可能出现的短暂中断, 允许从本地缓冲区播放少量内容.

加密是RTMP的另一个特点, 因为RTMP加密(RTMPE)在单独的基础上保护数据包(稍后详细介绍). 一些基于http的解决方案开始解决集成DRM问题, 但是大多数HTTP传输不支持包级别的加密.

与RTSP或HTTP相比，RTMP的两个缺点是需要下载插件, 以Flash Player插件的形式出现在流行的web浏览器上, 大多数RTMP内容是通过“非标准”端口1935发送的，而不是通过始终开放的端口80, 哪一个用于HTTP流量.

模糊HTTP和RTMP之间的界限, 然而, 是RTMP中的隧道特性(称为RTMPT), 它允许RTMP被封装在HTTP请求中. 这允许RTMP通过显示为端口80上的HTTP流量来穿越防火墙.

那么MPEG DASH呢?

乍一看, one might think that choosing RTSP or RTMP would be the obvious choice for any streaming media application; it’s like choosing a race car to run races rather than choosing a truck. 但是，正如现实生活中经常发生的那样，看似显而易见的事情未必如此.

使用RTSP或RTMP代替HTTP的最大反对意见是，RTSP和RTMP需要在发送服务器和查看器之间建立一个近乎连续的链接. 与此形成鲜明对比的是, HTTP服务器可以缓存内容，然后将其移动到基于web的缓存中，以便根据需要交付. 观众可能看不出有什么区别, 但是必须为带宽付费的人会注意到HTTP模型使用的百家乐软件更少, 因此, 支持成本更低.

再加上MPEG DASH(基于HTTP的动态自适应流)标准即将定稿的事实, 天平可能会进一步向RTSP和RTMP倾斜. MPEG DASH被设计成一个更开放的标准，用于HTTP上的自适应流, 而不是正在使用的专有版本，如微软的Smooth Streaming, Adobe动态流媒体, 和苹果 HTTP 在线直播 (HLS). 如果MPEG DASH流行起来, 它可以鼓励内容生产者使用HTTP而不是RTSP和RTMP进行流媒体. (有关MPEG DASH的概述及其对流媒体的意义，请阅读“什么是MPEG DASH.”)

然后是访问问题. 防火墙和代理通常允许HTTP通信通过端口80进入. 然而，对于使用不同连接的RTSP和RTMP，情况就不一定如此了. 例如，RTMP使用1935端口，许多防火墙阻止通过该通道进行远程访问. (如果此传递路径失败，Flash将被配置为寻找替代方法.)

话虽如此，RTMPT使通过HTTP连接隧道发送RTMP提要成为可能. 这是通过发送封装在HTTP请求中的RTMP数据来实现的. 这种方法允许cdn通过端口80连接移动RTMP数据.

同时，RTSP和RTMP确实有许多其他的有利因素. 首先也是最重要的是，它们是为流媒体设计的，这意味着一切. 特别是, 事实上，RTSP和RTMP feed提供了真正的实时vcr式控制，并在连接时开始播放，这对观众来说是一个很大的优势.

RTSP和RTMP的第二个优点是安全性. 因为视频是流媒体而不是传输的, 观看者最后得到的文件并不是他们以后可以保留的. 正如本文前面所提到的, Adobe提供了该协议的安全版本，称为RTMPE (RTMP加密)。. 顾名思义, RTMPE在流式传输期间提供实时加密，以增强内容保护.

与此形成鲜明对比的是, HTTP是一种文件传输形式, 这意味着内容最终会出现在观看者的临时文件中. 授予, 建立防止盗版的安全措施是可能的, 比如文件加密, 但事实是，观众拥有这些文件. 现在可以通过使用安全HTTP (HTTPS)来提供文件传输保护. 不幸的是, HTTPS还没有被广泛接受为DRM保护的一种形式, 这就意味着一些内容版权持有者可能不愿意让被许可方使用它.

RTSP和RTMP的第三个优势是它们在视频会话期间收集的关于用户行为的数据量. 有了这些协议, 你可以看到观众看了多长时间, 当他们快进或断开连接时, 以及哪些部分他们看了不止一次.

这个故事的寓意是:在适当的情况下, HTTP, RTSP, 和RTMP可以作为传输协议. 问题是哪一个对你来说更有意义.

为了解决这个问题, 与你的技术人员和你正在考虑使用的cdn的代表交谈. 重点是HTTP文件碎片的性能:如果今天的技术足以满足您的需求, HTTP可能是一个更经济的选择. 另一方面, 不要严格根据钱来做决定, 或者你可能会因为少找钱而破产.

传输协议比较