流媒体协议RTP、RTSP、RTMP、HLS、SRT、WebRTC​全面分析

流媒体协议RTP、RTSP、RTMP、HLS、SRT、WebRTC全面分析

随着网络架构的变迁、媒体技术发展、音视频场景迭代，基于流媒体的技术也是推陈出新。但由于流媒体协议属于应用层技术，缺乏统一标准，因此相关技术更加五花八门。但抓住流媒体协议的核心，各种协议理解起来也就容易了，各种流媒体协议都是将视频分解为多个块，然后发送给视频播放端，播放端接收、重新组合、完成播放。根据传输是否顺序传输，还有实时流式传输和顺序流式传输的区别。接下来我们就介绍常用的几种常用技术：RTP、RTSP、RTMP、HLS、SRT、WebRTC。

概述

在讨论之前，我们要建立网络分层模型的概念，所有流媒体协议都有归属的层级，这个是理解、区分协议的基础。

流媒体协议需要根据目标场景，选择TCP/UDP，再进行应用层协议开发，这里就出现第一个概念，如何选择TCP/UDP？

TCP和UDP之间最大的区别是：TCP面向有连接，能够对自己提供的连接实施控制。UDP面向无连接，不会对自己提供的连接实施控制。一般来说，TCP适用于要求可靠传输的应用，例如文件传输。UDP适用于实时应用，例如：IP电话、视频会议、直播等。

但在流媒体的实际使用场景中，如果直接用UDP来传输音视频，那公网传输中无法避免的丢包、乱序等极端情况会导致客户端无法解码。而如果直接TCP来传输音视频，那TCP自身的拥塞控制机制、传输数据延时大，队头阻塞等问题，会对音视频的实时传输造成一定的困扰。

图片来自：流媒体传输协议浅析（一）_江海细流的博客-CSDN博客https://blog.csdn.net/fengliang191/article/details/120813885

所以对于流媒体传输，需要对运输层TCP/UDP协议进行高层次的开发，以适应流媒体传输时的应用需求。

RTP

RTP(Real-time Transport Protocol，实时传输协议)和RTCP(Real-time Transport Control Protocol)一起使用，RTP使用偶数端口号收发数据，相应的RTCP则使用相邻的下一位奇数端口号。当应用程序启动一个RTP会话时，将同时占用两个端口，分别供RTP和RTCP使用。RTP负责数据传输，RTCP负责收集相关连接信息，实时监控数据传输和服务质量。

RTP的典型应用创建在UDP上，但也能够在TCP或ATM等其余协议之上工作。RTP基于UDP时，和UDP一样，并不提供任何传输可靠性的保证和流量的拥塞控制机制，无法保证实时业务的服务质量。这里就有个疑问，既然UDP和RTP都是传输层协议，RTP由在UDP之上，那二者有什么关系？简单来说，RTP协议和UDP两者共同完成传输层协议传输。UDP只是负责传输数据包，RTP提供时间标志戳及其他技术来保证流媒体在实时传输时的时间正确性。

RTCP负责管理传输质量。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计信息。服务器利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

RTSP

比RTP多了一个S的RTSP是RealTime Streaming Potocol 实时流协议，是传输层（RTP是传输层）之上的应用层协议，可选择UDP、组播UDP、TCP、RTP为传输机制。RTSP定义了双向多应用程序如何有效地通过IP网络传送多媒体数据。RTSP充当多媒体服务器的网络远程控制，使实时数据如音频与视频的快进快退、中止、播放成为可能。

和RTP相比，应用场景上RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。协议上，RTSP是应用层协议，可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。这里就比较清晰了，运营商的IPTV直播业务，没有任何回放、倒退等操作，所以可以直接采用UDP+RTP+组播实现。

多说一句，这里的RSVP是Resource Reserve Protocol资源预订协议，因为音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求以外，还需其余更多的条件。可以使用RSVP预留一部分网络资源，能在一定程度上为流媒体的传输提供QoS保障。

这里可以小结一下：

1. RTP提供时间标志，序列号以及其余可以保证在实时数据传输时处理时间的方法。

2. RTCP是RTP的控制部分，用来保证服务质量和成员管理。

3. RTSP具体数据传输交给RTP,提供对流的远程控制。

4. RSVP预留带宽,提升QoS。

RTMP

另一个名字很相似的RTMP是Real Time Messaging Protocol实时消息传输协议，是Adobe公司为Flash播放器和服务器之间开发的音视频数据传输的开放协议，一般传输flv或f4v格式的媒体流。RTMP是工作在TCP之上的协议，使用端口1935，能够保持长连接，并为用户提供低延时通信。RTMP是目前低延时直播应用最普遍的协议，几乎是全部编码器标准输出协议，是PC机打开浏览器就能播放（通常浏览器默认有Flash），也是全部CDN支持的最好的直播分发协议。

RTMP是基于TCP协议的，且通常只占用TCP一个通道来传输数据和指令，能保证了视频的传输质量。RTMP包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMPT封装在HTTP请求之上，可穿透防火墙；RTMPS类似RTMPT，增加了TLS/SSL的安全功能；RTMPE在RTMP的基础上增加了加密功能。

因为RTMP是基于TCP之上的，所以也存在三次握手的要求，另外RTMP还增加了C0/S0到C2/S2的三次握手。所以播放一个RTMP协议的流媒体需要经过：握手，建立连接，建立流，播放。

