一、先讲结论（你先建立整体认知）

WebRTC 本质 = 用 UDP 做的 P2P 实时通信 + 一套“打洞 + 协商”机制

它不是一个“简单的库”，而是一整套机制：

信令交换 + NAT穿透 + P2P连接 + 实时传输

二、核心问题：两个设备为什么连不上？

你必须先搞懂这个，否则 WebRTC 永远理解不了。

现实网络是这样的：

手机A（内网） → 路由器 → 互联网 → 路由器 → 手机B（内网）

👉 问题：

• A 不知道 B 的真实地址 ❌
• B 也不知道 A ❌
• 路由器（NAT）挡住了 ❌

本质问题就一句话：

两个内网设备，默认是无法直接通信的

三、WebRTC 怎么解决？（核心三件事）

1️⃣ 先“互相介绍自己”（信令）

注意：

👉 WebRTC 不会帮你传这些信息，你必须自己搞

A 和 B 要交换什么？

- 我支持什么编码（视频/音频）
- 我用哪个端口
- 我的网络信息（IP）

这个交换过程：

A → 服务器 → B
B → 服务器 → A

👉 这个服务器就叫：

信令服务器（Signaling Server）

重点：

WebRTC 连接之前，必须靠信令“撮合”

四、第二个难点：NAT 穿透（打洞）

为什么不能直接连？

因为：192.168.x.x（内网IP） → 外网访问不了

WebRTC 的解决方案：

方案1：STUN（打洞）

作用：

帮你知道“我在公网看起来是谁”

流程：

A → STUN服务器：我是谁？
STUN → A：你公网IP是 1.2.3.4:5000

然后：

A 把这个地址告诉 B
B 尝试连接这个地址

👉 如果成功：

✅ P2P 直连建立

方案2：TURN（兜底）

如果打洞失败：A → TURN → B

👉 所有数据走服务器中转

本质：

技术	本质
STUN	找路径
TURN	走代理

五、真正建立连接（核心过程）

关键对象：PeerConnection

它干的事情：

- 管理连接
- 处理网络切换
- 发送数据

整体流程（你必须能背下来）

第一步：A 创建 Offer

A：我想跟你通信，这是我的能力

第二步：通过信令发给 B

A → 信令服务器 → B

第三步：B 回复 Answer

B：可以，我也支持这些

第四步：交换 ICE 候选（最关键🔥）

👉 什么是 ICE？

所有可能的通信路径集合

比如：

- 内网IP
- 公网IP（STUN）
- TURN地址

👉 双方不断尝试这些路径：哪个能通，就用哪个

第五步：连接建立

A ↔ B（直连 or 中继）

六、数据是怎么传的？

音视频：

WebRTC → RTP（基于 UDP）

特点：

• 实时性优先
• 丢包可以接受

---

数据（控制命令）：

RTCDataChannel

👉 类似：

• WebSocket（但走 P2P）

七、为什么 WebRTC 一定用 UDP？

TCP 问题：

• 丢包必须重传 → 卡顿
• 延迟高

✅ UDP 优势：

• 不保证可靠 → 但快
• 可以自己控制重传策略

👉 本质：

WebRTC 是“实时优先”，不是“绝对可靠”

八、整个 WebRTC 本质架构

信令服务器（你自己实现）
↑ ↓
Offer/Answer/ICE
↑ ↓

A 设备 ←→ B 设备
↓ ↓
STUN / TURN（辅助）

九、用一句话讲清整个过程（面试杀手级）

WebRTC 通过信令服务器交换连接信息（Offer/Answer/ICE），利用 STUN 获取公网地址并进行 NAT 穿透，优先建立 UDP 的 P2P 直连；如果失败则通过 TURN 中继，最终基于 RTP 进行低延迟音视频或数据传输。

十、必须真正理解的三个“本质”

---

本质1：WebRTC 不负责“找人”

👉 它只负责：连通 + 传输

找人靠：信令服务器（WebSocket）

本质2：WebRTC 核心是“打洞”

👉 如果没有 NAT 问题：

其实根本不需要这么复杂

本质3：WebRTC = 工业级 UDP 封装

👉 帮你解决：

• 丢包处理
• 抖动缓冲
• 编解码
• 网络切换

十一、总结

WebRTC 的本质不是“音视频框架”，而是一套完整的实时通信体系：

通过信令协商建立连接，

利用 NAT 穿透实现 P2P 通信，并基于 UDP 实现低延迟的数据传输。

它解决的核心问题不是“怎么传”，而是“如何在复杂网络环境下让两个设备连起来并稳定通信”。