WebRTC 入门指南：核心原理、连接流程与实战挑战
介绍 WebRTC 的核心 API、Offer/Answer 与 ICE 建连流程。
WebRTC (Web Real-Time Communication) 是一项支持网页浏览器和移动应用进行实时音视频通信的开源项目和技术标准。它允许开发者不依赖插件或第三方软件，直接在浏览器中实现点对点（Peer-to-Peer）的音视频通话、数据传输和屏幕共享。
🧱 WebRTC 核心组成
WebRTC 的核心 API 分为三大部分（均挂载在 window.RTCPeerConnection 上）：
| API 类别 | 作用 | 关键对象/方法 |
|---|---|---|
| 媒体获取 | 获取用户的摄像头、麦克风、屏幕流 | getUserMedia(), getDisplayMedia() |
| 点对点连接 | 建立、管理浏览器之间的直接连接，传输媒体和数据 | RTCPeerConnection (核心), RTCDataChannel |
| 信令（辅助） | 交换连接元数据（Session Description, ICE Candidates），WebRTC 本身不定义信令协议，需要开发者自己实现（如 WebSocket, SIP） | createOffer(), setLocalDescription(), addIceCandidate() |
🔄 建立连接的经典流程（信令 + 连接）
- 用户 A 调用
getUserMedia获取媒体流。 - A 创建
RTCPeerConnection对象，将媒体流加入其中。 - A 创建 Offer (SDP)，通过信令通道发送给 B。
- B 收到 Offer，创建 Answer (SDP)，返回给 A。
- 双方开始 ICE (Interactive Connectivity Establishment) 候选信息交换，尝试找到最佳的网络路径（直连或通过 TURN 中继服务器）。
- ICE 协商成功后，建立点对点连接，媒体流开始传输。
关键点：信令服务器（通常用 WebSocket）不处理媒体数据，只负责交换控制信息，因此非常轻量。
⚡ 核心技术点
-
ICE (Interactive Connectivity Establishment)：整合 STUN (Session Traversal Utilities for NAT) 和 TURN (Traversal Using Relays around NAT) 协议，解决 NAT 穿透问题。
- STUN 服务器：协助找出客户端的公网 IP 和端口（适合对称 NAT 之外的情况）。
- TURN 服务器：当点对点直连失败时，作为中继转发媒体流（消耗带宽较大）。
-
SRTP (Secure Real-time Transport Protocol)：加密媒体流，保证通信安全。
-
SCTP (Stream Control Transmission Protocol)：用于
RTCDataChannel的数据传输，提供可靠/不可靠、有序/无序的通道，支持类似 WebSocket 的数据发送。 -
编解码器：默认支持 VP8、VP9、H.264 视频，Opus 音频；可硬件加速。
📱 常见应用场景
| 场景 | 例子 |
|---|---|
| 视频会议 | Google Meet, Zoom Web, Jitsi Meet |
| 在线客服/呼叫中心 | Web 端实时通话、屏幕共享 |
| 实时互动教学/医疗 | 白板协作、文件共享 |
| 多人游戏/元宇宙 | 低延迟语音聊天，RTCDataChannel 传输状态数据 |
| 直播连麦 | 观众与主播实时互动（非 CDN 推流） |
| 文件点对点传输 | 类似 ShareDrop，不经过服务器中转 |
✅ 优点与 ❌ 缺点
优点：
- 跨平台：浏览器内置，无需安装插件。
- 低延迟：通常点对点直连，比传统 HLS/RTMP 推流方案延迟更低（可达 < 500ms）。
- 安全：强制加密（SRTP），且信令只是控制平面。
- 开源免费：浏览器已集成，不需要支付许可费。
缺点：
- 信令服务器仍需自己搭建：WebRTC 没有规定信令协议，开发者需要实现 WebSocket 或 SIP 服务器用于控制信令交换。
- 连接成功率并非 100%：某些严格对称 NAT 或防火墙环境可能必须使用 TURN 中继（成本较高）。
- 开发复杂度较高：需要处理 ICE 状态、媒体协商、带宽适配、回音消除等。
- 大规模通讯（SFU 模式）：超过 2 人的多人会议时，单纯点对点（Mesh）会导致上行带宽和 CPU 激增，需要部署 SFU (Selective Forwarding Unit) 服务器合流转发——增加了架构复杂度和成本。
🆚 WebRTC vs 其他实时方案
| 方案 | 延迟 | 适用场景 | 插件/依赖 |
|---|---|---|---|
| WebRTC | < 500ms | 实时互动、视频会议、游戏 | 无 |
| HLS (HTTP Live Streaming) | 10-30s | 直播、点播，大规模分发 | 无（现代浏览器支持） |
| RTMP (Real-Time Messaging Protocol) | 2-5s | 推流到直播平台 | Flash 已淘汰，现多为推流端 |
| WebSocket + AJAX | 可变（取决于轮询） | 实时数据推送、聊天 | 无 |
| 私有插件 (Flash, Silverlight) | 低 | 历史遗留 | 需要插件，已淘汰 |
🧪 如何学习/使用 WebRTC
- 依赖环境：现代浏览器（Chrome, Firefox, Safari, Edge），Node.js 或任意后端语言写信令服务器。
- 简单尝试：使用
RTCPeerConnection+getUserMedia实现一个 1v1 视频通话（可配合socket.io做信令）。 - 继续深入：
- 掌握 STUN/TURN 部署（可使用公共 STUN 服务器，或自建 coturn）。
- 学习 SFU 架构（如使用
mediasoup、Janus、Jitsi Videobridge）。 - 了解
RTCDataChannel用于实时文本/文件传输。 - 研究带宽自适应、回音消除（AEC）、噪声抑制等音视频处理。
📚 资源推荐
- 官方文档：WebRTC 官方网站，MDN WebRTC API
- 学习项目：Google codelabs 的 “Real-time communication with WebRTC”
- 开源示例：
webrtc/samples(官方 demo)，simple-peer(Node.js 封装库) - SFU 服务器：
mediasoup(Node.js)、Janus(C)、Jitsi Meet(Java/JS)
❓ 总结对 WebRTC 的了解
WebRTC 的核心 API、建立连接的 ICE/STUN/TURN 机制、媒体与数据传输、实际应用场景、常见挑战（如 NAT 穿透、SFU 架构）以及如何与其他技术（如 WebSocket）配合。后续学习具体的问题——例如“如何实现屏幕共享并传输高质量视频”、“怎么部署一个简单的 TURN 服务器”、“多人视频会议的最佳架构选择”等。