RTMP也有不可忽视的缺点，首先，RTMP协议太老，HEVC/H.265/AV1等视频格式都没有官方定义，另外就如刚刚所说，RTMP连接过程较长，存在TCP三次握手和本身的C0/S0到C2/S2的三次握手，再加上connection，createstream，play/publish，总地来说RTMP完成一次建连需要进行9次会话。而且RTMP的拥塞控制完全依赖传输层TCP的拥塞控制算法来进行拥塞管理，无法提供带宽自适应的算法。

HLS

HLS是HTTP Live Streaming，由Apple公司提出的基于短连接HTTP的媒体流传输协议，用于实时音视频流的传输。由于其实基于HTTP协议的，所以网络支持很好，能方便穿透防火墙或代理服务器。

HLS协议将整条流切割成一个小的能够经过HTTP下载的媒体文件，而后提供一个配套的媒体列表文件M3U8。客户端拿到M3U8后，根据内容顺序地拉取媒体文件播放。

HLS有很明显的优势，因为其针对HTTP协议进行针对设计，客户端只须要支持HTTP请求即可。另外，使用HTTP协议网络兼容性好，HTTP数据包也能够方便地经过防火墙或者代理服务器，CDN支持良好。还有就是Apple公司提出的HLS，Apple全系列产品支持HLS协议，Android也已经加入了对HLS的支持。

但HLS由于采用切片式的多媒体文件，因为切片需要时间编码，所以切片的延时不可避免。另外使用HTTP短连接，需要不断的与server建立连接，且需要完成TCP的三次握手，四次挥手，交互耗时长。所以HLS的延时较高，难以用到时延要求更严格的直播场景。另外，由于HLS切片一般较小，海量碎片在文件分发、一致性缓存都有较大挑战。

SRT

SRT由Haivision和Wowza在UDT的基础上，针对音视频实时性提出的协议。SRT是基于UDT的协议（UDT协议是基于UDP的传输协议，具有非常良好的丢包重传机制，丢包重传的控制消息非常丰富，同时支持ACK、ACKACK、NACK。这里有必要提一下UDT，UDT是基于UDP，并引入新的拥塞控制和数据可靠性控制机制，UDT是面向连接的双向的应用层协议。

SRT拥有三大特点，安全，可靠，低延迟。安全方面，SRT支持AES加密，保障端到端的视频传输安全。可靠性方面，SRT通过前向纠正技术(FEC)保证传输的稳定性。低延迟方面，由于SRT建立在UDT协议之上，解决了UDT协议传输延迟高和复杂的传输时序问题，可以做到支持高吞吐量文件和超清视频的实时传输。

SRT基于时间的报文发送，使其具有良好的防止流量突发的能力。音视频流经过网络传输，帧间隔和码率特性会被完全改变，解码这样的信号容易出现故障。而SRT增加了纠错协议，在封装中包含精准的时间戳，解码接收端可以通过该时间戳重现固定的帧间隔。还能通过规定延时量，同时划定send buffer（发送端缓冲区）与receive buffer（接收端缓冲区），来自接收端的反馈信号（可以理解为后向纠错）通过一系列的设置、纠错、流量控制，使编码后的视音频码流拥有与原码流几乎一样的码率特性。基于此，SRT协议具有抗丢包、抗拥塞、抗抖动等特性。

WebRTC

WebRTC是Web Real-Time Communication网页实时通信，是一个支持网页浏览器进行实时语音对话或视频对话的技术而无需任何插件。由谷歌2010年以6820万美元收购Global IP Solutions公司而获得，如今WebRTC已经不仅仅局限于PC的网页浏览器，Android，iOS平台上很多应用都已经采用了这样技术。

WebRTC使用是RTP分装码流，跟视频监控，IPTV，会议电视一样都是RTP承载媒体流，只不过WebRTC信令遵守ICE框架，走自定义信令，IPTV领域走RTSP信令，视频监控走GB28181或者onvif信令，会议电视走h323或SIP协议。另外，WebRTC的码流采用SRTP进行加密，且WebRTC优先使用VP9、VP8、H.264，不支持H.265。

小结

从网络上接收视频时，首先要解协议（RTSP/RTMP等），然后是解格式（MKV，RMVB），之后才是将视频（H264）和音频（AAC）格式数据分别解码为图像（RGB/YUV）和声音（PCM），再根据时间戳同步播放。

RTSP+RTP主要用于IPTV，原因是传输数据使用的是UDP，运营商能保证自己的IPTV网络环境稳定，传输效率更高。

RTMP主要用于互联网音视频传输，它使用的是TCP传输，因为互联网环境相对较差，采用RTMP保证了视频的传输质量，但是其传输延迟相对较高，传输效率相对较低。（传输延时主要看比较对象，和UDP的RTP相比确实高，但和HLS相比肯定会时延更低）

HLS是Apple的动态码率自适应技术，主要用于PC和Apple终端的音视频服务。

SRT的优点在于基于音视频按照时间戳进行收发，可有效保证音视频，同时ACK/ACKACK/NACK多种丢包纠正机制可有效降低延时与丢包率。同样，由于SRT拥塞控制过于简单，原生SRT不支持连接迁移等。所以SRT更加适合编码器到最近节点的传输或其他网络环境固定的场景。

WebRTC虽然目前更多用在视频会议等场景，但各厂商也在逐渐向更广阔场景发力。