1. 课程导入
各位同学，咱们今天正式开讲RTP时间戳机制的第一章。说实话，我做了十几年流媒体，见过太多因为时间戳没搞明白而翻车的项目。有的是音画不同步，有的是播放器直接卡死。嗯，咱们从最基础的RTP协议讲起，把地基打牢。
1.1 RTP/RTCP协议栈：一对好搭档
RTP全称是Real-time Transport Protocol，实时传输协议。它还有个形影不离的兄弟叫RTCP——RTP Control Protocol。我习惯把它们比作「快递员」和「监工」的关系。
- RTP：负责把音视频数据打包发出去。它不保证送达，也不管顺序，只管「发」。说白了就是个无连接的UDP之上的封装层。
- RTCP：负责反馈网络质量。丢包率、延迟、抖动，这些信息由RTCP周期性地在端点之间交换。
你可能会问：为什么要把控制信息和数据分开？我在项目中遇到过这样的场景——如果控制信息和数据混在一起，一旦网络拥塞，控制包和数据包一起丢，整个系统就抓瞎了。RTP/RTCP分离的设计，至少保证了数据流不受控制信令的干扰。
协议栈位置：RTP/RTCP运行在UDP之上。应用层 → RTP/RTCP → UDP → IP。注意，RTP本身不提供任何QoS保障，它只负责封装和时序标记。
下面这张图展示了RTP/RTCP在协议栈中的位置，以及它们之间的协作关系：
1.2 RTP在实时通信中的角色
RTP不是传输层协议，它是个应用层框架。它的核心职责就三件事：
- 载荷类型标识：告诉接收方你发的是H.264还是AAC，还是别的什么格式。
- 序列编号：每个RTP包都有一个递增的序列号，接收方靠它检测丢包和重排序。
- 时间戳：这是咱们这门课的核心。时间戳告诉接收方这个包里的数据应该在什么时刻播放。
你想想看，如果没有RTP，直接用UDP裸传音视频数据会怎样？接收方拿到一堆字节流，不知道是什么编码格式，不知道哪个包先到哪个包后到，更不知道什么时候该播放。RTP就是给这些裸数据穿上了「制服」，让它们变得有序可管理。
我的经验：在WebRTC项目中，RTP的序列号和时间戳是调试的「第一现场」。每次遇到音画不同步，我第一件事就是抓RTP包，看时间戳的增量是否稳定。序列号如果出现跳变，基本可以断定有丢包。
1.3 RTP报文头结构详解
RTP固定头只有12字节。别小看这12个字节，里面塞满了关键信息。咱们一个一个来看。
| 字段 | 长度（bit） | 说明 |
|---|---|---|
| V（版本） | 2 | 当前版本为2 |
| P（填充） | 1 | 为1时包尾有填充字节 |
| X（扩展） | 1 | 为1时头部后有扩展头 |
| CC（CSRC计数） | 4 | 表示CSRC标识符的数量 |
| M（标记） | 1 | 应用自定义，常用于帧边界 |
| PT（载荷类型） | 7 | 标识编码格式，如96=H.264 |
| 序列号 | 16 | 每发一个包递增1，用于检测丢包 |
| 时间戳 | 32 | 采样时刻，单位取决于时钟频率 |
| SSRC | 32 | 同步源标识符，唯一标识一个流 |
| CSRC列表 | 0~480 | 当CC>0时存在，标识贡献源 |
这里我重点说几个容易踩坑的字段：
- 序列号：初始值是随机的，不是从0开始。我曾经在调试时看到序列号从12345开始，还以为是bug，后来查RFC才知道这是安全考虑——防止攻击者猜测序列号。
- 时间戳：单位不是毫秒！对于音频，通常是采样率分之一秒。比如8kHz采样的音频，时间戳每增加1代表125微秒。这个细节搞错了，音画同步直接崩。
- SSRC：冲突是可能发生的。两个端点如果随机到了相同的SSRC，RTCP会通过BYE报文通知冲突，然后重新选一个。
⚠️ 避坑指南：我曾经接手过一个项目，对方把RTP时间戳直接填了系统毫秒时间。结果音频8kHz采样下，时间戳增量应该是160（每20ms包），他填了20。播放器直接认为这是变速播放，声音变调。记住：时间戳的单位是采样周期，不是毫秒！
下面这张图展示了RTP报文头的完整结构，方便你对照记忆：