跳到主要内容

创建日期：2026-09-06 ｜ 最近更新：2026-09-06 内容基准：W3C WebRTC 1.0 规范（2021 年成为正式 Recommendation）、IETF rtcweb 工作组系列 RFC（RFC 8825 起，含 2024 年更新至 RFC 9429 的 JSEP）、MDN WebRTC 文档。文末附引用。

WebRTC 101（第 0 篇 · 入门）：它解决什么问题，全景怎么画

WebRTC（Web Real-Time Communication） 不是"一个库"，而是一整套让浏览器/App 之间做实时音视频与任意数据交换的标准协议栈 + 浏览器 API。它由 Google 2010 年收购 GIPS 后开源推动，标准化上两路并行：

  • **IETF（rtcweb 工作组）**定"线缆上跑什么协议"：媒体怎么传、怎么加密、怎么穿透 NAT；
  • **W3C（WebRTC 工作组）**定"浏览器里怎么调用"：getUserMedia / RTCPeerConnection / RTCDataChannel / getStats。

两边的分界一句话就能记住：API 归 W3C，协议归 IETF，中间用 JSEP（RFC 9429）把"会话描述协商"衔接起来。

1. 它到底解决什么问题​

把 WebRTC 放进更大的背景里看：你写过的 HTTP/WebSocket 都是"经过服务器中转"的客户端-服务器模型，两端互不知道对方。而视频通话 / 屏幕共享 / 低延迟协作这类需求想要的是"端到端、尽量点对点、延迟几百毫秒以内"。要实现它，必须跨过一堆 HTTP 时代根本不用操心的坎：

难题具体表现
采集与处理摄像头/麦克风怎么拿、回声消除、降噪、自动增益
编码压缩每秒几十 MB 的原始音视频怎么压到能在网络上跑（Opus / VP8 / VP9 / H.264 / AV1）
"找到对方"两边都在路由器后面（NAT），没有公网地址，怎么互相找到 → ICE / STUN / TURN
网络抖动丢包实时传输不能像文件下载一样重传一整块，要抖动缓冲、丢包隐藏、码率自适应
安全实时内容默认必须加密 → DTLS / SRTP
没有"标准信令"API 不管"怎么约好通话"，信令由开发者自己搭（见第 2 篇）

WebRTC 的价值就是把上面这些用一套浏览器原生 API + 强制协议标准化掉——开发者不用自己实现音视频编解码、拥塞控制或 P2P 穿透。

2. 四个 API 组件（先记住这四块）​

API负责什么通俗说法
getUserMedia采集音视频轨道"拿设备"
RTCPeerConnection点对点连接：信号处理、编解码协商、安全、传输、带宽管理"接通并维护一条加密的实时管道"
RTCDataChannel在已建立的点对点连接上跑任意数据（底层 SCTP over DTLS）"P2P 的 WebSocket"
getStats汇报会话统计"体检表"

注意两个反直觉点，理解了就懂了一半 WebRTC：

  1. 信令不在 API 里。RTCPeerConnection 不管"对方在哪、怎么邀约"，只负责"给我一份 SDP、我给你一份"，交换描述的动作（WebSocket/HTTP/任何消息通道）由应用自己做。
  2. getUserMedia 不等于通话。采集只是拿了本地轨道，真正连起来的是 RTCPeerConnection——第 1、2 篇会把这两件事拆开讲。

3. 全景分层：我的心智模型​

我习惯把 WebRTC 画成三层，读文档时先想"这是哪一层的事"：

┌─ 应用层 ─────────────────────────────────────────────┐
│  你的信令（WebSocket / HTTP / 房间 / 鉴权）           │
│  getUserMedia · RTCPeerConnection · RTCDataChannel   │
├─ 连接层（"把两台机器连起来并加密"）────────────────────┤
│  信令描述协商：SDP / Offer-Answer（JSEP, RFC 9429）   │
│  连接建立与打洞：ICE（RFC 8445）/ STUN / TURN         │
│  密钥与加密：DTLS → SRTP（媒体）/ SCTP（数据）         │
├─ 媒体与数据层（"线上跑什么格式"）──────────────────────┤
│  音频：Opus 等 · 视频：VP8/VP9/H.264/AV1              │
│  RTP/RTCP 传输 · 抖动缓冲 · 丢包恢复 · 码率自适应      │
└──────────────────────────────────────────────────────┘

这套结构正好是本系列后面每一篇的目录：第 1 篇在应用层（采集），第 2、3 篇在连接层（SDP、ICE），第 4、5 篇在媒体/数据层（SRTP、SCTP/DataChannel），第 6 篇回到应用层谈生产与选型。

4. 一次通话的生命周期（先看全貌，细节后补）​

  1. 采集：getUserMedia 拿到本地音视频轨道；
  2. 协商：双方通过你自己的信令通道交换 SDP（offer → answer），里面带"我想传什么格式、有哪些候选地址"；
  3. 打洞：双方跑 ICE——收集候选（本机/STUN 反射/TURN 中继），互相做连通性探测，挑出最快能通的那条路径；
  4. 加密握手：在选中的路径上做 DTLS 握手，派生出加密媒体（SRTP）与加密数据（SCTP）的密钥；
  5. 流动：音视频以 SRTP 包流动，数据以 SCTP 跑 RTCDataChannel；期间实时丢包恢复、码率自适应；
  6. 体检：getStats 与浏览器内部工具（Chrome 的 chrome://webrtc-internals）随时可查。

5. 本系列路线图（101：按学习路径推进）​

篇主题状态
0入门：全景与心智模型（本文）✅
1采集与三件套：getUserMedia、轨道、约束与坑✅
2建立连接：为什么要有信令、Offer/Answer 与 SDP 精读✅
3NAT 穿透：ICE / STUN / TURN 是怎么"打洞"的✅
4媒体平面：DTLS→SRTP、RTP/RTCP、编解码与自适应✅
5DataChannel：SCTP over DTLS，何时用它替代 WebSocket✅
6生产与选型：Mesh/SFU、TURN 自建、信令与监控✅
7+实操坑位：逐条记录本地 Demo 踩坑 / 弱网 / 调试待写

系列主线：能讲原理的讲原理，能画图的画图，代码只给到"能验证结论"的程度（本栏目定位是探索笔记，不是照抄 API 手册）。

6. 开写之前必须知道的一条红线（安全）​

WebRTC 会向网页暴露本机真实内网/公网地址（ICE candidate 里带的），即使你做了 VPN/代理。这不是可修的 bug，而是它工作的方式——做隐私敏感应用（尤其国内环境）时要对"被探测到本地 IP"这件事有预期，浏览器与 uBlock Origin 类工具有缓解手段。更系统的安全话题放到第 6 篇。

参考与来源​