[TOC] 参考：[https://zhuanlan.zhihu.com/p/94570212](https://zhuanlan.zhihu.com/p/94570212) 参考：[https://blog.csdn.net/moyebaobei1/article/details/86703258](https://blog.csdn.net/moyebaobei1/article/details/86703258) ## RTSP **RTSP(Real-Time Stream Protocol)协议** RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。 RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而必须**依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送**。RTSP负责定义具体的控制信息、操作方法、状态码，以及描述与RTP之间的交互操作。RTSP媒体服务协议框架如下：  ## RTP 协议 我们现在已经决定好用UDP做实时语音。 我们以视频为例，在视频中，一个 I 帧的数据量是非常大的（假设要几十 K）。而以太网的最大传输单元是多少呢？ 1.5K，所以要传输一个 I 帧需要几十个UDP包。这几十个包传到对端后，还要重新组装成 I 帧，这样才能进行解码还原出一幅幅的图像。那么我必须要在包中，添加额外的标记才能够完成组装。这至少包括： * **序号**：用于标识传输包的序号，这样就可以知道这个包是第几个分片了。 * **起始标记**：记录分帧的第一个 UDP 包。 * **结束标记**：记录分帧的最后一个 UDP 包。 有了上面这几个标识字段，我们就可以在发送端进行拆包，在接收端将视频帧重新再组装起来了。 其实，这样的需求在很早之前就已经有了。因此就有了**RTP**协议。下面让我们来详细看一下 RTP 协议吧。一般情况下，在实时互动直播系统传输音视频数据流时，我们并不直接将音视频数据流交给 UDP 传输，而是**先给音视频数据加个 RTP 头，然后再交给 UDP 进行传输**。   知道了上面这些字段的含义后，下面我们还是来看一个具体的例子吧！假设你从网上接收到一组音视频数据，如下： ``` ... {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:13,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:14,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:14,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:15,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:15,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:16,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:16,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:17,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:17,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:18,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:18,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:19,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=0,PT:98,seq:19,ts:1122334455,ssrc=2345}, {V=2,P=0,X=0,CC=0,M=0,PT:111,seq:20,ts:1122334455,ssrc=888}, {V=2,P=0,X=0,CC=0,M=1,PT:98,seq:20,ts:1122334455,ssrc=2345}, ... ``` 假设 PT=98 是视频数据，PT=111 是音频数据，seq 是序号 ，ts 表示时间戳 。 按照上面的规则很容易就能将视频帧组装起来。 ## RTCP 协议 实时传输控制协议(Real-time ControlProtocol，RTCP)是和 RTP一起工作的**控制**协议。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包。  **RTCP功能** 在使用 RTP 包传输数据时，难免会发生丢包、乱序、抖动等问题，下面我们来看一下使用的网络一般都会在什么情况下出现问题： * 网络线路质量问题引起丢包率高； * 传输的数据超过了带宽的负载引起的丢包问题； * 信号干扰（信号弱）引起的丢包问题； * 跨运营商引入的丢包问题 ; WebRTC 对这些问题在底层都有相应的处理策略，但在处理这些问题之前，它首先要让各端都知道它们自己的网络质量到底是怎样的，**这就是 RTCP 的作用**。 **RTCP 报文的种类** RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。 根据所携带的控制信息不同，RTCP信息包可分为**RR（接收者报告包）、SR（源报告包）、SEDS（源描述包）、BYE（离开申明）和APP（特殊应用包）**五类5类： RTCP 有两个最重要的报文：RR 和 SR 。通过这两个报文的交换，各端就知道自己的网络质量到底如何了。  **SR 报文**   从上图中我们可以了解到，SR 报文分成三部分：**Header、Sender info**和**Report block**。 * Header 部分用于标识该报文的类型，比如是 SR 还是 RR。 * Sender info 部分用于指明作为发送方，到底发了多少包。 * Report block 部分指明发送方作为接收方时，它从各个 SSRC 接收包的情况。 通过以上的分析，你可以发现**SR 报文**并不仅是指发送方发了多少数据，它还报告了作为接收方，它接收到的数据的情况。当发送端收到对端的接收报告时，它就可以根据接收报告来评估它与对端之间的网络质量了，随后再根据网络质量做传输策略的调整。