WebRTC 是什么？能做什么？（概览篇）本文是 WebRTC 系列专栏的第一篇，旨在帮助读者建立对 WebRTC 的整体认知，了解其发展历程、核心能力、主要组件以及优势与局限。
目录WebRTC 的发展历史WebRTC 能解决什么问题WebRTC 核心组件WebRTC 的优势与局限总结1. WebRTC 的发展历史1.1 起源：从 GIPS 到 GoogleWebRTC（Web Real-Time Communication）的故事要从一家名为 Global IP Solutions（GIPS） 的瑞典公司说起。GIPS 成立于 1999 年，专注于开发高质量的音视频编解码器和实时通信技术。他们的技术被广泛应用于 Skype、Yahoo Messenger、QQ 等知名即时通讯软件中。
2010 年 5 月，Google 以 6820 万美元收购了 GIPS。这次收购为 WebRTC 的诞生奠定了技术基础。
1.2 WebRTC 的诞生与标准化时间里程碑事件2011 年 5 月Google 宣布开源 WebRTC 项目，将 GIPS 的核心技术贡献给开源社区2011 年 10 月W3C 发布 WebRTC 1.0 的第一个工作草案2012 年 1 月Chrome 稳定版开始支持 WebRTC2013 年 2 月Firefox 和 Chrome 之间首次实现跨浏览器 WebRTC 通话2017 年 11 月Apple 在 Safari 11 中加入 WebRTC 支持2021 年 1 月W3C 和 IETF 正式将 WebRTC 1.0 定为推荐标准（Recommendation）1.3 标准化组织WebRTC 的标准化由两个组织共同推进：
W3C（World Wide Web Consortium）：负责定义 JavaScript API 规范IETF（Internet Engineering Task Force）：负责定义底层协议规范（如 ICE、DTLS-SRTP 等）1.4 版本演进WebRTC 1.0：2021 年正式成为 W3C 推荐标准，定义了核心 APIWebRTC NV（Next Version）：正在开发中，包含 Insertable Streams、WebTransport 集成等新特性2. WebRTC 能解决什么问题WebRTC 的核心价值在于：让浏览器具备原生的实时音视频通信能力，无需安装任何插件。
2.1 典型应用场景实时音视频通话这是 WebRTC 最核心的应用场景。
用户 A 的浏览器 <-----> 用户 B 的浏览器
| |
摄像头/麦克风 摄像头/麦克风
典型产品：
Google MeetDiscord（Web 版）Facebook MessengerZoom（Web 版）直播互动WebRTC 的低延迟特性（通常 < 500ms）使其非常适合需要实时互动的直播场景。
应用场景：
连麦直播在线拍卖体育赛事实时竞猜电商直播带货对比传统直播协议：
协议典型延迟适用场景HLS10-30 秒点播、大规模直播RTMP3-5 秒推流、传统直播WebRTC< 500ms实时互动在线教育WebRTC 在在线教育领域的应用非常广泛：
1 对 1 辅导：师生实时音视频互动小班课：多人音视频会议大班课：老师端使用 WebRTC，学生端可降级为 HLS互动白板：通过 DataChannel 实现实时协作典型产品：ClassIn、腾讯课堂、VIPKID
P2P 文件传输利用 WebRTC 的 DataChannel，可以实现浏览器之间的点对点文件传输：
// 发送端
dataChannel.send(fileData);
// 接收端
dataChannel.onmessage = (event) => {
saveFile(event.data);
};
典型产品：ShareDrop、Snapdrop、PairDrop
云游戏与远程桌面WebRTC 的低延迟特性使其成为云游戏和远程桌面的理想选择：
云游戏：Google Stadia（已关闭）、NVIDIA GeForce NOW远程桌面：Parsec、Chrome Remote DesktopIoT 与智能设备智能门铃实时视频无人机实时图传工业设备远程监控2.2 WebRTC 解决的核心痛点在 WebRTC 出现之前，浏览器实现实时通信面临诸多挑战：
痛点传统方案WebRTC 方案需要安装插件Flash、Java Applet原生支持，无需插件跨平台兼容性差各平台独立开发统一 API，跨浏览器延迟高服务器中转P2P 直连开发成本高需要深厚音视频背景简单 API 封装3. WebRTC 核心组件WebRTC 的核心由三大组件构成：
┌─────────────────────────────────────────────────────────────┐
│ WebRTC 核心组件 │
├─────────────────┬─────────────────────┬─────────────────────┤
│ MediaStream │ RTCPeerConnection │ RTCDataChannel │
│ (媒体流) │ (对等连接) │ (数据通道) │
├─────────────────┼─────────────────────┼─────────────────────┤
│ 获取音视频数据 │ 建立 P2P 连接 │ 传输任意数据 │
│ 处理媒体轨道 │ 处理信令交换 │ 支持可靠/不可靠传输 │
│ 控制设备访问 │ 管理 ICE 候选 │ 类似 WebSocket API │
└─────────────────┴─────────────────────┴─────────────────────┘
3.1 MediaStream（媒体流）MediaStream 负责获取和管理音视频数据。
获取媒体流
// 获取摄像头和麦克风
const stream = await navigator.mediaDevices.getUserMedia({
video: true,
audio: true
});
// 获取屏幕共享
const screenStream = await navigator.mediaDevices.getDisplayMedia({
video: true
});
核心概念MediaStream：包含一个或多个轨道的媒体流MediaStreamTrack：单个音频或视频轨道MediaDevices：访问媒体设备的接口轨道操作
// 获取所有视频轨道
const videoTracks = stream.getVideoTracks();
// 获取所有音频轨道
const audioTracks = stream.getAudioTracks();
// 禁用视频轨道（关闭摄像头但保持连接）
videoTracks[0].enabled = false;
// 停止轨道（完全释放设备）
videoTracks[0].stop();
3.2 RTCPeerConnection（对等连接）RTCPeerConnection 是 WebRTC 的核心，负责建立和维护 P2P 连接。
核心职责信令交换：交换 SDP（Session Description Protocol）NAT 穿透：通过 ICE 框架建立连接媒体传输：使用 SRTP 加密传输音视频连接管理：监控连接状态、处理重连基本使用
// 创建 PeerConnection
const pc = new RTCPeerConnection({
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' }
]
});
// 添加本地媒体流
stream.getTracks().forEach(track => {
pc.addTrack(track, stream);
});
// 创建 Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// 处理远端 Answer
await pc.setRemoteDescription(remoteAnswer);
// 监听远端媒体流
pc.ontrack = (event) => {
remoteVideo.srcObject = event.streams[0];
};
连接建立流程
发起方 (Caller) 接收方 (Callee)
│ │
│ 1. createOffer() │
│──────────────────────────────────>
│ │
│ 2. setLocalDescription(offer) │
│ │
│ 3. 通过信令服务器发送 Offer ────────>
│ │
│ 4. setRemoteDescription(offer)
│ │
│ 5. createAnswer()
│ │
│ 6. setLocalDescription(answer)
│ │
│ <──────── 7. 通过信令服务器发送 Answer
│ │
│ 8. setRemoteDescription(answer) │
│ │
│ <═══════ 9. ICE 候选交换 ═══════>
│ │
│ <══════ 10. P2P 连接建立 ══════>
│ │
3.3 RTCDataChannel（数据通道）DataChannel 允许在 P2P 连接上传输任意数据。
特点基于 SCTP（Stream Control Transmission Protocol）支持可靠传输和不可靠传输支持有序和无序传输API 类似 WebSocket基本使用
// 创建数据通道
const dataChannel = pc.createDataChannel('myChannel', {
ordered: true, // 是否保证顺序
maxRetransmits: 3 // 最大重传次数
});
// 发送数据
dataChannel.send('Hello, WebRTC!');
dataChannel.send(new ArrayBuffer(1024));
// 接收数据
dataChannel.onmessage = (event) => {
console.log('Received:', event.data);
};
// 监听状态变化
dataChannel.onopen = () => console.log('Channel opened');
dataChannel.onclose = () => console.log('Channel closed');
配置选项选项说明默认值ordered是否保证消息顺序truemaxPacketLifeTime消息最大生存时间（ms）-maxRetransmits最大重传次数-protocol子协议名称''negotiated是否手动协商falseid通道 ID自动分配⚠️ maxPacketLifeTime 和 maxRetransmits 互斥，只能设置其一。
4. WebRTC 的优势与局限4.1 优势✅ 原生支持，无需插件
✅ 超低延迟场景延迟局域网 P2P< 50ms公网 P2P100-300msTURN 中转200-500ms✅ 端到端加密WebRTC 强制使用加密：
DTLS（Datagram Transport Layer Security）：密钥交换SRTP（Secure Real-time Transport Protocol）：媒体加密
┌──────────────────────────────────────────────────┐
│ WebRTC 安全架构 │
├──────────────────────────────────────────────────┤
│ 应用层 │ SDP / ICE │
├──────────────────────────────────────────────────┤
│ 安全层 │ DTLS (密钥交换) + SRTP (媒体加密) │
├──────────────────────────────────────────────────┤
│ 传输层 │ UDP / TCP │
└──────────────────────────────────────────────────┘
✅ P2P 直连，节省带宽成本
传统方案（服务器中转）：
用户 A ──> 服务器 ──> 用户 B
带宽成本 ×2
WebRTC P2P：
用户 A <────────────> 用户 B
带宽成本 ×0
✅ 跨平台支持平台支持情况Chrome✅ 完整支持Firefox✅ 完整支持Safari✅ 支持（iOS 11+）Edge✅ 完整支持Android WebView✅ 支持iOS WKWebView⚠️ 部分支持✅ 开源且免费libwebrtc 完全开源（BSD 许可证）无需支付专利费用活跃的社区支持4.2 局限❌ 大规模场景的挑战P2P 架构在大规模场景下面临挑战：
N 个用户全互联：
连接数 = N × (N-1) / 2
10 人会议 = 45 条连接
50 人会议 = 1225 条连接 ← 不可行！
解决方案：
SFU（Selective Forwarding Unit）：服务器转发，每人只需 1 条上行MCU（Multipoint Control Unit）：服务器混流，带宽最优但 CPU 开销大❌ NAT 穿透成功率不同 NAT 类型的穿透成功率：
NAT 类型穿透难度成功率Full Cone简单~95%Restricted Cone中等~85%Port Restricted Cone较难~70%Symmetric困难~30%当 P2P 穿透失败时，需要 TURN 服务器中转，这会：
增加延迟产生服务器带宽成本❌ 移动端的挑战iOS WKWebView：不支持 getUserMedia后台运行：App 切到后台时连接可能中断网络切换：WiFi/4G 切换时需要重新建立连接❌ 信令服务器仍然需要WebRTC 本身不包含信令机制，开发者需要自行实现：
// 需要自己实现信令服务器
const signalingServer = new WebSocket('wss://your-signaling-server.com');
signalingServer.send(JSON.stringify({
type: 'offer',
sdp: offer.sdp
}));
❌ 调试困难网络问题难以定位编解码问题需要专业知识缺乏统一的调试工具推荐调试工具：
chrome://webrtc-internalsWireshark（配合 SSLKEYLOGFILE）❌ 编解码器兼容性编解码器ChromeFirefoxSafariVP8✅✅✅VP9✅✅❌H.264✅✅✅AV1✅⚠️❌Opus✅✅✅5. 总结WebRTC 核心要点方面要点定义浏览器原生的实时音视频通信技术标准化W3C（API）+ IETF（协议）核心组件MediaStream + RTCPeerConnection + RTCDataChannel核心优势无插件、低延迟、端到端加密、P2P主要局限大规模场景、NAT 穿透、移动端兼容适用场景判断
是否需要实时互动？
│
├── 是 ──> 延迟要求 < 1s？
│ │
│ ├── 是 ──> WebRTC
│ │
│ └── 否 ──> 考虑 RTMP/HLS
│
└── 否 ──> 考虑其他方案
下一篇预告在下一篇文章中，我们将深入探讨 WebRTC 的架构设计，包括：
浏览器中的 WebRTC 架构API 体系详解信令流程libwebrtc 媒体引擎结构参考资料WebRTC 1.0: Real-Time Communication Between Browsers - W3CWebRTC Official WebsiteHigh Performance Browser Networking - WebRTC ChapterGoogle’s WebRTC ProjectMDN Web Docs - WebRTC API