深入浅出 RTP 协议：从原理到 WebRTC 实践

1. 为什么需要 RTP？

在实时通信（RTC）领域，UDP 是传输协议的首选，因为它延迟低、无须握手。但 UDP 也有致命缺点：它只负责发送，不保证数据包的顺序、逻辑关系和到达率。

音视频数据具有极强的前后逻辑关系 （例如视频帧需要按顺序解码），为了解决 UDP 的这些缺陷，RTP（Real-time Transport Protocol） 应运而生。它在 UDP 之上增加了一层，专门用于处理音视频的实时传输。

层级定位：RTP 属于应用层协议，与 HTTP/HTTPS 处于同一级别。

2. RTP 报文结构详析

一个 RTP 包由 Header（报头） 和 Payload（有效负载） 组成。Header 最小为 12 字节。

2.1 报文格式图解

text 复制代码

# Header 只负责传输控制信息（序列号、时间戳、同步源 SSRC、负载类型 PT 等）。
# Payload data 才是应用层数据，即你编码好的音视频帧（或帧的分片）。
0                1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       extension header(X=1才有)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        extension Data(X=1才有)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
|                                                               |
|                    RTP Payload Data                           |   
|                   （H.264 NALU、AAC帧、Opus帧等）               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Padding（如果P=1才有）                      | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2 核心字段解析

字段	位宽	功能说明
V (Version)	2 bit	版本号，目前标准为 2。
P (Padding)	1 bit	填充位。为 1 时，包尾有填充字节（常用于加密）。
X (Extension)	1 bit	扩展位。为 1 时，SSRC 后紧跟扩展头。
CC	4 bit	CSRC 计数，表示后面跟着多少个 CSRC 标识符。
M (Marker)	1 bit	标记位。视频通常标记一帧的结束；音频标记静音后的首包。
PT (Payload Type)	7 bit	负载类型。标识编码格式（如 96 是 H.264，111 是 Opus）。
Sequence Number	16 bit	序列号。每发一包加 1，用于检测丢包和重组顺序。
Timestamp	32 bit	时间戳。记录采样时刻，用于音视频同步和抖动计算。
SSRC	32 bit	同步源标识符。全局唯一，标识一个媒体流的来源。
CSRC	32 bit	贡献源列表。仅在混音/合并场景使用，记录原始流的 SSRC。

3. RTCP：RTP 的"黄金搭档"

RTP 负责传数据，而 RTCP（RTP Control Protocol） 负责质量反馈。

核心功能：监视服务质量（QoS）、媒体间同步（音画同步）、多播组成员标识。
工作机制：参与者周期性发送 RTCP 包，包含已发包数、丢包率等统计信息。通过这些反馈，发送端可以动态调整传输速率或负载类型。

4. 音视频封包策略与 MTU 限制

由于网络传输中存在 MTU（最大传输单元，通常为 1500 字节） 的限制，RTP 需要根据数据大小采取不同的封装策略：

4.1 音频封包

音频帧通常很小（几十到几百字节），因此一个 RTP 包通常正好存放一帧完整的音频数据。

4.2 视频封包（重点）

视频帧通常很大，远超 MTU。封装方式分为三种：

单包（Single NALU）：NALU 较小，一个包搞定。
聚合包（STAP-A/B）：将多个极小的 NALU（如 SPS/PPS）放进一个 RTP 包。
分片单元（FU-A/B）：将一个大的 NALU 切分成多个片段，封装在多个 RTP 包中。

分片重组的关键点：

相同时间戳：同一视频帧的所有分片 RTP 包，其时间戳完全一致。
FU 头标识 ：通过 FU 头的 S 位（Start） 和 E 位（End） 来判断是帧的开始还是结束。

避坑指南 ：不要依赖底层的 IP 分片。如果 IP 分片中丢失任意一片，整个 RTP 包都会失效。因此，WebRTC 等现代 RTC 产品会主动在应用层进行 RTP 载荷分片。

5. WebRTC 中的进阶应用

在 WebRTC（以 M74 版本为例）中，RTP 扩展头扮演了至关重要的角色：

abs-send-time：绝对发送时间，GCC 拥塞控制算法的核心依赖。
transport-cc：传输层拥塞控制，用于精准的带宽估计。
audio-level：携带音量信息，用于音量检测和 UI 展示。
video-orientation：携带视频旋转角度，让接收端直接调整渲染方向。

6. 常见概念辨析

SSRC vs CSRC：SSRC 区分不同的流（如你的音频流 vs 你的视频流）；CSRC 用于多人会议 MCU 混音场景，记录被混合的多个原始源。
Simulcast vs SVC：Simulcast 是同时发多路不同分辨率的流供选择；SVC 是在一个流里分层，按需解码。

结语

RTP 协议是实时音视频传输的基石。理解了 RTP 的报头设计、分片逻辑以及与 RTCP 的配合机制，你就掌握了 RTC 技术的命门。

如果你觉得这篇文章有帮助，欢迎点赞、收藏、关注！