WebRTC 入门：是什么、能做什么、核心模块

WebRTC 让浏览器和 App 不用装插件就能实现实时音视频通话。这篇从零讲起：WebRTC 是什么、能做什么、整体架构、核心模块，以及一个最简单的例子跑起来。

大家好，我是黒漂技术佬。

做音视频的，WebRTC 绕不开。以前要做网页视频通话，得装 Flash 插件，或者用专门的客户端。现在有了 WebRTC，浏览器原生支持，几行 JS 就能开摄像头、做视频通话。

不仅是浏览器，移动端、PC 端都有 WebRTC 的实现，跨平台的实时通信基本都用它。

这篇是 WebRTC 系列的第一篇，讲基础概念、能做什么、核心模块有哪些。

一、WebRTC 是什么？

全称

Web R eal-T ime Communication，网页实时通信。

是什么

一套开放的标准和技术，让浏览器和移动应用之间可以直接进行实时音视频和数据通信，不需要中间插件或第三方软件。

谁搞的

最早是 Google 收购 GIPS 公司后开源的
现在由 W3C 和 IETF 标准化
Chrome、Firefox、Safari、Edge 全部支持

特点

免费开源：免费使用，代码开源
浏览器原生支持：不用装插件，JS API 直接用
点对点（P2P）：数据直接在两端传输，不经过服务器（打洞成功的话）
低延迟：实时通信，延迟一般几百毫秒
跨平台：Web、Android、iOS、Windows、Mac 都支持

二、WebRTC 能做什么？

1. 视频通话 / 语音通话

最常见的场景：一对一视频聊天、多人视频会议。

2. 屏幕共享

远程协作、在线教育、技术支持，共享屏幕给对方看。

3. 实时数据传输

DataChannel 可以传任意数据：

文件传输
游戏同步
白板协作
实时消息

4. 直播

低延迟直播场景，比 RTMP/HLS 延迟低很多。

5. 物联网

设备之间实时传输音视频和数据。

典型应用

视频会议：Zoom、腾讯会议、飞书会议（底层很多用了 WebRTC 技术）
在线教育：一对一辅导、小班课
社交应用：视频聊天
远程医疗：远程问诊
云游戏：低延迟传输游戏画面

三、WebRTC 整体架构

三大核心模块

复制代码

┌─────────────────────────────────────────┐
│           WebRTC 整体架构               │
│                                         │
│  ┌─────────────┐  ┌─────────────────┐  │
│  │ getUserMedia│  │   RTCPeerConn   │  │
│  │  音视频采集  │  │  连接与传输     │  │
│  └──────┬──────┘  └───────┬─────────┘  │
│         │                 │            │
│         └────────┬────────┘            │
│                  │                     │
│         ┌────────┴────────┐            │
│         │  RTCDataChannel │            │
│         │   数据通道       │            │
│         └─────────────────┘            │
│                                         │
│  底层：音视频编解码、网络传输、NAT穿透   │
└─────────────────────────────────────────┘

1. MediaStream（媒体流）

音视频数据的抽象
包含多个轨道（Track）：视频轨、音频轨
来源：摄像头、麦克风、屏幕共享、本地文件

2. RTCPeerConnection（点对点连接）

WebRTC 的核心，负责建立和管理两端的连接
处理 NAT 穿透（STUN/TURN）
处理音视频编解码
处理网络传输（SRTP）
处理带宽估计、丢包重传等

3. RTCDataChannel（数据通道）

在点对点连接上传输任意数据
支持可靠和不可靠两种模式
低延迟，适合实时数据传输

四、关键技术点

1. 音视频编解码

视频

VP8 / VP9：Google 推的，免版税，WebRTC 默认
H.264：硬件支持好，兼容性好
AV1：新一代，压缩率高，正在普及

音频

Opus：WebRTC 默认，音质好，码率范围大
G.711 / G.722：传统电话用的，兼容性好

WebRTC 会自动协商两端都支持的编解码器。

2. NAT 穿透（STUN / TURN / ICE）

大部分设备在 NAT 后面（路由器、防火墙），不能直接连接。

STUN：帮你发现自己的公网 IP 和端口
TURN：打洞失败时的中继服务器，数据转一下
ICE：整合 STUN 和 TURN，自动选最好的连通路径

后面专门一篇讲这个。

3. 信令（Signaling）

WebRTC 不管怎么交换联系方式，这部分要自己实现：

交换 SDP（媒体协商信息）
交换 ICE Candidate（网络候选地址）
控制通话的开始、结束

信令服务器可以用 WebSocket、HTTP 随便实现，WebRTC 标准不管这个。

4. 安全

媒体流用 SRTP 加密传输
数据通道用 DTLS 加密
必须 HTTPS 才能用（localhost 除外）

五、最简单的例子：打开摄像头

