音视频面试题集锦 54 期：WebRTC 相关面试题

分享来自“关键帧Keyframe”公众号的音视频面试题集锦 54 期之 WebRTC 面试题。

1、【连接与网络篇】当用户从 Wi-Fi 切换到 4G 网络时，WebRTC 的连接通常会中断。请详述 ICE Restart 的触发流程是怎样的？在这个过程中，客户端需要重新进行 SDP 协商吗？ufrag 和 pwd 字段会发生什么变化？

考察点： ICE 状态机、网络切换处理、STUN/TURN 重新收集。

参考答案：

背景：当网络接口发生变化（IP 地址变了），原本建立好的 P2P Socket 连接（5-tuple）失效，必须重启 ICE 流程。

ICE Restart 流程：

1. 检测网络变更： 客户端（Native 层）监听系统网络回调（如 iOS NWPathMonitor 或 Android ConnectivityManager），检测到 IP 变化。
2. 触发 Restart： * 调用 peerConnection.restartIce()。
   • 这会导致 WebRTC 内部重新生成 ICE 相关的凭证，即 ice-ufrag (Username Fragment) 和 ice-pwd (Password) 发生变化。这是区分“旧连接”和“新尝试”的关键标志。
3. 重新协商 (Renegotiation) – 必须步骤：
   • 仅仅收集 Candidate 是不够的，必须将新的 ufrag/pwd 告诉对方。
   • 发起方创建新的 Offer (createOffer)，此时生成的 SDP 中包含新的 ufrag/pwd。
   • 双方完成一次完整的 SetLocal / SetRemote (Offer/Answer) 交换。
4. 收集新 Candidate： 伴随着新的 SDP，客户端开始在新网络接口上向 STUN/TURN 服务器发送 Binding Request，收集新的 host, srflx, relay 候选者并通过 Signaling 发送给对方。
5. 连通性检查： 双方对新的候选者对进行 STUN Ping/Pong 检查，选出新的最佳路径，恢复媒体流。

2、【标准与兼容篇】WebRTC 标准化过程中，Plan B 和 Unified Plan 是两种处理多路流（Multi-stream）的 SDP 格式。请解释它们在 SDP 结构上的核心区别是什么？为什么现在的 WebRTC 标准强制使用 Unified Plan？

考察点： SDP 语义、M-line 概念、Transceiver 模型。

参考答案：

核心区别：m= 行 (Media Line) 的使用方式。

1. Plan B (旧标准，Chrome 曾主推):
   • 结构： 整个 SDP 中，同一种媒体类型（如视频）**只有一行 m=video**。
   • 多流表示： 如果有 3 路视频流，它们全部挤在这一行 m= 下面，通过 a=ssrc 属性来区分不同的流（Stream ID）和轨道（Track ID）。
   • 缺点： 此时 SDP 无法准确描述每一路流的方向（SendRecv/SendOnly）和编码参数。如果一路要 H.264，一路要 VP8，Plan B 很难表达。
2. Unified Plan (现行标准，IETF 制定):
   • 结构：每一路流对应一个独立的 m= 行。
   • 多流表示： 如果有 3 路视频流，SDP 中就会有 3 个 m=video ... 部分。
   • 优点： 每一路流都可以独立配置方向（a=sendonly）、编码器（Payload Type）、RTCP 反馈机制等。
   • Transceiver 映射： WebRTC 代码中的 RtpTransceiver 对象与 SDP 中的 m= 行是一一对应的。这使得“添加/移除轨道”的操作逻辑非常清晰。

为什么强制 Unified Plan：Plan B 存在严重的互操作性问题（尤其是在与 Firefox 或硬件终端通信时）。Unified Plan 提供了更细粒度的控制，支持更复杂的场景（如：同时发送一路 H.264 和一路 AV1）。目前 Chrome 和 Safari 均已默认弃用 Plan B。

3、【数据通道篇】WebRTC 的 DataChannel 是基于 SCTP (Stream Control Transmission Protocol) 协议实现的。请问 SCTP over DTLS over UDP 相比于直接使用 TCP WebSocket 有什么优势？DataChannel 的 Head-of-Line Blocking (队头阻塞) 问题在什么配置模式下会发生？

考察点： SCTP 协议特性、可靠性与有序性、网络分层。

参考答案：

SCTP over UDP 的优势：

1. NAT 穿透： 既然 WebRTC 已经用 ICE 打通了 UDP P2P 通道，DataChannel 直接复用这个通道，无需像 TCP 那样重新握手或处理复杂的 NAT 映射。
2. 避免 TCP 的队头阻塞 (全局)： TCP 是严格有序的字节流，如果包 #2 丢了，即使包 #3, #4 到了，应用层也读不到，必须等 #2 重传。SCTP 支持**多流 (Multi-streaming)**，流 A 的丢包不会阻塞流 B 的数据读取。

