一、WebRTC 初探：从一次真实需求说起
我记得那是 2018 年，我接手了一个在线教育项目。客户要求实现「浏览器直接视频通话，不能装插件」。当时市面上主流的方案是 Flash 或者 Silverlight，但这两者都快被淘汰了。我翻遍了技术文档，最终找到了 WebRTC。
说实话，第一次看到 WebRTC 的 API 时，我有点懵。它不像传统的 Socket 编程那样直观。但当我真正跑通第一个 P2P 视频通话时，那种感觉——嗯，就像打通了任督二脉。
1.1 什么是 WebRTC？
WebRTC，全称 Web Real-Time Communication。说白了，就是让浏览器之间能直接传音视频和数据，不需要中间服务器转发。
你想想看，传统的网页通信是什么样？客户端发请求给服务器，服务器再转发给另一个客户端。WebRTC 不一样，它让两个浏览器直接建立连接，数据不经过服务器中转。
核心要点：WebRTC 是一个开源项目，由 Google 发起，现在由 W3C 和 IETF 共同标准化。它提供了三个核心 API：
- MediaStream（getUserMedia）—— 获取摄像头、麦克风、屏幕共享
- RTCPeerConnection —— 建立点对点连接，传输音视频
- RTCDataChannel —— 传输任意数据（文本、文件、二进制）
我在项目中遇到过不少开发者，以为 WebRTC 只能做视频通话。其实它的数据通道能力被严重低估了。后面我们会专门讲数据通道，这里先留个悬念。
1.2 为什么需要 WebRTC？
这个问题我问过自己很多次。为什么不用现成的 Socket 或者 HTTP 轮询？
原因很简单：延迟。
传统的 HTTP 请求，从建立连接到传输数据，再到服务器响应，延迟通常在 100ms 以上。如果是跨洋通信，延迟可能到 300-500ms。对于视频通话来说，超过 200ms 的延迟就会让人感觉「卡顿」和「不自然」。
WebRTC 走的是 UDP 协议，延迟可以控制在 50ms 以内。而且它内置了丢包重传、抖动缓冲、回声消除等机制——这些如果让你自己实现，没个半年搞不定。
我的经验：曾经有个项目需要做远程医疗，要求端到端延迟低于 100ms。用 WebRTC 轻松达标。如果用传统的 RTMP 或者 HLS，延迟至少 3-5 秒，根本没法用。
另外，WebRTC 是免费的。不需要购买商业授权，不需要部署昂贵的流媒体服务器。你只需要一个信令服务器（用于交换连接信息），剩下的都交给浏览器。
1.3 WebRTC 的核心能力
WebRTC 的能力可以概括为三个维度：
| 能力 | 说明 | 典型应用 |
|---|---|---|
| 音视频采集 | 通过 getUserMedia 获取摄像头、麦克风、屏幕 | 视频通话、直播、屏幕共享 |
| 音视频传输 | 通过 RTCPeerConnection 实现 P2P 传输 | 一对一/多方视频会议 |
| 数据通道 | 通过 RTCDataChannel 传输任意数据 | 文件传输、游戏、IoT 控制 |
这里我要特别强调一下数据通道。很多人以为 WebRTC 只能传音视频，其实数据通道可以传任何东西——文本、JSON、二进制文件、甚至实时游戏的状态同步。
我做过一个项目，用数据通道传输大文件（几百 MB），速度比 HTTP 快了好几倍。为什么？因为数据通道走的是 UDP，没有 TCP 的慢启动和拥塞控制，而且可以自定义传输策略。
注意：数据通道默认是「不可靠」模式（类似 UDP），如果你需要保证数据不丢失，需要开启「可靠」模式（类似 TCP）。但可靠模式会牺牲一些速度。具体怎么选，看你的业务场景。
1.4 浏览器兼容性概览
说到兼容性，我踩过不少坑。早期 WebRTC 的 API 前缀五花八门：Chrome 用 webkitRTCPeerConnection，Firefox 用 mozRTCPeerConnection，Safari 直到 2017 年才支持。
现在情况好多了。主流浏览器的兼容性如下：
| 浏览器 | 支持版本 | 备注 |
|---|---|---|
| Chrome | 28+ | 全面支持，包括数据通道 |
| Firefox | 22+ | 全面支持 |
| Safari | 11+ | 支持音视频，数据通道需注意 |
| Edge | 79+（Chromium 版） | 全面支持 |
| iOS Safari | 11+ | 部分 API 有差异 |
我曾经在 Safari 上遇到过数据通道无法建立的问题。查了半天，发现是 Safari 对 RTCDataChannel 的 negotiated 属性处理方式不同。嗯，这种坑后面我们会专门讲。
避坑指南：如果你需要兼容旧浏览器，建议使用 adapter.js 这个 polyfill 库。它能自动处理不同浏览器的 API 差异。但注意，它只解决 API 命名差异，不解决功能差异。
1.5 WebRTC 的整体架构
为了让你更直观地理解 WebRTC 的工作流程，我画了一张架构图：
这张图展示了 WebRTC 的核心流程：两个浏览器通过信令服务器交换连接信息（SDP 和 ICE 候选），然后直接建立 P2P 连接。音视频和数据通道都走这条直连通道。
信令服务器只负责「牵线搭桥」，不负责数据传输。这也是 WebRTC 能大幅降低服务器成本的原因。
1.6 本章小结
WebRTC 不是银弹，但它解决了一个核心问题：浏览器之间如何实时通信。
它的三大能力——音视频采集、P2P 传输、数据通道——覆盖了绝大多数实时通信场景。兼容性方面，主流浏览器已经全面支持，但 Safari 和移动端还有一些坑需要留意。
我个人建议，如果你刚开始接触 WebRTC，先从数据通道入手。因为它不需要摄像头和麦克风，调试起来更简单。等熟悉了连接建立流程，再上手音视频。
好了，这一章就到这里。下一章我们会动手搭建第一个 WebRTC 数据通道应用。