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 技术的命门。
如果你觉得这篇文章有帮助，欢迎点赞、收藏、关注！