流媒体直播协议与比较

前言

这几年来，视频直播、游戏直播、竞赛直播等已经成为互联网行业的大热话题，本文主要和大家谈谈直播协议、视频推流等技术内容。

流媒体概述

所谓流媒体是指采用流式传输的方式在 Internet 播放的媒体格式。
流媒体又叫流式媒体，它是指把实时的视频流或音频流传送到服务器，服务器再把视频流或音频流当成数据包发出，传送到网络上。
用户通过解压设备对这些数据进行解压后，节目就会像发送前那样显示和播放出来。
流媒体以流的方式在网络中传输音频、视频和多媒体文件的形式。
流媒体文件格式是支持采用流式传输及播放的媒体格式。
流式传输方式是将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，
由服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中，用户不必像非流式播放那样等到整个文件全部下载完毕后才能看到当中的内容，而是只需要经过几秒钟或几十秒的启动延时即可在用户计算机上利用相应的播放器对压缩的视频或音频等流式媒体文件进行播放，剩余的部分将继续进行下载，直至播放完毕。

流媒体直播协议

RTP :(Real-time Transport Protocol)

RTP是用于Internet上针对多媒体数据流的一种传输层协议。RTP 协议和 RTP 控制协议 RTCP 一起使用，而且它是建立在 UDP 协议上的。RTP 不像http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。

RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或简写 RTCP)

RTCP即实时传输控制协议，是实时传输协议(RTP)的一个姐妹协议。
注：RTP 协议和 RTP控制协议(RTCP) 一起使用，而且它是建立在UDP协议上的。

RTSP:(Real Time Streaming Protocol)

RTSP是用来控制声音或影像的多媒体串流协议，RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。媒体数据使用rtp，rtcp协议。一般使用udp作为传输层。适合IPTV场景。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途
径，并为选择基于RTP上发送机制提供方法传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，比较能容忍网络延迟。

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

RTMP(Real Time Messaging Protocol)

Macromedia 开发的一套视频直播协议，现在属于 Adobe。和 HLS 一样都可以应用于视频直播，基于TCP不会丢失。区别是 RTMP 基于 flash 无法在 iOS 的浏览器里播放，但是实时性比 HLS 要好。RTMP实时消息传送协议是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输 开发的开放协议。iOS 代码里面一般常用的是使用 RTMP 推流，可以使用第三方库 librtmp-iOS 进行推流，librtmp 封装了一些核心的 API 供使用者调用。
RTMP 协议也要客户端和服务器通过“握手”来建立 RTMP Connection，然后在Connection上传输控制信息。RTMP 协议传输时会对数据格式化，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有 Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据Chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。

HTTP协议

HTTP的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。
最初的HTTP视频协议，没有任何特别之处，就是通用的HTTP文件渐进式下载。本质就是下载视频文件，而利用视频文件本身的特点，就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如faststart工具，就是专门做这个功能的。
但是最为原始的状态下，视频无法进行快进或者跳转播放到文件尚未被下载到的部分。这个时候对HTTP协议提出了range-request的要求。这个目前几乎所有HTTP的服务器都支持了。range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。
优点：
HTTP Live Streaming 还有一个巨大优势：自适应码率流播（adaptive streaming）。效果就是客户端会根据网络状况自动选择不同码率的视频流，条件允许的情况下使用高码率，网络繁忙的时候使用低码率，并且自动在二者间随意切换。这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助。实现方法是服务器端提供多码率视频流，并且在列表文件中注明，播放器根据播放进度和下载速度自动调整。使用起来也非常简单。
缺点：
实时性相对较差，直播的时候延迟比较高。

HLS:HTTP Live Streaming(HLS)

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

WebRTC:

web端实现流媒体的协议。google刚推出WebRTC的时候巨头们要么冷眼旁观，要么抵触情绪很大。使用RTP协议传输。

常用流媒体协议的对比

协议名称	优点	缺点
rtmp	- 实时性高：一般能做到3秒内。 - 支持加密：rtmpe和rtmps为加密协议。 - 稳定性高：在PC平台上flash播放的最稳定方式是rtmp，如果做CDN或者大中型集群分发，选择稳定性高的协议一定是必要的。 - 一般主流编码器都支持该协议。	- 协议复杂：开发者写起来累，效率也不行。 - Cache麻烦：流协议做缓存不方便。
http	- 性能很高：http的性能好，协议简单，高性能服务器也完善。如果分发的量特别大，譬如点播视频网站，没有直播的实时性要求，http协议是最好选择。 - 没有碎片：http相比hls没有碎片。 - 穿墙：http协议是互联网唯一肯定会开放的协议，所以不存在封端问题。	- 实时性差：延迟10s起步。 - 原生支持不好：PC上flash对于http流支持还可以，但是移动端对于http的支持不是很完善
hls	- 性能好：和http一样。 - 穿墙：和http一样。 - 原生支持很好：iOS上支持完美，Android上支持差些。PC/flash上现在也有各种as插件支持HLS。	- 实时性差：与ts切片长度有关，大约3个切片长度时间的延迟，基本上HLS的延迟在10秒以上。 - 文件碎片：若分发HLS，码流低，切片较小时，会导致太多的文件碎片
rtsp	- 延迟低，一般都能够做到500ms。 - 带宽好，时效率高。 - 倍速播放，主要是回放的时候提供的功能。 - 控制精准，任意选择播放点。	- 服务端实现复杂。 - 代理服务器弱：数量少，优化少。 - 无路由器防火墙穿透。 - 管流分离：需要1-3个通道。

总结

实时流一般使用rtmp。rtmp能做到1到3秒的延迟，是直播里除了rtsp外延迟最低的协议。PC上支持直接播放，移动端可以用FFmpeg解码播放。

参考资料

1、直播协议和推流 - 简书
2、直播技术简单介绍之直播协议 - 图鸭科技 - CSDN博客
3、几种直播流媒体协议 - HDHunter的专栏 - CSDN博客
4、三种主流流媒体协议比较 - 矩阵实验室 - CSDN博客