1. WebRTC 概述：起源、技术栈与应用场景
WebRTC 这玩意儿，说白了就是让浏览器能直接视频通话。不用装插件，不用额外客户端。我第一次接触它是在 2013 年，当时还在做传统的 Flash 直播方案。说实话，那时候觉得这技术挺糙的，延迟高、兼容差。但后来我发现，我错了。
1.1 WebRTC 的起源与发展
2011 年，Google 收购了 Global IP Solutions（GIPS），一家做 VoIP 引擎的公司。然后 Google 把这套技术开源了，就是后来的 WebRTC。2013 年，W3C 和 IETF 开始标准化。我记得当时 Chrome 和 Firefox 还在打架，各自实现不一样，搞得我们开发者很头疼。
发展到现在，WebRTC 已经是 W3C 推荐标准了。所有主流浏览器都支持，包括 Safari。嗯，这里要注意，Safari 的支持来得比较晚，大概 2017 年才跟上。
关键里程碑：
- 2011 - Google 收购 GIPS，开源 WebRTC
- 2013 - W3C 发布首个工作草案
- 2017 - Safari 正式支持 WebRTC
- 2021 - WebRTC 成为 W3C 推荐标准
1.2 核心技术栈
WebRTC 不是单一技术，是一整套协议栈。我习惯把它分成三层：
你想想看，浏览器要完成实时通信，得做多少事？采集摄像头、编码、打包、穿越 NAT、解码、渲染。每一层都有坑。我曾经在一个项目中，ICE 连接死活建立不起来，查了两天才发现是 STUN 服务器配置错了。
1.3 核心 API 详解
WebRTC 暴露给 JavaScript 的 API 其实就三个：
| API | 作用 | 我踩过的坑 |
|---|---|---|
getUserMedia |
采集音视频 | 移动端必须加 {audio: true, video: {facingMode: 'user'}} |
RTCPeerConnection |
建立 P2P 连接 | ICE 候选者收集顺序影响连接速度 |
RTCDataChannel |
传输任意数据 | SCTP 缓冲区满会导致丢消息 |
个人习惯：我每次写 getUserMedia 都会加 try-catch。因为用户可能拒绝授权，或者设备不支持。别问我怎么知道的。
1.4 应用场景分析
WebRTC 能做的事，比大多数人想象的多。不只是视频通话。
- 视频会议 - 最经典场景。Zoom、Google Meet 都在用。但要注意，多人会议需要 SFU 或 MCU 架构。
- 远程医疗 - 对延迟要求极高。我曾经帮一家医院做过远程超声方案，延迟必须控制在 200ms 以内。
- 直播连麦 - 主播和观众互动。这里有个坑：推流用 RTMP，连麦用 WebRTC，需要做协议转换。
- 屏幕共享 - 用
getDisplayMedia实现。注意帧率设置，我一般设 15fps，太高了 CPU 扛不住。 - IoT 实时监控 - 摄像头数据直接推送到浏览器。省去了转码服务器。
1.5 与传统流媒体方案对比
很多人问我：WebRTC 和 RTMP、HLS 比，到底强在哪？我直接给你看对比：
| 特性 | WebRTC | RTMP | HLS |
|---|---|---|---|
| 延迟 | < 500ms | 1-3s | 5-30s |
| 浏览器原生支持 | 是 | 需插件 | 是 |
| P2P 能力 | 原生支持 | 不支持 | 不支持 |
| 编解码 | VP8/VP9/H.264 | H.264 | H.264 |
| 抗丢包 | 强（FEC+NACK） | 弱 | 弱 |
| 部署复杂度 | 高 | 中 | 低 |
注意：WebRTC 延迟低，但部署复杂。你需要 STUN/TURN 服务器，还要处理信令。如果只是做直播，HLS 可能更省事。选方案要看场景，别盲目追新。
1.6 为什么选择 WebRTC
我做了十年流媒体，从 RTMP 到 HLS 到 WebRTC。说实话，WebRTC 是最难搞的，但也是最有价值的。原因有三：
- 延迟是硬需求 - 视频通话延迟超过 1 秒，用户就受不了。WebRTC 能做到 200ms 以内。
- 自适应码率 - 网络波动时自动降码率。这个功能在移动端特别重要。我见过太多方案在网络差的时候直接卡死。
- 安全 - 强制 DTLS 加密。不像 RTMP 那样裸奔。现在浏览器都要求安全上下文才能用 WebRTC。
嗯，最后说一句。WebRTC 不是银弹。它解决的是实时互动问题，不是分发问题。如果你要做万人直播，还是得靠 CDN。但如果你要做的是两个人或者小范围的实时互动，WebRTC 是目前最好的选择。