WebRTC 完全教程：浏览器实时音视频通信
深度讲解 WebRTC 三大 API、ICE/STUN/TURN 穿透原理、P2P vs SFU vs MCU 架构、行业产品对比与自建部署方案，从基础到实战。
实时音视频通信曾经只存在于高端视频会议系统中，需要昂贵的硬件和专业部署。WebRTC（Web Real-Time Communication）的出现彻底改变了这一现状。今天，任何开发者都可以在浏览器中通过几百行 JavaScript 代码实现媒体捕获、编码、传输、解码的全套流程。从视频通话、在线教育、远程协作，到实时直播、游戏语音，WebRTC 已成为互联网实时通信的基石。本教程深度剖析 WebRTC 的核心 API、网络穿透原理、不同服务端架构的权衡，以及如何从零开始自建或选型商用方案。
WebRTC 的三大核心 API
WebRTC 提供了三个主要接口来实现音视频通信：
getUserMedia 负责从本地设备（麦克风、摄像头）获取音视频流。它返回一个 MediaStream 对象，包含多个音频轨和视频轨。调用时会触发浏览器权限弹窗，用户同意后才能访问硬件。
RTCPeerConnection 是核心引擎。它管理与远端对端的连接生命周期：信令交换（SDP offer/answer）、ICE 候选地址采集与配对、媒体编码与传输、统计信息采集。两个浏览器要建立 P2P 连接，必须各创建一个 RTCPeerConnection 实例，通过一个中央信令服务器交换 SDP 和 ICE。
RTCDataChannel 用于传输任意二进制或文本数据（非音视频）。它建立在同一条 P2P 连接上，可做低延迟的游戏状态同步、实时协作编辑、文件传输。相比 WebSocket，数据通道避免了中央服务器，纯端到端。
ICE、STUN、TURN：网络穿透的三驾马车
互联网上的两个浏览器要直接通信，需要知道彼此的 IP 地址和端口。但大多数用户都躲在 NAT（网络地址转换）和防火墙后面，外部看不见他们真实地址。ICE（Interactive Connectivity Establishment）框架就是为了解决这个问题。
STUN（Session Traversal Utilities for NAT）是一个简单的 UDP 协议。浏览器向 STUN 服务器发送请求，服务器回复"你的外网 IP 和端口是 X"。这样浏览器就知道了 NAT 映射后的公网地址，可以通知对端来连接。STUN 是免费且廉价的，Google 提供了公开的 STUN 服务器。
但 STUN 有局限：在某些严格的企业防火墙或对称 NAT 后，STUN 探测不出可用地址。此时需要 TURN（Traversal Using Relay NAT）。TURN 是一个中继服务器，浏览器把所有媒体数据都发往 TURN 服务器，TURN 再转发给对端。这样绕过了 NAT，但代价是服务器成本。
ICE 联合这两者：先尝试 P2P 直连（通过 STUN），如果失败再回退到 TURN 中继。过程对应用层透明。
P2P vs SFU vs MCU：服务端架构的三种选择
当用户数 > 2 时，单纯 P2P 开始暴露问题。如果要支持 N 个参与者的多方通话，有三种架构思路：
P2P（完全分布式）：每个参与者与其他所有参与者建立点对点连接。优点是零中央服务器，延迟最低，成本最省。缺点是上行带宽浪费、客户端 CPU 负担重。实际中只适合 2-4 人小规模通话。
SFU（Selective Forwarding Unit）：每个参与者与服务器建立一条连接，上传自己的流；从服务器下载其他参与者的流。服务器不做编码转换，只负责选择性转发。优点是扩展性好、延迟中等、上行带宽均匀。Google Meet、Zoom 的大会议用的就是 SFU。
MCU（Multipoint Control Unit）：服务器接收所有参与者的流，重新编码成一路混合流后下发给所有人。优点是下游客户端只需处理一路流。缺点是服务器 CPU 负担极重、延迟最高、成本最贵。在互联网已被 SFU 替代。
行业产品对比：Zoom、Google Meet、飞书
Zoom 以视频会议体验著称。它采用混合架构：一对一用 P2P，多人切换到 SFU；支持端到端加密；码率自适应能力强。
Google Meet 是浏览器原生 WebRTC，无需安装。默认用 SFU 架构；支持录制、转录、背景模糊等云端处理；与 Google Workspace 深度集成。
飞书 是国内互联网企业首选，支持音视频会议、共享屏幕、实时文档协作。底层也是 SFU 加各种优化。
这些产品的共同点：都投入巨资在媒体处理、网络优化、全球 CDN 部署上。
自建 SFU：Mediasoup 与 Janus
Mediasoup 是一个现代、高性能的 SFU 框架，用 Node.js + C++ 混合开发。开发者用 JavaScript 编写业务逻辑，底层用 C++ 处理数据路径。优点是代码简洁、易于扩展、生产级稳定性。社区活跃，有很多商用案例。
Janus 是一个更老的、插件化的媒体网关。核心是 C 编写的实时通信引擎，通过插件扩展功能。优点是足够灵活、可以做很多高级功能、运维工具齐全。缺点是配置复杂、学习陡峭。
选型：新项目倾向 Mediasoup；老项目或需要极高定制化选 Janus。两者都需要信令服务器来协调信令、认证、房间管理。
商用云 RTC：声网、即构、腾讯云 TRTC
声网 Agora 是全球 WebRTC 云平台的先驱。提供 SDK、全球节点部署、弱网优化。优势是全球覆盖、体验调优成熟。
即构 ZEGOCLOUD 是国内创业公司，也提供全球 RTC 服务。与声网差不多的定位，但在中国和东南亚的成本更低。
腾讯云 TRTC 是国内云厂商的选择。优势是与腾讯生态集成、国内节点充足、套餐搭配灵活。
一般的选型逻辑：全球用户 → 声网；中国用户 → 腾讯云或即构；定制化需求 → 自建 Mediasoup。
端到端加密与安全考虑
WebRTC 媒体默认用 DTLS-SRTP（DatagramTLS + Secure Real-time Transport Protocol）加密。这意味着即使信令服务器被破译，媒体内容也保持加密。
但"端到端"也有含义边界：在 SFU 架构中，虽然媒体加密，但 SFU 服务器能看到 RTCP 反馈、可能推断出用户活动模式。
此外，WebRTC 有个安全特性需注意：浏览器发起 WebRTC 连接前，必须是 HTTPS 或 localhost。这防止了中间人攻击。
移动端集成与优化
iOS 和 Android 都完整支持 WebRTC。但移动环境更恶劣：带宽波动、丢包率高、CPU/电池受限。商用 SDK 都做了深度优化：
自适应码率（ABR）是关键。GOOG 拥塞控制算法会实时监测网络状态，动态调整编码比特率。当检测到丢包时，立即降码率；网络恢复则慢慢提。
硬件编码也很重要。iOS 有 H264/H265 硬编、Android 有 H264/VP8/VP9。用硬编代替软编，CPU 占用从 30-50% 降到 5-10%。
屏幕共享在移动端也支持，但需要系统级权限。
常见问题
WebRTC 有什么安全风险吗？
WebRTC 支持 DTLS-SRTP 端到端加密，通信内容点对点直连。主要风险是 IP 泄露（WebRTC leak）—— 即使用户开了 VPN，WebRTC 仍可能泄露真实 IP。现代浏览器可通过 mDNS 候选地址隐藏 IP，但跨浏览器兼容性不一致。建议：关键应用用 TURN 中继隐藏 IP；或用 rtcConfiguration 限制候选地址类型。
WebRTC 在移动端表现如何？
iOS/Android WebRTC 支持完整。但移动网络中，带宽波动大、丢包率高，需要做自适应码率（ABR）。绝大多数商用 SDK（声网、即构、腾讯云 TRTC）都内置了针对移动网络的优化：主动降分辨率、启用 VP9/H265 硬件编码、网络拥塞检测与反馈。如果用原生 WebRTC，建议借鉴 libwebrtc 的拥塞控制算法（GCC）。
自建 SFU 用 Mediasoup 还是 Janus？
Mediasoup（Node.js，生产级，视频质量强）适合新项目、有研发实力的团队。Janus（C，灵活插件化，学习曲线陡）适合定制化需求多的场景。两者都需要运维（信令服务器、数据库、监控告警）。实际选型还要考虑：成本（服务器数量、带宽）、延迟要求、用户规模。中小企业一般直接用云厂商 RTC 更划算。
如何降低 WebRTC 延迟？
P2P 直连延迟最低（通常 50-200ms），因为无需经过服务器。但穿透失败会回退到 TURN，延迟陡增。SFU 延迟一般 200-400ms，因为多路媒体合流。MCU 由于需要重新编码所有流，延迟可能 500ms+。降低延迟的关键：1) 优先 P2P；2) 选择靠近用户的 TURN 服务器；3) 调整编码器参数（帧率、关键帧间隔）；4) 减少信令往返（预连接）。
WebRTC 可以做一对一视频通话吗？
完全可以，这是 WebRTC 最常见的应用。一对一场景不需要服务端媒体处理，只需要一个信令服务器（传递 SDP offer/answer 和 ICE 候选地址）。一旦连接建立，数据直接在两个浏览器间 P2P 传输。延迟最低、成本最省。Zoom、Google Meet、飞书等都支持点对点一对一模式。