网络基础：RTP/RTCP协议在音频传输中的作用，时间戳与序列号机制
聊音频同步，绕不开RTP和RTCP。这两个协议，说白了就是音视频数据在网络上跑的「运输规则」和「监控系统」。我刚开始做WebRTC的时候，总觉得协议是理论课的东西，直到线上出现声音断断续续、口型对不上的问题，才老老实实回来啃这些基础。
嗯，咱们今天就把这两个协议拆开揉碎，看看它们到底怎么保证音频在丢包网络里还能「稳」住。
RTP：音频数据的「快递单」
RTP（Real-time Transport Protocol）负责承载实际的音频数据。但它不保证送达，也不保证顺序——听起来有点不靠谱对吧？
实际上，它只做一件事：给每个音频包贴上「标签」，让接收端能自己拼回去。
这个标签，就是序列号和时间戳。
序列号：包的身份证
每个RTP包都有一个唯一的序列号，发送端从随机值开始，每发一个包就加1。接收端靠它做三件事：
- 检测丢包：如果收到的序列号跳了，说明中间有包丢了
- 排序：网络可能让包乱序到达，序列号就是排序的依据
- 去重：同一个序列号出现两次，说明是重传包，直接丢弃
关键点：序列号只保证顺序，不保证时间关系。两个相邻序列号的包，播放时间可能差很远——这就要靠时间戳了。
时间戳：播放的节拍器
时间戳表示音频数据采样的时刻。对于音频，它通常以采样率为单位递增。比如48kHz采样率，每帧20ms的音频，时间戳每次增加960（48000 × 0.02）。
接收端根据时间戳来决定：
- 什么时候播放这个包
- 两个包之间的播放间隔
- 音视频是否需要同步
我曾经踩过的坑：时间戳的初始值是随机的，不是从0开始。有一次我写播放器，直接拿时间戳当绝对时间算，结果音频开头总有一段静音。后来才意识到，时间戳只表示相对时间差，不能当绝对时间用。
RTCP：网络状况的「体检报告」
RTP只管发数据，不管网络好坏。RTCP（RTP Control Protocol）就是来补这个缺的。它周期性地在带外发送控制报文，告诉发送端：
- 丢包率是多少
- 网络抖动有多大
- 往返时延（RTT）是多少
这些信息，是音频同步方案做决策的基础。
SR与RR：发送端和接收端的报告
RTCP主要有两种报告：
| 报告类型 | 发送方 | 包含内容 | 作用 |
|---|---|---|---|
| SR（Sender Report） | 发送端 | NTP时间戳、RTP时间戳、发送包数、发送字节数 | 用于计算RTT和同步音视频流 |
| RR（Receiver Report） | 接收端 | 丢包率、累计丢包数、最高序列号、抖动、延迟 | 反馈网络质量，触发发送端调整码率或重传 |
我个人习惯把RTCP报告看作「网络质量的晴雨表」。丢包率超过5%，我就知道该启动FEC（前向纠错）或者NACK（重传）了。
时间戳与序列号的配合：同步的基石
序列号和时间戳，一个管顺序，一个管时间。两者配合，才能实现音频同步。
举个例子：
- 包A：序列号=100，时间戳=1000
- 包B：序列号=101，时间戳=1960
- 包C：序列号=102，时间戳=2920
如果网络先到了包C，再到了包A，接收端会怎么做？
- 先看序列号：包C的序列号是102，包A是100，说明包A应该排在前面
- 再看时间戳：包A的时间戳是1000，包C是2920，说明包A应该先播放
- 把包A放到播放队列前面，包C放到后面
你看，序列号保证了顺序，时间戳保证了播放节奏。缺一个，音频就乱套了。
小技巧：在实现JitterBuffer时，我建议用时间戳作为主键排序，用序列号辅助检测丢包。因为时间戳能反映真实的播放时序，而序列号只反映发送顺序。网络重传可能导致序列号乱序，但时间戳不会变。
SVG：RTP/RTCP在音频同步中的角色
下面这张图，展示了RTP和RTCP在音频传输中的协作关系：
实际项目中的经验
我记得有一次做VoIP项目，用户反馈通话过程中声音忽快忽慢。排查下来，问题出在时间戳处理上。
发送端用的是48kHz采样率，但接收端误以为采样率是44.1kHz。结果时间戳换算出来的播放间隔全错了——音频要么加速，要么减速。这就是典型的时间戳与采样率不匹配问题。
所以我的建议是：
- 发送端：确保RTP时间戳的增量严格等于采样率 × 帧长
- 接收端：不要硬编码采样率，从RTP负载类型（PT）中解析
- 同步点：用RTCP SR中的NTP时间戳校准RTP时间戳，消除时钟漂移
一句话总结：序列号帮你「找对顺序」，时间戳帮你「踩准节拍」，RTCP帮你「看清路况」。三者缺一，音频同步就是空中楼阁。