DataChannel 的配置与队头阻塞：DataChannel 允许开发者配置两个属性：ordered (是否有序) 和 maxRetransmits (可靠性)。

• Head-of-Line Blocking 发生场景：当配置为 ordered = true (默认模式) 时。 虽然 SCTP 允许多流，但在同一个 DataChannel ID 内，如果为了保证消息按顺序到达，一旦中间某个包丢失，SCTP 必须在接收端缓存后续到达的包，等待丢失包重传成功后才能向上层递交。这就是局部的队头阻塞。
• 如何避免：对于实时性要求极高的数据（如游戏操作指令：最新的指令覆盖旧指令），应设置 **ordered = false**。此时，后发的包如果先到了，应用层会立即收到，不会等待丢失的前序包。

4、【音频处理篇】WebRTC 的音频处理模块 (APM) 中，AEC (回声消除) 是一项艰巨的任务。请解释什么是 “Double Talk” (双讲) 场景？为什么它会导致回声消除算法失效或出现“吞音”现象？WebRTC 是如何处理的？

考察点： 信号处理、非线性滤波 (NLP)、自适应滤波器。

参考答案：

Double Talk (双讲)：指远端说话人（参考信号 Reference）和近端说话人（麦克风采集信号）同时在说话的场景。

为什么难：

• AEC 的核心是建立一个自适应滤波器（Linear Filter），试图模拟扬声器到麦克风的物理路径（回声路径），从采集信号中减去参考信号。
• 滤波器系数的更新依赖于“误差信号”。在双讲时，近端说话人的声音变成了极大的“干扰噪音”，导致滤波器误以为回声路径变了，开始错误地调整系数（发散）。
• 后果： 滤波器可能把近端人声也当成回声给“消除”掉（吞音），或者无法收敛导致回声泄漏。

WebRTC 的处理策略：

1. 双讲检测 (DTD): 首先检测是否处于双讲状态（通过对比远端信号和近端信号的能量相关性）。
2. 冻结系数： 一旦检测到双讲，立即停止更新自适应滤波器的系数，保持之前的状态。只进行滤波操作，不进行学习。
3. NLP (非线性处理) 调整： 在线性滤波后，通常有个 NLP 模块用来切除残留回声（类似于降噪门）。在双讲时，WebRTC 会调低 NLP 的激进程度，宁可漏一点回声，也不能把近端人声切掉（这也是为什么双讲时偶尔能听到一点回声的原因）。

5、【码率控制篇】WebRTC 发送端有一个组件叫 “Pacer (平滑发送器)”。它的作用是什么？当带宽预测 (BWE) 认为当前带宽有 2Mbps，但实际视频编码码率只有 500Kbps 时，WebRTC 会发送 Padding 包。请问这些 Padding 包有什么具体作用？它们会占用 Pacer 的预算吗？

考察点： 发送端架构、漏桶算法、抗抖动、Probing 机制。

参考答案：

Pacer 的作用：视频编码器输出的帧是一簇一簇的（Key Frame 很大，P 帧较小）。如果编码完一帧立即把所有 UDP 包“突发”发出去，会导致网络瞬间拥塞、路由器 buffer 溢出并丢包。 Pacer 像一个**漏桶 (Leaky Bucket)**，它将这些突发的数据包缓存起来，按照 BWE 计算出的目标码率，均匀地（通常每 5ms 发一次）发送到网络中，平滑网络抖动。

Padding (填充包) 的作用：当 Encoder Bitrate < Target Bitrate 时（例如静止画面，编码器输出很低，但带宽很好），WebRTC 会发送 Padding 包（通常是 RTX 包或重复包）来填补空缺。

1. 保活带宽估计 (Keep-alive BWE): 如果长时间只发 500Kbps，基于延迟的 BWE 算法会慢慢“遗忘”之前探测到的 2Mbps 高带宽，误以为链路只能承载 500Kbps。一旦画面突然变复杂（需要 2Mbps），BWE 会限制发送，导致模糊。Padding 维持了“高水位”的带宽占用。
2. 探测更高带宽 (Probing): 有时为了探测带宽上限（Alr Probing），也会发送 Padding。

Pacer 预算：会占用。Pacer 的发送预算（Pacing Rate）通常略高于 BWE 的预估带宽（例如 factor * BWE）。无论是真实的 Video 包还是 Padding 包，都要经过 Pacer 排队。Pacer 会优先发送 Video 包，如果 Video 包不够且需要探测/保活时，才发送 Padding 包。

学习和提升音视频开发技术，推荐你加入我们的知识星球