流媒体相关协议说明

流媒体

所谓流媒体是指采用流式传输的方式在Internet播放的媒体格式。如：音频、视频或多媒体文件。流媒体实现的关键技术就是流式传输。
与单纯的下载方式相比，这种对多媒体文件边下载边播放的流式传输方式不仅使启动延时大幅度地缩短，而且对系统缓存容量的需求也大大降低。

 

流式传输技术

流式传输技术又分两种，一种是顺序流式传输，另一种是实时流式传输。
顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，它经常被称作HTTP流式传输。顺序流式文件易于管理，但不支持现场直播，严格地说是一种点播技术。

实时流式传输与顺序流式传输不同，他需要专用的流媒体服务器与传输协议。实时流式传输总是实时传送，特别适合现场事件。实时流式传输必须匹配连接带宽。这意味着图像质量会因网络速度降低而变差。实时流式传输允许你对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。

 

HTTP流式传输的优点

适合较小的文件
不需要特殊的服务器软件，WEB服务器一抓一大把
在低带宽的网络连接下也可以工作，最坏情况下可以等下载完成再看
可以实现边下载边播放，就像流方式一样
可以适用于任何文件类型
网络丢包会重新传输直至用户收到
可以穿过几乎所有防火墙(这是使用web方式的好处)

 

HTTP流式传输的缺点

不能实现广播或者多播
不能广播实况流
当带宽很大时，传输的速度大大超过需要的速度，对服务器压力太大，也浪费带宽
不能跳过头部，必须先下完前面的才可以看后面的(这个应该可以克服)
客户端的磁盘可以保存节目(这个可以说是优点也可以说是缺点)

 

实时流方式的优点

可以实现实况转播，可以实现广播和多播
素材可以随机访问
节约用户的磁盘空间
不浪费带宽
不会在客户的硬盘留下copy
可以传输一个文件中的独立流
可以实现每个流的带宽分配，带宽补偿等功能

 

实时流方式缺点

需要使用专用的流服务器
假如文件比特率超过连接速度，观看将会断续，这个很难让人忍受，所以高质量(也就意味着高比特率)的片子一般都是下载到硬盘上看
丢失的包将会永久丢失(流服务器一般都有一定的丢包重传机制)
很多格式的媒体文件不能使用流式播放
有可能被防火墙挡住

 

流媒体相关协议

RTP:实时传输协议
RTCP:RTP 控制协议
SRTP:安全实时传输协议
RTSP:实时流传输协议
RTMP:实时消息传输协议
MMS:串流媒体传送协议
HLS:Apple的动态码率自适应技术

 

RTP

Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 
RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。
RTP 由两个紧密链接部分组成： RTP ― 传送具有实时属性的数据；RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。

 

RTCP

实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。

RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

 

SRTP & SRTCP

安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。

由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。

 

RTSP

RTSP是由Real Networks和Netscape共同提出的。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

 RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。

 

RTSP 和RTP的关系

RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。

RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。它是一种类似与http协议的网络应用层协议。

 

 

 

 

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。
它有三种变种：
1)工作在TCP之上的明文协议，使用端口1935；
2)RTMPT封装在HTTP请求之中，可穿越防火墙；
3)RTMPS类似RTMPT，但使用的是HTTPS连接；

RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上.
RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

 

RTSP、 RTMP、HTTP的异同

RTSP RTMP HTTP都是在应用层。

理论上RTSP RTMP HTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。

HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。RTMP和RTSP协议是流媒体协议。

RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。

RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。

RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。

 

HLS

HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。
相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。

 

总结：

常见的几种流媒体协议的优缺点：
RTMP：Adobe 公司为Flash/AIR与服务器之间传输音视频数据而开发的私有协议，也是目前最常用的流媒体传输协议。
优点：基于TCP长连接，不需要多次建连，延时低，通常只有1~3s；技术成熟，配套完善。
缺点：在PC浏览器中只能通过Flash使用，且无法在移动浏览器使用；鉴于Flash即将退出舞台，所以在网页播放端基本不会以RTMP做拉流。
HLS：苹果公司提出的基于HTTP的流媒体网络传输协议。其工作原理是切片式传输，把直播流切成无数片，用户在观看视频时，每次客户端可以只下载一部分。
优点：基于HTTP协议，所以接入CDN较为容易，很少被防火墙拦下，且自带多码率自适应；作为苹果提出的协议，在macOS/iOS下有极大优势，Android中也提供了对应的支持；可以说此项协议用在移动设备上是再合适不过了。
缺点：延时较大，通常不低于10s 。大量的TS片文件，会造成服务器存储和请求的压力。
HTTP-FLV：把音视频数据封装成FLV，然后通过HTTP连接传输，与RTMP相比只是传输协议变了。对于网页播放端，本来还是需要Flash才能播放，但「flv.js」的出现又弥补了这个缺陷。
优点：低延时，整体效果与RTMP非常接近；相较于RTMP协议，能有效避免防火墙和代理的影响。
缺点：它的传输特性会让流媒体资源缓存在本地客户端，也就是说保密性不怎么样；直到目前仍然不兼容iOS的浏览器。
WebRTC：基于Google开源技术，在Web端上实现流媒体的协议。
优点：RTMP和HLS都是掌握在大企业手中的协议，而WebRTC已被纳入W3C标准；无需安装插件，支持的浏览器越来越多。
缺点：厂商对浏览器或系统的定制可能会导致可用性问题，且缺乏服务器端设计和部署方案；传输质量难以保证，优化手段有限；在安卓设备上的兼容性不好；另外，此项协议主要面向Web端，对原生开发支持不足。