什么是流媒体协议?

这是我们的系列文章的另一部分 “什么是...?" 文章, 旨在提供定义, 历史, 和 context around significant terms 和 issues in the online video industry.

选择一个流媒体技术涉及多个考虑因素, including an underst和ing of the pluses 和 minuses of the 流媒体 protocol used by the technology. This article defines a 流媒体 protocol 和 then discusses the relative merits of the protocols used by today’s leading 流媒体 technologies.

什么是通信协议?

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

简单来讲, 国际标准化组织(ISO) 创建了开放系统互连模型，该模型为通信功能定义了七个逻辑层. 所有的流协议都在应用层, which means they can use any layer beneath it for plumbing functions like transmitting data 包s. 这使得每一层中的协议能够专注于特定的功能, 而不必重新创建整个函数堆栈.

OSI模型

例如，实时流协议(RTSP) is an application-level 流媒体 protocol that can use multiple protocols in the transport layer to transmit its 包s, 包括通用数据报协议(UDP) 和传输控制协议(TCP). Sometimes application-level protocols are written specifically for a particular transport protocol, 就像实时传输协议(RTP)，它通常建立在UDP传输上.

希望, this brief overview will help you underst和 where 流媒体 protocols live 和 how they interact with other, 低级协议. This is as technical as we get, folks, so from here on out it should be smooth sailing.

一开始就有HTTP，它很好

有了这个背景, 让我们开始研究用于视频流的应用层协议, 从他们的祖父开始, HTTP. 你们可能知道, HTTP代表超文本传输协议, 哪个是网络的通用语. HTTP governs the communications between web servers 和 browsers 和 is the protocol used to distribute all the content on websites to remote viewers, 包括HTML文本, GIF和JPG图形, PDF文件和其他基于web的(相对于 FTP)下载.

Early experiments with delivering video via HTTP were less than satisfactory for a number of reasons, not the least of which was the limited b和width available in the 28/56Kbps modems of the day. The first video files posted on the web were delivered via download 和 play, 这意味着它们必须在播放之前完全下载. 然后苹果开创了渐进式下载, 视频下载后可以从哪里开始播放, 这有点帮助, 但没有提供像前瞻性搜索或随机访问这样的功能.

The other big negatives of HTTP-delivered video were cost 和 quality of service issues. HTTP交付在可用带宽允许的情况下尽可能快地完成. 如果查看器通过高速连接连接, 整个视频文件以最快的速度发送了出去. If the viewer stopped watching after a few moments, much of that transfer was wasted.

In addition, this mode of delivery made it difficult to serve multiple viewers. When viewer A clicked on the video, the server started sending the video as quickly as possible. 当观众B, C, D, E点开了视频, outbound b和width might be insufficient to serve them any video until the transfer to viewer A was complete.

流媒体协议的兴起

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

首先是流媒体服务器的存在, 或者一个只负责提供流媒体内容的软件程序. These 流媒体 servers worked in conjunction with traditional HTTP servers so that when a viewer clicked a link on the HTTP server, it initiated a connection between the 流媒体 server 和 the player that persisted until the viewer stopped watching. 因为这种联系, 这些协议被认为是“有状态的”,，与HTTP相比, 哪个是无状态的，服务器和玩家之间没有连接.

这种连接解决了HTTP传递的大多数缺点. 流式传输协议允许查找视频文件中的随机点, 自适应流媒体, where multiple encoded files could be distributed to the player based upon available b和width 和 CPU power. The server could meter out the flow of video to the player on a just in time basis, 所以如果观众停止观看, 额外的带宽很少被浪费. 因为出站流量是被测量的, 流媒体服务器可以更有效地为多个用户服务, 提高整体服务质量.

HTTP -回到未来

随着时间的推移, 因为Flash视频开始主导流媒体视频领域, RTMP成为主流的流媒体协议, 至今仍被广泛使用. 然而，随着微软基于http的引入光滑的流和苹果的 HTTP直播(HLS), 基于http的流媒体技术由于多种原因开始复苏, both having to do with perceived negatives of RTMP 和 innovations in HTTP technologies that addressed many of its negatives.

RTMP的缺点包括:

RTMP报文可能会被某些防火墙拦截, though the Adobe Media Server has workarounds if these problems are experienced.
RTMP 包s can’t leverage st和ard HTTP caching mechanisms available within the networks of ISPs, 公司, 以及其他组织, 怎样才能提高配送效率和服务质量.
持久的服务器到玩家的连接意味着成本的增加, 因为流媒体服务器要花钱.
The required server may also limit scalability as compared to HTTP-based 流媒体, 因为HTTP服务器比RTMP服务器多得多.

我说"感知",因为在撰写本文时(2012年8月), RTMP仍然被像彭博。和街上.com, which tends to cast doubt on the notion that RTMP can’t get through to heavily firewalled viewers. ESPN 和 MTV 也可以使用RTMP，这会使您质疑可伸缩性和成本问题.

抛开这些疑虑, there’s a general perception among technical cognoscenti that HTTP-based technologies are more effective at delivering high-quality streams. 另外，Adobe引入了 HTTP动态流(HDS) in 2010, providing a Flash-based alternative for those seeking HTTP-based 流媒体 to the desktop. 突然之间, 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流媒体.

As mentioned, several innovations in HTTP 流媒体 also addressed previous limits of the technology. 像之前一样, there is no persistent connection between the server 和 the player; the video resides on any HTTP server 和 the technology remains stateless. 然而, 现在所有基于http的流都被分解成块, 单独的文件或较大文件中的段. 而不是用单个请求检索单个大文件, HTTP-based technologies retrieve consecutive short chunks on as needed basis.

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

Since these technologies are delivered via HTTP, they sidestep the issues faced by RTMP. HTTP-based technologies are firewall friendly 和 can leverage HTTP caching mechanisms. 因为不需要流媒体服务器, they are less expensive to implement 和 can scale more cheaply 和 effectively to serve available users.

最后点

Again, RTMP distribution is still widely 和 beneficially used by many websites today. 然而, 虽然有些网站可能没有什么改变的动力, 在这一点上，如果你正在考虑流媒体技术, 压倒性的观点是通过HTTP交付. 当然，为了适应苹果设备(和Android 3).0或更高)，HLS是您唯一的选择.

It’s also useful to recognize that most video content is delivered via plain old HTTP 渐进式下载. 确定, 有局限性, 比如缺乏自适应流媒体, 但你不能说结果太糟糕了 YouTube, who delivers about 70% of video over the web, exclusively via 渐进式下载. 然而，这种方法阻止了YouTube部署数字版权管理通过HDS提供的技术, 光滑的流, 和HLS来保护他们的视频, 拥有品牌内容的网站使用这些技术的关键原因是什么.

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