4. 反馈同步：RTCP协议、NACK机制、基于延迟的反馈、基于抖动的反馈
同步这件事，光靠发送端单方面努力是不够的。你想想看，网络状况千变万化，发送端又没长眼睛，它怎么知道接收端到底卡在哪？
所以，反馈机制就派上用场了。说白了，就是让接收端告诉发送端：「嘿，我这边情况不太妙，你得调整一下。」
我在早期做直播项目时，就吃过「只管发、不管收」的亏。那时候推流端疯狂发包，结果接收端缓冲区炸了，画面卡成幻灯片。后来我才意识到，没有反馈的同步，就像蒙眼开车。
这一章，我们就来聊聊反馈同步的四个核心手段：RTCP 协议、NACK 机制、基于延迟的反馈、基于抖动的反馈。
4.1 RTCP 协议：反馈的「信使」
RTP 负责传数据，RTCP 负责传控制信息。它俩是搭档，缺一不可。
RTCP 报文里包含几个关键字段：
- 丢包率：接收端统计的丢包比例，发送端据此判断网络拥塞程度。
- 累计丢包数：从会话开始到现在的总丢包数，用于长期趋势分析。
- 到达时间抖动：接收端计算的包间隔抖动，反映网络稳定性。
- 最后时间戳：接收端最近一次收到 RTP 包的时间，用于往返时间（RTT）计算。
我个人习惯把 RTCP 看作「体检报告」。发送端定期收到这份报告，就知道接收端「身体」怎么样——是丢包严重（感冒发烧），还是抖动剧烈（心律不齐）。
RTCP 的发送间隔：RTCP 报文不能发得太频繁，否则会占用带宽。标准建议是，RTCP 流量不超过总会话带宽的 5%。
我曾经在一个项目中，把 RTCP 间隔设得太短，结果控制报文占掉了 15% 的带宽，反而加剧了丢包。嗯，这算是一个典型的「好心办坏事」案例。
4.2 NACK 机制：精准的「重传请求」
NACK（Negative Acknowledgment），就是接收端告诉发送端：「第 1024 号包我没收到，麻烦再发一次。」
它和 ACK 不同。ACK 是「收到了，谢谢」，NACK 是「没收到，快补」。在实时音视频场景中，NACK 更实用，因为接收端不需要为每个包都回复确认，只在丢包时才反馈。
NACK 的工作流程大致如下：
- 接收端检测到序列号不连续，判断某个包丢失。
- 接收端构造 NACK 报文，包含丢失包的序列号列表。
- 发送端收到 NACK 后，从历史缓冲区中取出对应包，重新发送。
- 接收端收到重传包后，插入到正确位置，恢复数据连续性。
NACK 的时效性：重传包必须在播放时间之前到达，否则就白费了。所以，NACK 通常配合一个超时机制——如果重传包在指定时间内没到，就直接跳过，不再等待。
我记得有一次调试 WebRTC 的 NACK 逻辑，发现重传率特别高。排查了半天，原来是历史缓冲区太小，发送端还没来得及重传，包就被清掉了。后来我把缓冲区从 200ms 扩大到 500ms，问题就解决了。
4.3 基于延迟的反馈：让发送端「慢下来」
延迟反馈的核心思路是：如果接收端发现包到达延迟变高，就通知发送端降低发送速率。
怎么测量延迟？最常用的方法是计算 RTT（Round-Trip Time）。发送端在 RTCP 报文中嵌入一个时间戳，接收端收到后立即回复，发送端就能算出往返时间。
但 RTT 反映的是整个环回路径的延迟，不够精细。更高级的做法是使用 单向延迟（One-Way Delay, OWD），这需要发送端和接收端时钟同步（比如通过 NTP）。
基于延迟的反馈策略通常包含几个步骤：
- 测量：持续计算每个包的到达延迟或 RTT。
- 平滑：用指数移动平均（EMA）过滤掉瞬时波动，得到平滑延迟。
- 比较：将当前延迟与基线延迟对比，判断是否出现拥塞。
- 调整：如果延迟持续上升，就降低发送码率或帧率。
注意：延迟上升不一定都是拥塞引起的。路由切换、Wi-Fi 干扰、CPU 过载都可能导致延迟抖动。所以，基于延迟的反馈最好结合丢包率一起判断，避免误触发。
我在做某款视频会议软件时，就遇到过延迟误判的问题。当时网络其实没问题，但接收端 CPU 满载，导致解码延迟飙升。发送端误以为网络拥塞，疯狂降码率，结果画面糊成一团。后来我们加了一个 CPU 负载检测，才把这个问题解决。
4.4 基于抖动的反馈：让发送端「稳下来」
抖动（Jitter），指的是包到达间隔的变化。如果网络稳定，包应该均匀到达；如果网络波动，包就会「扎堆」或「断流」。
抖动对同步的影响很大。你想想看，如果包一会儿快一会儿慢，接收端的缓冲区就得不断调整，要么溢出，要么欠载。
基于抖动的反馈，就是让接收端把抖动信息告诉发送端，发送端据此调整发送节奏。
抖动的计算方式：
J(i) = J(i-1) + (|D(i-1, i)| - J(i-1)) / 16
其中：
D(i-1, i) = (R(i) - R(i-1)) - (S(i) - S(i-1))
R(i) 是第 i 个包的到达时间
S(i) 是第 i 个包的发送时间这个公式是 RTCP 标准里定义的。它用了一个平滑因子（1/16），让抖动值不会因为单个异常包而剧烈变化。
发送端收到抖动反馈后，可以做什么？
- 调整发送间隔：如果抖动大，就适当拉开发送间隔，减少突发性。
- 增加 FEC 冗余：抖动大的网络往往丢包也多，FEC 可以提前保护。
- 降低帧率：减少单位时间内的包数量，降低抖动对接收端的影响。
抖动 vs 延迟：延迟是「慢」，抖动是「不稳」。两者经常同时出现，但处理方式不同。延迟高就降速，抖动大就平滑。
我曾经在一个跨国直播项目中，发现抖动值忽高忽低。后来定位到是某个中间路由器的 QoS 策略有问题，它把音视频包标记成了低优先级，导致包被随机丢弃和延迟。我们跟运营商沟通后，调整了 DSCP 标记，抖动才降下来。
4.5 反馈同步的整体架构
把上面四个手段串起来，就构成了一个完整的反馈同步闭环：
这个闭环里，RTCP 是信使，NACK 是急救员，延迟反馈是减速带，抖动反馈是稳定器。四者配合，才能让音视频同步在复杂网络下保持稳定。
4.6 实战中的避坑指南
最后，分享几个我在项目中踩过的坑：
- RTCP 间隔别太短：我曾经设成 100ms，结果控制报文占掉 10% 带宽。建议按标准走，5% 以内。
- NACK 重传别无限等：设一个超时时间，比如 200ms。超时了就放弃，别让播放线程死等。
- 延迟反馈别只看一次：单次延迟飙升可能是噪声，用 EMA 平滑后再判断。
- 抖动反馈要区分场景：直播场景对抖动容忍度高，实时通话容忍度低。阈值要按场景调。
我的建议：在调试反馈同步时，先把 RTCP 日志打开，观察丢包率、抖动、RTT 三个指标的变化趋势。很多时候，问题就藏在这些数字的「异常波动」里。
反馈同步不是一锤子买卖，而是一个持续优化的过程。你调好了码率，网络变了；你调好了缓冲区，内容变了。所以，保持监控，持续调整，才是王道。