标准 WebRTC 弱网策略四件套

一、概念：

SDP、ICE 属于【信令】：是两端用来协商怎么建立连接的描述信息，不是音频本身。

音频流（RTP 包）属于【媒体】：就是真正的声音数据。

信令服务器只负责交换 SDP/ICE，音频 RTP 两端 P2P UDP 直传；接收端开启抖动缓冲（Jitter Buffer）平滑网络抖动、开启 NACK 丢包重传做弱网修复，全程音频流量不经过服务器。
区别SFU（选择性转发单元）：SDP 信令走服务端，媒体全部由服务端分发。

MCU（Multipoint Control Unit，多点控制单元）混音架构，和 SFU 选择性转发模式不同：服务端对各路媒体先解码、PCM 混音合成单路音频，再重新编码下发给所有客户端。

• SFU：RTP 包不解码，原样转发，下行多路独立音频流。
• MCU：解码 → PCM 混音 → 重编码，所有客户端下行只收到一路混合音频流。

二、流量路径对比：

1、P2P 模式：

A <--(SDP/ICE)--> 信令服务器 <--(SDP/ICE)--> B
A <----音频RTP----> B
优点：媒体直连，服务器无音频带宽消耗。

2、中转模式（TURN / SFU）：

A --> 服务器（转发音频） --> B
缺点：音频全部经过服务器，服务器要扛媒体带宽。
补充：ICE 里面也包含 TURN 候选，如果 P2P 直连失败，ICE 会自动降级走 TURN，这时音频就又走 TURN 服务端了，这是 ICE 的自动兜底。

三、WebRTC RTP 弱网四件套：

1、Jitter Buffer（抖动缓冲）：

接收端的 “蓄水池”，解决包到达忽快忽慢、乱序。接收端解决「包到达快慢不稳、乱序」，牺牲一点延迟换平滑播放。

2、NACK（Negative ACK，选择性重传，事后补救）修复：

接收端发现丢包后，主动请求发送端重传丢的 RTP 包，两者配合，就是 P2P 音频里弱网抗卡顿的核心组合（WebRTC 音频里 NetEQ 就是带自适应 jitter buffer + 丢包补偿）。

- TCP 是 ACK：收到包告诉发送方 “收到了”。
- NACK 反过来：接收端看到序列号断了（空洞），发 RTCP 反馈：我缺 seq=105、107，请重发。
- NACK 是选择性重传，只重传丢的那几个包，不是全部重传。
- 重传：发送端收到 NACK 之后，把之前发过、还在缓存里的 RTP 包再发一次，是 NACK 对应的动作。

3、FEC（Forward Error Correction，前向纠错，提前带冗余）：

发送方提前附加冗余包，丢包之后接收端本地直接恢复，不用请求重传。比如每发 3 个音频包，附带 1 个 FEC 冗余包；3 个里丢任意 1 个，接收端靠冗余本地算出丢失包。

4、TCC（Transport-wide Congestion Control，传输层拥塞控制。管带宽、防堵，不是用来修已经丢的包）：

接收端统计所有 RTP 包的到达时间，给发送端反馈网络延迟、带宽、队列拥塞，让发送端提前降码率/降发送速度，从源头减少丢包。

四、联动流水线：

发送侧：
TCC评估带宽 → 按允许码率发送RTP包
↳ 附加FEC冗余包（可选）
↳ 维护RTP历史缓存，准备响应NACK

网络：抖动、乱序、丢包

接收侧：
RTP包 → JitterBuffer排序缓存
① 先尝试FEC本地恢复丢包（最快，无额外延迟）
② FEC恢复不了，检测序列号空洞 → 发送NACK请求重传
③ 持续统计包到达间隔 → 发送TCC反馈，通知发送端降码率防拥塞
④ 重传包到达，填入JB；超时没等到，NetEQ插值兜底