传输协议 在5G+超高清直播传输领域，选择一种有效的传输协议，以减少业务传输时延，改善业务性能是非常重要的。目前应用较多的是RTP、SRT、RIST、RTMP等协议。

RTP协议：

实时传输协议（Real-time Transport Protocol）,从字面理解也是和实时传输有关系，协议的初衷是为了实时多人视频会议而设计的，现在应用很广泛。在视频监控、实时直播、语音电话、视频会议都能看到应用。特别是在目前大热的webRTC中将其作为传输协议，国内安防标准GB28181和国际标准ONVIF也是用这个传输音视频。在视频监控和实时视频传输还是统治级别的存在，没有啥协议能够进行短期取代。

RTP数据包格式：

RTP固定头：

RTP的数据包由RTP Header + RTP Playload组成。其中RTP固定头如下图所示：

[图片上传失败...(image-a794af-1682318032773)]

各个字段的解释：

1. V：当前的协议的版本号是2，其中0和1已经在草案规范中被占用，这里基本就是固定值了；

2. P：填充标记，包的末尾包含了一个或者多个填充字节，其中填充字节的第一字节包括了后面填充字节的长度，该长度字段包含自己，主要是为了一些对齐处理；

3. X位，如果为1则说明有扩展头，一般默认为0，很少有场景会用到；

4. CC位：是为了计算后面有多少个CSRC，四位说明则最大支持15个CSRC，一般默认为0。

5. M位：特别对于视频而言就是一帧的结束，视频帧比较大，需要通过多个NALU来传输，当看到M位为1时就认为是这个I帧的结束，由于音频帧比较小，一个RTP包就是一个音频帧，所以该位直接置1。

6. Sequence number序列号：16位，用于标识发送者发送的RTP报文序列号，每发送一个RTP包，则这里就增加1，当达到最大值后，则重新从0开始。刚才说了一般RTP协议是承载协议是UDP，UDP是不可靠传输协议。那我们如何保证接收端收的数据是正确的呢，就是通过这个字段进行重新排序，所以接收端一般收到RTP数据第一件事就是排序。

特别注意两点：

a. 这个序列号的初始值可以为0但是也可以为其它随机值，只要符合+1就行;

b. b.发送端的音频和视频都是通过RTP传输的，但是他们是分别计数的，所用的序列号是不同的。

7. timestamp时间戳：占32位四字节，这个单位要注意是采样率到倒数，不是真实的时间，一般要根据采样率进行换算。这里反应的RTP报文第一个八位组的采样时刻，目的是为了接收端计算延迟、抖动和音视频同步。需要说明的是，一个视频帧的时间戳是相同的，但是一个视频帧数据量很大可能需要多个RTP包传输，这样就存在多个RTP包时间戳相同的情况，音频帧数据小，不存在音频帧跨RTP的情况，所以不存在这个问题。

8. SSR同步信号源：占32位四字节，用于标识同步信号源，这个值只要保证在一路音视频会话里面值不相同即可。该标识符是随机选取的 RFC1889推荐了MD5随机算法。该值的作用就是在会话中标识RTP负载流的身份，给一个唯一标记值。

9. CSRC特约信号源CSRC:同样是32位，四字节。一个RTP头最多可以含有0-15个，如果是1对1的流媒体传输，这个字段就不用处理，直接忽略该字段。但是混流和混音时，则需要把各方的RTP同步信号源列出来，这样接收端就能正确指出交谈双方的身份。

RTP扩展头解析：

RTP提供了扩展机制以实现个性化：某些新的负载格式独立的功能要求的附加信息可以允许放到RTP数据包头的扩展部分进行传输，基本的RT并不定义任何扩展头本身。

我的理解就是为了给RTP传输协议增加一些扩展性，防止未来一些新功能的加入，同时允许用户增加一些私有信息和私有功能在里面，大部分音视频场景都没有启用RTP扩展部分，但是也有例外。在WebRTC中看到利用RTP扩展部分做了FEC（前向纠错，核心思想就是一些异或运算）的算法处理，这样当发生RTP丢包可以通过扩展快速恢复丢包，在网络不好的时候特别有用。

扩展头格式：

[图片上传失败...(image-44ea7c-1682318032773)]

字段说明：

扩展字段定义define by profile:16bit两字节，这个由上层的具体实现协议来决定；

扩展头长度length:表示扩展头的长度字段，16bit即2字节，最大扩展长度1024字节；

注意：

如果要启用扩展头，固定头的扩展标记X置1，负载类型playload需要按照规范定义，扩展头字段的长度可以为0，因为不包括头字段的4字节，最大1024.

RTP打包方式：

但是对于发送端组RTP包的一方来说，尽可能找简单的打包方式。对于接受端则需要适配各种发送端的打包方式，因为无法决定输入源的打包方式。这里先分享下我们的打包方式，比较简单：

1. 我们对于NALU的长度<1400的则采用的是单一NALU打包到单一的RTP包中；

2. 我们对于NALU的长度>=1400的则采用了FU-A的方式进行了打包，这种就是把一个大的NALU进行了切分，最后接收方则进行了合并，把多个RTP包合并成一个完整的NALU即可；

3. 至于为什么NALU的长度大于1400字节就要进行FU-A切片，是因为底层MTU大小值固定为1500，从传输效率讲，这里用1400作为切分条件。

RTCP协议：

实时传输控制协议即Real-time Transport Control Protocol，这个协议是RTP协议的姊妹协议，它是为了进行服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识，目前WecRTC用这个协议进行流量和拥塞控制。

RTSP协议：

实时流协议即Real Time Streaming Protocol，这是一种会话管理和媒体控制的协议，用的最多地方就是视频监控。视频监控中摄像机、NVR、前后端之间都是用这个协议和RTP协议配合进行流媒体传输。

RTMP：

实时信息传输协议（Real Time Message Protocol），由Adobe公司提出的一种应用层的协议，RTMP协议是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的，RTMP用于在服务器和Flash播放器之间实时传输视频，音频和数据。目前，RTMP应用较广，特别在直播领域。国内主流的CDN平台和OTT平台基本都支持RTMP，大部分的硬件或软件编码器也都支持RTMP推流格式。

SRT：

由Haivision和Wowza共同创建的互联网传输协议，SRT协议是基于H.264/H.265压缩方案的传输协议，传输带宽可调，比如高清视频可自定义设置4-20Mbps均可。SRT能够在复杂网络环境下实时、准确地传输数据流的网络传输技术，它在传输层使用UDP协议，具备UDP速度快、开销低的传输特性，支持点对点传输，无需中间进行服务器中转（仅需任意一端具备固定公网IP地址即可），互联网点对点传输可小于1s。SRT在丢包率20%以下，延迟可控制在200ms~500ms之间，远远低于RTMP协议的2秒 - 5秒的延迟。SRT是目前非常受欢迎的互联网视频传输协议，广泛用于广电远程节目制作播出、企业远程直播和互联网流媒体应用。

RIST：

Video Services Forum (VSF) 于2017年初成立了可靠的互联网流传输协议（Reliable Internet Stream Transport，RIST）小组，为协议创建通用规范。RIST的首选流传输协议是RTP配合RTCP。RTP发送端口为偶数P，则RTCP端口为P+1。推荐发送端RTCP使用Sender Report (SR) + CNAME，接收端使用Receiver Report (RR) + CNAME。SRT联盟继续扩大，SRT协议在上行侧广泛部署，与之竞争的是VSF联盟的RIST协议，也给了开源参考实现，大有赶超势头。