1. 课程导入
聊 WebRTC 之前，我想先问你一个问题：在 2011 年之前，浏览器之间怎么实现实时音视频通话？
答案是——基本不可能。那时候你要做视频通话，要么装 Flash，要么装插件，要么用 Java Applet。说白了，浏览器本身没有这个能力。我 2010 年刚入行做 VoIP 时，为了在网页上跑一个视频通话 demo，折腾了整整两周，最后还是靠 ActiveX 控件才勉强跑通。那体验，嗯，谁用谁知道。
1.1 起源：Google 的野心与 GIPS 收购
故事要从 2010 年说起。Google 当时想做 Google Talk 的网页版，但发现市面上没有合适的浏览器实时通信方案。于是他们干了一件事——收购了一家叫 GIPS（Global IP Solutions）的公司。
GIPS 是做什么的？简单说，他们是做 VoIP 引擎的。音频编解码、回声消除、丢包补偿、抖动缓冲……这些底层技术他们都有。Google 花了 6820 万美元买下 GIPS，然后做了一件在当时看来很疯狂的事：把 GIPS 的核心代码开源，并捐给了 W3C 和 IETF 做标准化。
关键节点：2011 年 5 月，Google 正式开源 WebRTC 项目。同年，W3C 成立 WebRTC 工作组，IETF 成立 RTCWEB 工作组。浏览器实时通信的序幕就此拉开。
为什么 Google 要这么做？我个人理解，Google 的战略从来不是卖技术，而是推标准。浏览器有了实时通信能力，Google Meet、Google Voice 这些产品才能跑起来。你想想看，如果 WebRTC 是闭源的，Chrome 一家独大，其他浏览器厂商会跟进吗？不会的。
1.2 标准化历程：W3C + IETF 双线推进
WebRTC 的标准化其实分两条线：
- W3C（Web 端）：定义 JavaScript API，比如
getUserMedia、RTCPeerConnection、RTCDataChannel。这些是开发者直接调用的接口。 - IETF（协议层）：定义底层传输协议，比如 ICE、STUN、TURN、DTLS-SRTP、SDP 协商等。这些是浏览器底层实现的，开发者一般看不到。
我刚开始学 WebRTC 时，总觉得 W3C 的 API 文档就够了。后来踩了坑才发现——不懂 IETF 的协议细节，你连连接失败的原因都查不出来。比如 ICE 协商失败，你光看浏览器 console 报错是没用的，得抓包看 STUN 消息才知道是 NAT 穿透失败还是 Candidate 优先级配错了。
| 标准化组织 | 负责范围 | 关键规范 | 状态 |
|---|---|---|---|
| W3C | JavaScript API | WebRTC 1.0 (CR) | 2021 年定稿 |
| IETF | 传输协议 | RFC 8825~8837 | 2021 年发布 |
| IETF | ICE / STUN / TURN | RFC 8445 / 8489 / 8656 | 已稳定 |
| IETF | 数据通道 | RFC 8831 / 8832 | 已稳定 |
标准化过程其实挺曲折的。我记得 2015 年的时候，Chrome 和 Firefox 的 WebRTC 实现还不兼容，同样的 SDP 协商在 Chrome 上能通，在 Firefox 上就报错。后来 W3C 和 IETF 花了好几年才把规范对齐。到 2021 年，WebRTC 1.0 正式成为 W3C 推荐标准，IETF 也发布了 RFC 8825~8837 系列规范。嗯，这条路走了整整十年。
1.3 核心应用场景
WebRTC 能做什么？我列几个最常见的场景：
- 视频会议：Zoom、Google Meet、腾讯会议。这是 WebRTC 最经典的应用。点对点传输，低延迟，支持多人通话。
- 直播互动：连麦、弹幕、实时评论。WebRTC 的延迟可以做到 200ms 以内，比 HLS 的 5~10 秒强太多。
- 远程桌面 / 屏幕共享：通过
getDisplayMedia捕获屏幕，再用RTCPeerConnection传输。我在项目中做过一个远程协助工具，就是基于这个思路。 - 实时数据传输：用
RTCDataChannel传文件、游戏状态、IoT 传感器数据。不经过服务器中转，延迟极低。 - P2P 网络加速：利用 WebRTC 的 ICE 穿透能力，做 P2P CDN 或区块链节点通信。
避坑指南：我曾经在一个直播项目中，直接用 WebRTC 做万人直播。结果发现浏览器对 RTCPeerConnection 的数量有限制——Chrome 默认最多 500 个连接。后来改用 SFU（Selective Forwarding Unit）架构，才解决了这个问题。所以，WebRTC 适合小规模 P2P，大规模场景必须用服务器中转。
1.4 浏览器支持现状
截至 2025 年，主流浏览器对 WebRTC 的支持已经非常成熟了。我整理了一张表：
| 浏览器 | WebRTC 支持 | 备注 |
|---|---|---|
| Chrome / Edge | ✅ 完整支持 | 基于 Chromium，更新最快 |
| Firefox | ✅ 完整支持 | 与 Chrome 基本对齐 |
| Safari | ✅ 支持（部分延迟） | iOS 14+ 开始稳定 |
| Opera | ✅ 支持 | 基于 Chromium |
| IE / 旧版 Edge | ❌ 不支持 | 已淘汰，无需考虑 |
不过要注意，不同浏览器的实现细节还是有差异的。比如 Safari 对 RTCRtpSender.getParameters() 的支持就比 Chrome 晚了一年。我去年做一个跨浏览器适配项目时，发现 Safari 的 setLocalDescription 在 ICE 重启时行为跟 Chrome 不一样，查了两天文档才找到 workaround。
警告：不要完全依赖浏览器默认行为。WebRTC 规范里有很多“建议”而非“必须”的条款，不同浏览器实现可能不同。比如 iceCandidatePoolSize 的默认值，Chrome 是 0，Firefox 是 10。这种差异在复杂场景下会坑到你。
1.5 WebRTC 整体架构
说了这么多，我们来看看 WebRTC 的整体架构。下面这张图是我自己画的，涵盖了从 API 到传输层的核心模块：
从这张图你能看到，WebRTC 不是单一的技术，而是一整套协议栈。从上到下依次是：
- 应用层：你写的业务代码，比如视频会议 UI、直播推流逻辑。
- Web API 层：浏览器暴露给 JavaScript 的接口，比如
getUserMedia获取摄像头。 - WebRTC 引擎：浏览器内置的 C++ 实现，处理音频编解码、视频渲染、网络传输等。
- 传输层：ICE 打洞、STUN/TURN 中继、DTLS-SRTP 加密、SDP 协商。
- 网络层：底层 UDP/TCP 传输，支持 IPv4 和 IPv6。
我个人觉得，理解这个分层结构很重要。很多初学者遇到问题就盯着 JavaScript 代码看，其实问题可能出在传输层或者网络层。比如连接不通，你先查 ICE 状态，再查 STUN 响应，最后才看业务逻辑——这个排查顺序能省你很多时间。
1.6 小结
WebRTC 从 2011 年开源到现在，已经走过了十几年。它让浏览器原生支持实时通信，彻底改变了视频会议、直播互动、远程协作等行业。标准化方面，W3C 和 IETF 双线推进，2021 年终于全部定稿。浏览器支持方面，Chrome、Firefox、Safari 都已经稳定支持，但细节差异仍然存在。