WebRTC 从信令到 NAT 穿透（SDP / ICE / STUN / TURN）

很多人第一次接触 WebRTC 会卡在两件事上：

1. 明明我只是想"点对点视频通话"，为什么还要服务器？
2. 为什么在公司/宿舍网络里有时候能通、有时候完全不通？

本质原因是：WebRTC 不只是"音视频编码"，它更难的是"连接协商 + NAT 穿透"。

这篇文章按"能讲清 + 能排障"的顺序，梳理 WebRTC 的核心链路。

阅读目标：

• 看完能讲清：信令、SDP、ICE、STUN、TURN 的分工与整体流程
• 看完能排障：遇到"能交换 SDP 但连不上""某些网络必失败"时，你知道从哪查

目录

• 1. WebRTC 是什么
• 2. WebRTC 组成
• 3. 为什么必须要信令服务器
• 4. SDP Offer/Answer 交换了什么
• 5. ICE/STUN/TURN：穿透与兜底
• 6. 一张图讲清协商流程（工程版）
• 7. TURN 成本与部署注意
• 8. 常见问题与排障清单
• 9. 项目里怎么讲（WebSocket 做信令）
• 10. 30 秒面试模板

---

1. 一句话理解 WebRTC

WebRTC 是浏览器/客户端之间的实时音视频与数据通信方案，核心解决：

• 低延迟媒体传输
• NAT 穿透

它的协商靠 信令（Signaling），媒体传输走 SRTP，数据通道走 SCTP over DTLS。

---

2. WebRTC 的组成（你背这 4 个关键词就够）

• 媒体通道：音视频（SRTP）
• 数据通道：DataChannel（SCTP over DTLS）
• 安全：DTLS + SRTP
• 协商描述：SDP

这也是面试里最常被追问的一组。

---

3. 为什么必须要"信令服务器"（必问）

WebRTC 并不规定信令协议，但你必须有信令来交换"协商所需的信息"，包括：

• SDP Offer/Answer（媒体能力、编码、端口等）
• ICE Candidates（候选地址）

信令可以用什么实现？

• WebSocket
• HTTP
• MQTT

只要能可靠传递协商消息就行。

所以"为什么需要服务器"的标准回答是：

• 不是媒体必须走服务器，而是协商必须有通道。
• 真正的媒体流尽量 P2P；只有打洞失败才降级走 TURN 中继。

---

4. SDP：Offer/Answer 在交换什么

SDP（Session Description Protocol）可以理解成"双方能力说明书"，包括：

• 支持的音视频编码
• 分辨率/码率能力
• 端口、传输信息

典型流程：

1. A 创建 offer（包含能力与初始候选信息）
2. 通过信令发送给 B
3. B 设置 remote description 后创建 answer
4. 双方继续交换 ICE candidates

你可以把它理解为：

• SDP 解决"我们用什么参数通话"
• ICE 解决"我们怎么连得上"

---

5. NAT 穿透核心：ICE / STUN / TURN（必问）

5.1 ICE 是什么

ICE 是候选地址收集与连通性检查机制：

• 收集本地地址（host candidate）
• 收集反射地址（srflx candidate，通过 STUN 获取）
• 收集中继地址（relay candidate，通过 TURN 获取）
• 不断做连通性检查，选出最佳路径

5.2 STUN 是什么

STUN 用来让客户端知道"外网看到我的地址是什么"：

• 拿到公网反射地址
• 对大多数锥形 NAT 场景有效

5.3 TURN 是什么（兜底）

当 P2P 打洞失败时，就走 TURN 中继：

• 更稳定
• 但更贵（带宽成本）
• 延迟更高

标准面试说法：

• 优先 P2P（STUN）
• 失败再降级 TURN 中继

---

6. 一张图讲清协商流程（工程版）

你可以把 WebRTC 连接建立拆成三段：

1. 信令通道建立（WebSocket/HTTP）：只负责"交换信息"，不传媒体
2. SDP 协商：交换编解码能力与会话描述
3. ICE 连通性检查：收集候选地址并探测哪条路能通

工程上可以用这个"流程图"讲清楚：

A(浏览器)                 信令服务                 B(浏览器)
   |--- websocket connect ----->|<---- websocket connect ---|
   |--- SDP Offer ------------->|------------ SDP Offer ---->|
   |<-- SDP Answer -------------|<----------- SDP Answer ----|
   |--- ICE candidates -------->|----------- ICE candidates ->|
   |<-- ICE candidates ---------|<---------- ICE candidates --|
   |========== ICE checks (UDP/TCP) ==========>|
   |========== 选出最佳通路后建立媒体通道 ==========>|

候选地址通常会包含三类：

• host：内网地址
• srflx：通过 STUN 获取的公网反射地址
• relay：通过 TURN 分配的中继地址

ICE 的工作就是：

• 尝试各种 candidate 组合
• 谁能连通就选谁（优先 P2P，其次 relay）

---

7. TURN 成本与部署注意

TURN 是"兜底保可用"，但要提前接受代价：

• 带宽成本：媒体流经过 TURN，中继服务器要扛上行/下行
• 延迟增加：绕一跳
• 部署要求 ：
  • 公网可达
  • 需要开放 UDP（常见 3478）及中继端口范围

工程建议：

• 把 TURN 作为必须项准备好（否则你很难保证在公司/校园网的可用性）
• 但默认仍让 ICE 优先走 P2P，只有失败才使用 relay candidate

---

8. 常见问题与排障（博客必须写）

8.1 能交换 SDP 但连不上

常见原因：

• NAT 类型不支持直连
• 防火墙/公司内网限制 UDP

解决：

• 配 TURN
• 检查候选地址是否收集到 relay candidate

再补一个排障思路（很实用）：

• 如果 candidates 里只有 host/srflx，没有 relay，大概率 TURN 不可用或配置没生效
• 如果在公司网/校园网必失败，优先怀疑 UDP 被限制或是对称 NAT

8.2 回声/啸叫

• 回声消除、音频处理
• 耳机/设备问题

8.3 多人会议为什么不是纯 P2P

多人 P2P 会导致：

• 每个客户端要同时推多路上行，带宽爆炸

工程上常用：

• SFU（选择性转发）
• MCU（混流）

---

9. 项目里怎么讲（WebSocket 做信令）

即使你的项目没真的做 WebRTC，你也可以用"架构理解"来讲：

• WebRTC 本身不规定信令协议，所以工程里常用 WebSocket 做信令。
• 信令服务只负责转发 offer/answer/candidates，不参与媒体流。
• 媒体优先 P2P，失败走 TURN 中继兜底。

如果你想把它落到"工单系统"场景，可以这么说：

• 远程协助：维修人员与学生通过 WebRTC 视频确认故障
• WebSocket 作为信令（复用现有 token 鉴权与连接治理）

---

你也可以用"通用模板"回答（更适合面试 30 秒展开）：

• 我理解 WebRTC 的关键不在编码，而在"协商与穿透"。
• 信令负责交换 SDP 和 ICE candidates，媒体尽量走 P2P；
• NAT 穿透靠 ICE + STUN/TURN，TURN 作为兜底保证可用性。
• 真正落地时还要考虑多方会议架构（SFU）和网络自适应。

---

10. 30 秒回答模板

WebRTC 用于实时音视频，核心链路是：信令交换 SDP（能力协商）和 ICE candidates（连接协商），NAT 穿透靠 ICE + STUN/TURN，优先 P2P 直连，失败走 TURN 中继兜底。落地时还要考虑安全（DTLS/SRTP）、网络波动下的自适应，以及多人会议常用 SFU。