1.2.2　常见的流媒体协议

这几年网络直播特别火，国内很多网络直播平台做得风生水起，下面介绍几种常见的流媒体协议。

1．RTMP

实时消息协议（Real-Time Messaging Protocol，RTMP）是一个古老的协议，最初由Macromedia开发，后被Adobe收购，至今仍被使用。由于RTMP播放视频需要依赖Flash插件，而Flash插件多年来一直受安全问题困扰，正在被迅速淘汰，因此，目前RTMP主要用于提取视频流。也就是说，将视频发送到托管平台时，首先使用RTMP协议发送到CDN，随后使用另一种协议（通常是HLS）传递给播放器。RTMP协议延迟非常低，但由于需要Flash插件，所以不建议使用该协议，但流提取时例外。在流提取方便时，RTMP非常强大，并且几乎得到了普遍支持。

RTMP是一种用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体／交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/Red5等。RTMP与HTTP一样，都属于TCP/IP四层模型的应用层。RTMP Client与RTMP Server的交互流程需要经过握手、建立连接、建立流、播放／发送4个步骤。握手成功后，需要在建立连接阶段去建立客户端和服务器之间的“网络连接”。建立流阶段用于建立客户端和服务器之间的“网络流”。播放阶段用于传输音视频数据。RTMP依赖于TCP，Client和Server的整体交互流程如图1-5所示。

2．MPEG-DASH

MPEG-DASH（HTTP上的动态自适应流传输，ISO/IEC 23009-1）是由MPEG和ISO批准的独立于供应商的国际标准，它是一种基于HTTP的使用TCP传输协议的流媒体传输技术。MPEG-DASH是一种自适应比特率流技术，可根据实时网络状况实现动态自适应下载。尽管未被广泛使用，但该协议有一些很大的优势。首先，MPEG-DASH支持码率自适应。这意味着将始终为观众提供当前互联网连接速度可以支持的最佳视频质量，在网络速度波动时DASH可以保持不间断播放。其次，MPEG-DASH几乎支持所有编解码器，还支持加密媒体扩展（Encrypted Media Extensions，EME）和媒体源扩展（Media Source Extensions，MSE），这些扩展用于浏览器的数字版权管理标准API，但由于兼容性问题，如今只有一些广播公司在使用，将来或许会成为标准技术。

3．MSS

MSS，全称是Microsoft Smooth Streaming，该技术于2008年推出。如今，以Microsoft为重点的开发人员和在Xbox生态系统的开发人员仍在使用，除此之外已逐渐失去用户。Smooth Streaming支持码率自适应，并且拥有强大的数字版权管理工具。除非目标用户是Xbox用户，或计划只开发Windows平台的应用程序，否则不推荐使用该协议。

4．HDS

HDS，全称是HTTP Dynamic Streaming，是Adobe公司开发的流协议。HDS是RTMP的后继产品，也是依赖Flash的协议，但增加了码率自适应，并以高质量著称。它是延迟较低的流协议之一，具备分段和加密操作。在流媒体体育比赛和其他重要事件中广受欢迎。通常，不建议使用HDS。对于任何公司而言，采用基于Flash的技术无法吸引用户，围绕Flash搭建播放器不是一个好主意。

5．HLS

HLS，全称是HTTP Live Streaming，由Apple开发，旨在能够从iPhone中删除Flash，如今已成为使用最广泛的协议。桌面浏览器、智能电视、Android、iOS均支持HLS。HTML5视频播放器也原生支持HLS，但不支持HDS和RTMP。这样就可以触达更多的用户。HLS支持码率自适应，并且支持最新的H.265编解码器，同样大小的文件，H.265编码的视频质量是H.264的二倍。此前，HLS的缺点一直是高延迟，但Apple在WWDC 2019发布了新的解决方案，可以将延迟从8s降低到1～2s。具体可以查看Introducing Low-Latency HLS。HLS是目前使用最广泛的协议，并且功能强大。统计数据显示，如果视频播放过程中遇到故障，则只有8%的用户会继续在当前网站观看视频。使用广泛兼容的自适应协议（如HLS），可以提供最佳的受众体验。

