1. WebRTC 概述：起源、场景与架构

WebRTC 这玩意儿，说白了就是让浏览器能直接视频通话、屏幕共享的一套标准。我最早接触它是在 2013 年，那时候 Chrome 和 Firefox 刚支持，坑多得能养鱼。但今天回头看，它已经成了实时通信领域的事实标准。

1.1 起源与发展

WebRTC 的故事要从 2010 年说起。Google 收购了 Global IP Solutions（GIPS），这家公司手里握着当时最牛的语音引擎和视频编解码技术。Google 做了个大胆的决定——把核心技术开源，并推动 W3C 和 IETF 标准化。

我记得 2011 年 W3C 第一次发布 WebRTC 草案时，业内很多人觉得「浏览器里做实时音视频？不靠谱」。但 Google 硬是拉着 Mozilla、Opera 一起搞，到 2014 年，Chrome 和 Firefox 已经能互打电话了。

为什么会拖这么久？因为标准化涉及的东西太多了：媒体协商、NAT 穿透、加密传输、编解码器选择……每个环节都要多方博弈。我参与过一个项目，光 SDP 协商的兼容性问题就修了三个月。

1.2 核心应用场景

你想想看，现在哪些场景离不开 WebRTC？

• 视频会议 — Zoom、Google Meet、腾讯会议，底层全是 WebRTC 或它的变体
• 在线教育 — 师生互动、屏幕共享、白板协作，延迟必须控制在 200ms 以内
• 远程医疗 — 对音视频质量要求极高，丢包率超过 1% 就可能误诊
• 直播连麦 — 主播和观众实时互动，需要混流和转发的支持
• IoT 设备 — 摄像头、门铃、机器人，通过 WebRTC 实现低延迟监控

我在做在线教育项目时踩过一个坑：学生端网络差，视频卡成 PPT，但 WebRTC 默认的拥塞控制算法（GCC）对弱网场景优化不够。后来我们手动调整了码率阈值和 NACK 重传策略，才勉强能用。

1.3 浏览器支持情况

截至 2025 年，主流浏览器的支持情况已经很稳定了。我整理了一张表，方便你对照：

浏览器	支持版本	核心 API	备注
Chrome	28+	getUserMedia, RTCPeerConnection, RTCDataChannel	最早支持，生态最成熟
Firefox	22+	同上	与 Chrome 互操作性最好
Safari	11+	同上	早期有 H264 偏好问题
Edge	12+	同上	Chromium 内核后兼容性极佳

嗯，这里要注意：Safari 在 14 版本之前对 VP8/VP9 的支持很糟糕，只认 H264。如果你做跨浏览器应用，最好在 SDP 协商时同时提供 H264 和 VP8，让浏览器自己选。

1.4 整体架构概览

WebRTC 的架构其实不复杂，但层叠的东西很多。我习惯把它分成三层来看：

• 应用层 — 你写的 JavaScript 代码，调用 getUserMedia、RTCPeerConnection 等 API
• 会话层 — SDP 协商、ICE 连接管理、DTLS 加密握手
• 传输层 — SRTP/SCTP 数据通道、NACK/FEC 丢包恢复、JitterBuffer 抖动缓冲

下面这张图是我自己画的架构图，把核心模块和它们的关系串起来了：

这张图里我特别想强调传输层的 SRTP。很多人以为 WebRTC 的加密是「可选的」，其实从 2015 年起，所有浏览器都强制要求 DTLS+SRTP 加密。我曾经遇到一个客户，非要在内网关掉加密来降低延迟，结果 Chrome 直接拒绝连接。

1.5 核心模块速览

最后快速过一遍 WebRTC 的核心模块，后面章节会逐个深入：

模块	职责	我踩过的坑
getUserMedia	采集摄像头/麦克风/屏幕	移动端权限弹窗导致采集失败
RTCPeerConnection	管理端到端连接	ICE 候选地址收集超时
RTCDataChannel	传输非媒体数据	SCTP 缓冲区满导致丢消息
MediaStream	音视频轨道管理	多轨道同步时时间戳错乱
Stats API	获取连接统计信息	Chrome 和 Safari 的统计字段名不一致

好了，第一章就到这里。WebRTC 的起源、场景、浏览器支持和整体架构，你应该有个大概印象了。后面我们会从 SDP 协商开始，一步步拆解多媒体流封装的每个细节。