1. WebRTC 前世今生：了解 WebRTC 的起源、标准化历程以及它在实时通信领域的核心地位
说起 WebRTC，我最早接触它是在 2013 年。那时候我刚接手一个视频客服项目，客户要求在浏览器里直接通话，不能装插件。你想想看，2013 年的浏览器能干啥？Flash 还是主流，但 Flash 在移动端已经快死了。我翻遍了各种技术方案，最后找到了 WebRTC——当时它还叫 WebRTC 1.0，Chrome 和 Firefox 刚支持没多久。
说实话，第一次跑通两个浏览器之间的视频通话时，我挺激动的。不是因为技术多难，而是因为「浏览器原生就能做实时通信」这件事本身，太颠覆了。今天我们就聊聊 WebRTC 是怎么来的，它经历了什么，以及为什么它现在这么重要。
1.1 实时通信的「史前时代」
在 WebRTC 出现之前，浏览器里做实时音视频通信，基本只有两条路：
- 插件方案：Flash、Silverlight、Java Applet、ActiveX。用户得先装插件，版本还得对得上。
- 私有协议：厂商自己搞一套信令和媒体传输协议，比如早期的 Skype、QQ 视频通话。
这两条路都有硬伤。插件方案在移动端直接废掉——iOS 不支持 Flash，Android 上 Flash 也很快被抛弃。私有协议的问题更严重：不同厂商之间没法互通，你家的视频通话打不到我家的客户端上。
核心痛点：浏览器本身没有标准的实时通信能力，所有方案都是「绕路走」。用户体验差，开发成本高，生态碎片化严重。
我记得 2011 年做一个远程医疗项目，客户要求支持 IE6、Chrome、Firefox 和 Safari。为了视频通话，我们同时维护了 Flash 版、ActiveX 版和 Java Applet 版——三个团队各写一套代码，测试用例翻了三倍。每次浏览器升级，总有一个方案会出问题。那段时间我几乎每天都在跟「插件崩溃」打交道。
1.2 WebRTC 的诞生：Google 的野心
2010 年，Google 收购了 GIPS（Global IP Solutions）。GIPS 是一家做实时音视频引擎的公司，它的技术栈覆盖了音频编解码、回声消除、抖动缓冲、网络传输等核心模块。Google 买下 GIPS 后，做了一件在当时看来很「疯狂」的事：把 GIPS 的核心技术开源，并推动它成为 W3C 和 IETF 的标准。
为什么说疯狂？因为 GIPS 的技术是 Google 花了上亿美元买来的，直接开源等于白送竞争对手。但 Google 的逻辑很清楚：
- 实时通信的市场足够大，一家公司吃不下
- 标准化的浏览器实时通信能力，能催生整个生态
- Google 在浏览器（Chrome）和移动端（Android）都有布局，生态繁荣对它更有利
2011 年 5 月，Google 正式向 W3C 提交了 WebRTC 的初始草案。同年，IETF 也成立了 RTCWEB 工作组，负责制定相关的传输协议标准。WebRTC 的标准化进程正式启动。
一个小细节：WebRTC 最初的全称是「Web Real-Time Communication」，但 W3C 的规范里一直用「WebRTC」这个缩写。我个人习惯直接叫它「WebRTC」，因为全称念起来太长了。
1.3 标准化历程：从草案到正式推荐标准
WebRTC 的标准化之路并不平坦。从 2011 年提交草案，到 2021 年 W3C 发布正式推荐标准（Recommendation），整整走了十年。这中间经历了什么？
| 时间 | 里程碑事件 | 说明 |
|---|---|---|
| 2011.05 | Google 向 W3C 提交 WebRTC 初始草案 | 基于 GIPS 引擎，Chrome 率先实现原型 |
| 2012.02 | Firefox 开始实现 WebRTC | Mozilla 与 Google 合作推动标准化 |
| 2013.01 | Chrome 和 Firefox 实现互通的视频通话 | 首次跨浏览器实时通信演示 |
| 2014.03 | WebRTC 1.0 进入候选推荐阶段 | API 基本稳定，但协议细节仍在争论 |
| 2017.09 | WebRTC 1.0 发布候选推荐标准 | 主要浏览器实现趋于一致 |
| 2021.01 | W3C 发布 WebRTC 正式推荐标准 | 历时十年，终于成为正式标准 |
为什么花了这么久？核心原因有两个：
- 协议层面的博弈：IETF 内部对媒体传输协议（特别是 DTLS-SRTP 和 ICE 的细节）有大量争论。Google 的初始实现用了很多私有扩展，其他厂商要求完全标准化。
- 浏览器厂商的利益冲突：Apple 的 Safari 一直拖到 2017 年才正式支持 WebRTC，Microsoft 的 Edge 早期用的是自家的 ORTC（Object RTC）方案，后来才转向 WebRTC。
我在 2015 年做一个在线教育项目时，就吃过这个亏。当时 Safari 不支持 WebRTC，我们不得不给 Mac 用户单独准备一套 Flash 降级方案。直到 2017 年 Safari 支持后，才彻底扔掉 Flash 代码。
1.4 WebRTC 的核心架构
WebRTC 不是单一的技术，而是一整套协议和 API 的集合。它的核心架构可以概括为三层：
这张图我画了很多次，每次给团队新人讲 WebRTC 时都会先过一遍。你注意看：
- 应用层：开发者直接调用的 JavaScript API。getUserMedia 获取音视频流，RTCPeerConnection 建立连接，RTCDataChannel 传数据。信令部分 WebRTC 不管，你得自己实现。
- 引擎层：这是 WebRTC 的核心价值。音频引擎处理编解码和回声消除，视频引擎处理编解码和抖动缓冲，传输引擎处理加密和 NAT 穿透。这些在 GIPS 时代就已经很成熟了。
- 网络层：底层传输。WebRTC 优先用 UDP，因为实时性要求高；如果 UDP 被防火墙封了，就降级到 TCP 或通过 TURN 中继。
注意：WebRTC 的「引擎层」是浏览器内置的，开发者无法直接控制。你只能通过 API 参数间接影响引擎行为，比如设置编解码优先级、调整带宽估计策略。我曾经踩过一个坑：在弱网环境下想强制用低分辨率，结果发现 WebRTC 的带宽估计器会自动降分辨率，但降得太慢导致卡顿。后来我通过设置 RTCRtpSender.setParameters() 手动限制了最大码率，才解决问题。
1.5 WebRTC 的核心地位：为什么它不可替代？
到今天，WebRTC 已经不是「一个选项」，而是「事实标准」。你看看现在的实时通信产品：
- Google Meet、Zoom、腾讯会议：底层都用了 WebRTC 或它的变体
- Discord、Slack：语音通话基于 WebRTC
- Facebook Messenger、WhatsApp：WebRTC 是核心通话引擎
- 直播连麦、在线教育、远程医疗：几乎全部基于 WebRTC
为什么大家都选 WebRTC？说白了，三个原因：
- 免插件：浏览器原生支持，用户不用装任何东西。这一点在移动端尤其重要——你让用户装个插件才能视频通话？用户直接卸载你的 App。
- 标准统一：所有主流浏览器（Chrome、Firefox、Safari、Edge）都实现了同一套 API。写一次代码，到处运行。这在 2010 年之前根本不敢想。
- 生态成熟：WebRTC 开源十年，社区积累了大量的工具、库、最佳实践。你遇到的大部分问题，网上都能找到解决方案。
一个数据：根据 Statista 的统计，2023 年全球 WebRTC 市场规模已超过 50 亿美元，预计到 2028 年将突破 200 亿美元。这个数字背后，是无数实时通信应用在依赖 WebRTC 运转。
1.6 我的个人体会
做了这么多年实时通信，我最大的感受是：WebRTC 降低了实时通信的门槛，但没有降低它的复杂度。
什么意思？十年前你想做一个视频通话功能，得自己搞定音视频采集、编解码、网络传输、NAT 穿透、回声消除……每一项都是深坑。现在 WebRTC 帮你把引擎层封装好了，你只需要调几个 API 就能跑通一个 Demo。
但 Demo 和产品之间，隔着十万八千里。信令怎么设计？带宽怎么自适应？弱网怎么优化？多人通话的架构怎么选？这些 WebRTC 都不管，得你自己来。
嗯，这也是我为什么做这门课的原因。我希望帮你把 WebRTC 的「黑盒」打开，让你不仅会用，还能用好、用对。
一个小建议：如果你刚开始学 WebRTC，别急着写代码。先把这张架构图看懂，搞清楚每一层是干什么的。我见过太多人一上来就调 API，遇到问题完全不知道是引擎层的问题还是网络层的问题。