不用建立连接，先看看怎么获取本地摄像头：

html 复制代码

<!DOCTYPE html>
<html>
<body>
  <video id="localVideo" autoplay playsinline></video>

  <script>
    // 获取摄像头和麦克风
    async function startCamera() {
      try {
        const stream = await navigator.mediaDevices.getUserMedia({
          video: true,
          audio: true
        });
        
        // 显示到 video 标签
        const video = document.getElementById('localVideo');
        video.srcObject = stream;
        
        console.log('摄像头已打开');
      } catch (err) {
        console.error('打开摄像头失败:', err);
      }
    }
    
    startCamera();
  </script>
</body>
</html>

就这么几行，浏览器就能打开摄像头显示画面。这就是 WebRTC 的 MediaStream API。

六、一次完整的通话流程

两个浏览器建立视频通话，大致分几步：

第一步：信令服务器连通

两边都连上信令服务器，能互相发消息。

第二步：发起方创建 Offer

复制代码

A 创建 RTCPeerConnection
A 调用 createOffer() 生成 SDP
A 设置本地描述 setLocalDescription
A 通过信令把 Offer SDP 发给 B

第三步：接收方回复 Answer

复制代码

B 收到 Offer，设置远端描述 setRemoteDescription
B 创建 Answer SDP
B 设置本地描述
B 通过信令把 Answer SDP 发给 A

第四步：交换 ICE 候选

复制代码

两边各自收集 ICE Candidate（自己的网络地址）
通过信令服务器互相转发
两边尝试连接（STUN打洞、TURN中继）
找到可用的连接路径

第五步：媒体流传输

复制代码

连接建立成功
两边把音视频流通过 PeerConnection 发送
对方收到流，显示出来

简化流程图

复制代码

  A                    信令服务器                    B
  │                       │                        │
  │─── 加入房间 ──────────▶│                        │
  │                       │──── 有人加入 ──────────▶│
  │                       │                        │
  │─── Offer SDP ────────▶│                        │
  │                       │──── Offer SDP ────────▶│
  │                       │                        │── 创建Answer
  │                       │◀─── Answer SDP ────────│
  │◀── Answer SDP ────────│                        │
  │                       │                        │
  │─── ICE Candidate ────▶│                        │
  │                       │── ICE Candidate ──────▶│
  │                       │◀── ICE Candidate ──────│
  │◀── ICE Candidate ─────│                        │
  │                       │                        │
  │◀════════════ P2P 音视频数据 ═══════════════════▶│

看起来复杂，其实核心就是：交换 SDP 协商媒体、交换 ICE 建立连接、然后传数据。

七、WebRTC 的难点在哪？

1. NAT 穿透复杂

网络环境千差万别：不同路由器、不同运营商、防火墙、对称 NAT......

有些环境 STUN 打洞打不通，必须用 TURN 中继。

2. 多人通话架构复杂

一对一简单，多人就麻烦了：

Mesh：每个人连每个人，人多了上行带宽扛不住
SFU：转发服务器，每个人发一路，服务器转发给其他人
MCU：混流服务器，把多路合成一路

后面专门一篇讲多人架构。

3. 网络波动处理

实时网络不稳定，丢包、抖动、带宽变化。WebRTC 有很多机制处理：

拥塞控制（GCC、BBR）
丢包重传（NACK）
前向纠错（FEC）
自适应码率

4. 设备兼容性

不同浏览器、不同版本，API 有差异。一般用 adapter.js 抹平差异。

5. 移动端适配

Android/iOS 上的 WebRTC，后台、锁屏、权限处理都有坑。

八、本系列内容安排

这个系列 10 篇，从基础到实战：

WebRTC 入门：是什么、核心模块
音视频采集：getUserMedia 与设备管理
媒体流与轨道：MediaStream / MediaTrack
RTCPeerConnection 连接建立：SDP 与 ICE
NAT 穿透详解：STUN / TURN / ICE
音视频编解码：VP8 / VP9 / H.264 / Opus
数据通道：DataChannel 可靠与不可靠传输
信令服务器设计与实现
多人会议架构：Mesh / SFU / MCU 对比
实战：一对一视频通话完整实现

九、本篇小结

WebRTC = 网页实时通信，浏览器原生支持，开源免费
三大核心：MediaStream（采集）、RTCPeerConnection（连接传输）、DataChannel（数据）
关键技术：音视频编解码、NAT 穿透（STUN/TURN/ICE）、信令、加密
通话流程：信令交换 SDP → 交换 ICE → 建立连接 → 传输媒体
难点：NAT 穿透、多人架构、网络波动、兼容性
最简单的应用：getUserMedia 几行代码打开摄像头

下一篇讲音视频采集：getUserMedia 详细用法、设备管理、参数控制、屏幕共享。

我是黒漂技术佬。