HLS的工作原理是把整个流分成一个一个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的Extended M3U/M3U8 Playlist文件，用于寻找可用的媒体流。HLS只请求基本的HTTP报文，与实时传输协议（RTP）不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。HLS的网络框架结构如图1-6所示。

（1）服务器将媒体文件转换为m3u8及ts分片；对于直播源，服务器需要实时动态更新。

（2）客户端请求m3u8文件，根据索引获取ts分片；点播与直播服务器不同的地方是，直播的m3u8文件会不断更新，而点播的m3u8文件是不会变的，只需客户端在开始时请求一次。

6．RTSP

RTSP是TCP/IP协议体系中的一个应用层协议，是由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时开启多个串流需求控制（Multicast），传输时所用的网络通信协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。它允许同时开启多个串流需求控制，除了可以降低服务器端的网络用量，更进而支持多方视频会议（Video Conference）。因为与HTTP 1.1的运作方式相似，所以代理服务器的缓存功能也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

RTSP是TCP/IP协议体系中的一个应用层协议，如图1-7所示。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。

RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。行以CRLF中断，包括消息类型、消息头、消息体和消息长，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使其以自描述方式增加可选参数更容易，接口中采用SDP作为描述语言。

RTSP是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据（如音频与视频）的受控点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议的目的在于控制多个数据发送连接，为选择发送通道（如单播UDP、组播UDP与TCP）提供途径，并为选择基于RTP上发送机制提供方法。

RTSP可建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。

7．HTTP-FLV

HLS其实是一个“文本协议”，而并非流媒体协议。流（Stream）是指数据在网络上按时间先后次序传输和播放的连续音／视频数据流。之所以可以按照顺序传输和连续播放是因为在类似RTMP、FLV的协议中，每个音视频数据都被封装成了包含时间戳信息头的数据包，而当播放器获得这些数据包解包时能够根据时间戳信息把这些音视频数据和之前到达的音视频数据连续起来播放。MP4、MKV等类似这种封装，必须获得完整的音视频文件才能播放，因为里面的单个音视频数据块不带有时间戳信息，播放器不能将这些没有时间戳信息的数据块按顺序连接起来，所以就不能实时地解码播放。

HTTP-FLV、RTMP和HLS都是流媒体协议，从延迟性方面分析，HTTP-FLV和RTMP延迟低，内容延迟可以做到2s；HLS延迟较高，一般在10s甚至更高。RTMP和HTTP-FLV的播放端安装率高，只要浏览器支持Flash Player就能非常简易地播放；HLS的最大的优点是HTML5可以直接打开播放；可以把一个直播链接通过微信等转发分享，不需要安装任何独立的App，有浏览器即可。

下面对RTMP和HTTP-FLV进行比较。

（1）穿墙：很多防火墙会屏蔽RTMP，但是不会屏蔽HTTP，因此HTTP-FLV出现奇怪问题的概率很小。

（2）调度：RTMP有个302，但只有Flash播放器才支持，HTTP-FLV流就支持302，方便CDN纠正DNS的错误。

（3）容错：SRS的HTTP-FLV回源时可以回多个，和RTMP一样，可以支持多级热备。

（4）简单：FLV是最简单的流媒体封装，HTTP是最广泛的协议，这两个组合在一起可维护性更高，比RTMP简单。

HTTP协议中有一个约定，即content-length字段，可以指定HTTP的body部分的长度。服务器回复HTTP请求时如果有这个字段，客户端就接收这个长度的数据，然后就可以认为数据传输完成了；如果服务器回复HTTP请求中没有这个字段，客户端就一直接收数据，直到服务器跟客户端的Socket连接断开。HTTP-FLV直播就是利用这个原理，服务器回复客户端请求时不加content-length字段，在回复了HTTP内容之后，紧接着发送FLV数据，这样客户端就可以一直接收数据了。