1. 课程导入

各位同学，今天我们正式进入RTP协议的世界。说实话，RTP这个协议看起来简单，但坑不少。我在早期做VoIP网关的时候，就因为对RTP理解不够深，吃了不少苦头。这一章，咱们先把地基打牢。

1.1 RTP/RTCP协议栈：到底谁在干活？

先看一张整体架构图。我习惯把RTP/RTCP协议栈放在整个传输体系里看，这样你才能明白它跟UDP、TCP到底是什么关系。

从图上可以清楚看到：RTP/RTCP 位于应用层和传输层之间。它不直接操作网卡，而是把数据交给 UDP 去发。为什么选 UDP？说白了，实时通信最怕等。TCP 重传虽然可靠，但延迟不可控。你想想看，视频通话里如果因为丢包等重传，画面卡住两秒，那体验就全毁了。

1.2 RTP在实时通信中的角色：它到底干了什么？

很多初学者会把 RTP 跟「传输协议」划等号。其实它更像一个封装工。我举个例子：

假设你在打视频电话。摄像头采集到一帧图像，编码器把它压缩成 H.264 数据。这时候 RTP 上场了——它给这段数据加上一个头部，头部里包含：

• 序列号（Sequence Number）：接收端靠它判断有没有丢包，以及数据包的顺序对不对。
• 时间戳（Timestamp）：告诉播放器「这帧画面应该在哪个时间点显示」。注意，这个时间戳是采样时钟的计数，不是绝对时间。
• 负载类型（Payload Type）：标明数据是 H.264、G.711 还是 Opus。接收端根据这个选择对应的解码器。
• SSRC（同步源标识符）：每个 RTP 流有一个唯一的 SSRC，用来区分不同的发送源。

嗯，这里要注意：RTP 本身不保证数据一定到达。它只负责把数据包按顺序编号、打上时间戳，然后扔给 UDP。丢包了怎么办？那是应用层或者 RTCP 该操心的事。

1.3 RTP与RTCP的关系：一对黄金搭档

RTP 负责运数据，RTCP 负责反馈质量。两者缺一不可。我习惯把 RTP 比作「送货员」，RTCP 比作「质检员」。

RTCP 主要做这几件事：

1. 发送报告（SR）和接收报告（RR）：告诉发送方「我收到了多少包、丢了多少、抖动多大」。发送方根据这些数据调整码率或冗余策略。
2. 源描述（SDES）：传递会话参与者的名字、邮箱、CNAME 等信息。CNAME 用来关联同一个用户的多个 RTP 流（比如音频和视频）。
3. 结束（BYE）：通知对方我要退出了。
4. 应用特定（APP）：扩展功能，比如自定义反馈。

RTCP 的发送频率是有限制的。协议规定：RTCP 流量不能超过会话总带宽的 5%。为什么？因为 RTCP 本身也是数据包，发太频繁会挤占 RTP 的带宽。我在一个项目中遇到过 RTCP 风暴——某个终端频繁发 BYE 消息，导致其他参与者 RTCP 报告延迟，进而误判网络质量。后来加了限速才解决。

特性	RTP	RTCP
主要功能	传输实时媒体数据	传输控制与统计信息
传输方向	单向（发送方→接收方）	双向（所有参与者互发）
带宽占比	约 95%	约 5%
可靠性	不保证	不保证（但通常比 RTP 更可靠）
典型端口	偶数 UDP 端口	下一个奇数 UDP 端口

1.4 RTP协议的应用场景：VoIP、视频会议、直播

RTP 的应用场景其实就三个字：实时性。只要数据对延迟敏感，RTP 就是首选。

VoIP（语音通话）

VoIP 是 RTP 最经典的应用。语音数据小、延迟要求高（通常 <150ms）。RTP 头部只有 12 字节，开销极低。编码器每 20ms 生成一个语音帧，RTP 打包后直接发出去。我在做企业级 VoIP 网关时，遇到过一个问题：某些 SIP 终端发送的 RTP 时间戳时钟频率不对（标准是 8000Hz，有人用了 90000Hz），导致接收端播放速度异常。后来在 SDP 协商阶段强制校验时钟频率才解决。

视频会议

视频会议比 VoIP 复杂得多。一路视频流可能包含多个 RTP 流（比如主视频、屏幕共享、幻灯片）。RTCP 在这里的作用尤其重要——它通过接收报告告诉发送方当前网络状况，发送方据此调整视频编码的码率或分辨率。我记得有一次做跨国视频会议，跨洋链路抖动很大，RTCP 报告显示丢包率超过 10%。我们启用了前向纠错（FEC），在 RTP 负载里加入冗余包，才把丢包率降到 1% 以下。

直播

直播场景下，RTP 通常配合 RTSP 或 HLS 使用。RTSP 负责控制（播放、暂停、快进），RTP 负责传输。这里有个常见误区：很多人以为直播必须用 TCP。其实对于低延迟直播（比如体育赛事、互动直播），RTP over UDP 仍然是主流。延迟可以控制在 1-3 秒，而 TCP 方案通常要 5-10 秒。