WebRTC 原理一篇讲透（从 0 到本质）

一、先讲结论你先建立整体认知WebRTC 本质 用 UDP 做的 P2P 实时通信 一套“打洞 协商”机制它不是一个“简单的库”而是一整套机制信令交换 NAT穿透 P2P连接 实时传输二、核心问题两个设备为什么连不上你必须先搞懂这个否则 WebRTC 永远理解不了。现实网络是这样的手机A内网 → 路由器 → 互联网 → 路由器 → 手机B内网 问题A 不知道 B 的真实地址 ❌B 也不知道 A ❌路由器NAT挡住了 ❌本质问题就一句话两个内网设备默认是无法直接通信的三、WebRTC 怎么解决核心三件事1️⃣ 先“互相介绍自己”信令注意 WebRTC不会帮你传这些信息你必须自己搞A 和 B 要交换什么- 我支持什么编码视频/音频- 我用哪个端口- 我的网络信息IP这个交换过程A → 服务器 → BB → 服务器 → A 这个服务器就叫信令服务器Signaling Server重点WebRTC 连接之前必须靠信令“撮合”四、第二个难点NAT 穿透打洞为什么不能直接连因为192.168.x.x内网IP → 外网访问不了WebRTC 的解决方案方案1STUN打洞作用帮你知道“我在公网看起来是谁”流程A → STUN服务器我是谁STUN → A你公网IP是 1.2.3.4:5000然后A 把这个地址告诉 BB 尝试连接这个地址 如果成功✅P2P 直连建立方案2TURN兜底如果打洞失败A → TURN → B 所有数据走服务器中转本质技术本质STUN找路径TURN走代理五、真正建立连接核心过程关键对象PeerConnection它干的事情- 管理连接- 处理网络切换- 发送数据整体流程你必须能背下来第一步A 创建 OfferA我想跟你通信这是我的能力第二步通过信令发给 BA → 信令服务器 → B第三步B 回复 AnswerB可以我也支持这些第四步交换 ICE 候选最关键 什么是 ICE所有可能的通信路径集合比如- 内网IP- 公网IPSTUN- TURN地址 双方不断尝试这些路径哪个能通就用哪个第五步连接建立A ↔ B直连 or 中继六、数据是怎么传的音视频WebRTC → RTP基于 UDP特点实时性优先丢包可以接受数据控制命令RTCDataChannel 类似WebSocket但走 P2P七、为什么 WebRTC 一定用 UDPTCP 问题丢包必须重传 → 卡顿延迟高✅ UDP 优势不保证可靠 → 但快可以自己控制重传策略 本质WebRTC 是“实时优先”不是“绝对可靠”八、整个 WebRTC 本质架构信令服务器你自己实现↑ ↓Offer/Answer/ICE↑ ↓A 设备 ←→ B 设备↓ ↓STUN / TURN辅助九、用一句话讲清整个过程面试杀手级WebRTC 通过信令服务器交换连接信息Offer/Answer/ICE利用 STUN 获取公网地址并进行 NAT 穿透优先建立 UDP 的 P2P 直连如果失败则通过 TURN 中继最终基于 RTP 进行低延迟音视频或数据传输。十、必须真正理解的三个“本质”本质1WebRTC 不负责“找人” 它只负责连通 传输找人靠信令服务器WebSocket本质2WebRTC 核心是“打洞” 如果没有 NAT 问题其实根本不需要这么复杂本质3WebRTC 工业级 UDP 封装 帮你解决丢包处理抖动缓冲编解码网络切换十一、总结WebRTC 的本质不是“音视频框架”而是一套完整的实时通信体系通过信令协商建立连接利用 NAT 穿透实现 P2P 通信并基于 UDP 实现低延迟的数据传输。它解决的核心问题不是“怎么传”而是“如何在复杂网络环境下让两个设备连起来并稳定通信”。