1、WebRTC初探：什么是WebRTC、WebRTC的发展历史、WebRTC的核心应用场景
大家好，欢迎来到《WebRTC音视频采集实战》的第一课。
说实话，每次带新人入门WebRTC，我都会先问一个问题：你想想看，为什么一个浏览器，不需要装任何插件，就能跟千里之外的人视频通话？ 这背后，就是WebRTC在起作用。
我个人习惯把WebRTC比作「音视频领域的HTTP」。HTTP让网页内容的传输变得标准化，而WebRTC让实时音视频通信变得标准化。嗯，这个比喻虽然不完全准确，但能帮你快速理解它的地位。
1.1 什么是WebRTC？
WebRTC，全称是 Web Real-Time Communication，即网页实时通信。它是一个开源的项目，由Google发起，现在由W3C和IETF共同维护。
说白了，它是一套浏览器原生支持的API，让两个浏览器之间可以直接传输音视频数据，甚至任意二进制数据，不需要中间服务器转发媒体流。
核心要点：WebRTC不是单个API，而是一组API的集合，包括：
MediaStream（getUserMedia）—— 采集摄像头和麦克风RTCPeerConnection—— 建立点对点连接RTCDataChannel—— 传输任意数据
我在项目中遇到过不少新手，以为WebRTC只是一个「视频通话库」。其实它底层还涉及了NAT穿透、编解码器协商、带宽估计、丢包重传等一系列复杂机制。你想想看，如果这些都要自己从头实现，那得写到猴年马月去。
1.2 WebRTC的发展历史
WebRTC的历史，其实挺有意思的。我简单梳理一下关键节点：
| 时间 | 事件 | 我的点评 |
|---|---|---|
| 2011年 | Google收购GIPS公司，获得音视频引擎核心技术 | 这一步很关键，GIPS的编解码和回声消除技术至今仍是WebRTC的基石 |
| 2011年5月 | Google开源WebRTC项目 | 我记得当时圈内一片欢呼，终于不用自己写音视频引擎了 |
| 2013年 | Chrome和Firefox首次实现WebRTC互通的视频通话 | 那天我特意试了一下，虽然画质一般，但意义重大 |
| 2017年 | W3C发布WebRTC 1.0候选推荐标准 | API基本稳定，各大浏览器开始全面支持 |
| 2021年 | WebRTC成为W3C正式推荐标准 | 历时十年，终于转正了 |
为什么会花这么长时间？因为WebRTC涉及的东西太多了——浏览器厂商要统一API，还要协商编解码器（VP8、VP9、H.264），更要解决防火墙穿透的问题。我曾经参与过一个项目，光是STUN/TURN服务器的选型和调优就折腾了两周。
一个小知识：WebRTC的「SDP协商」机制，其实借鉴了SIP协议的思想。如果你做过VoIP开发，上手WebRTC会非常快。
1.3 WebRTC的核心应用场景
说到应用场景，很多人第一反应就是「视频会议」。没错，这是最典型的场景，但远不止于此。我根据实际项目经验，把WebRTC的应用场景分为三大类：
1.3.1 实时音视频通信
- 视频会议/在线教育：Zoom、Google Meet、腾讯会议的后台技术都大量使用了WebRTC（或基于其改造的版本）
- 远程医疗：我参与过一个远程问诊项目，医生端用WebRTC采集高清摄像头画面，患者端用手机浏览器就能接入，不需要安装任何App
- 直播连麦：主播和观众之间的实时互动，延迟控制在500ms以内
1.3.2 实时数据传输
- 文件传输：利用RTCDataChannel，可以实现浏览器之间的点对点文件传输，速度比服务器中转快得多
- 游戏同步：一些网页游戏用DataChannel传输玩家位置和状态，延迟极低
- IoT设备控制：我见过一个智能家居方案，用WebRTC在手机和摄像头之间建立直接通道，控制指令和视频流走同一条链路
1.3.3 屏幕共享与远程协助
- 远程桌面：Chrome远程桌面就是基于WebRTC实现的
- 在线协作：多人同时编辑文档时，用DataChannel同步光标位置和操作
避坑指南：我曾经在一个项目中，直接用WebRTC做万人直播，结果服务器带宽被打爆了。后来才明白，WebRTC的P2P架构不适合大规模直播场景，需要配合SFU（Selective Forwarding Unit）服务器做媒体流分发。这个后面我们会详细讲。
1.4 WebRTC的技术架构概览
为了让你对WebRTC有个整体认识，我画了一张架构图。这张图涵盖了WebRTC的核心模块和它们之间的关系：
从这张图你可以看到，WebRTC分为四层：
- 应用层：你写的业务代码，比如UI交互、房间管理
- Web API层：浏览器暴露给JavaScript的三个核心API
- 音视频引擎层：处理编解码、回声消除、带宽估计等脏活累活
- 传输层：负责NAT穿透、加密传输、丢包重传
我个人觉得，理解这个分层结构很重要。很多初学者一上来就调API，遇到问题就懵了。其实大部分问题都出在传输层——比如防火墙没开、STUN服务器配置不对。后面我们会专门用一节课来讲这个。
1.5 为什么选择WebRTC？
你可能要问：市面上那么多音视频方案，为什么偏偏选WebRTC？
我总结了几点：
- 免费且开源：没有授权费，代码随便改。我见过一些公司基于WebRTC做二次开发，定制自己的音视频引擎
- 浏览器原生支持：Chrome、Firefox、Safari、Edge都支持，用户不需要装任何插件
- 移动端也有：Android和iOS的WebView都支持WebRTC，一套代码跑两端
- 生态成熟：有大量的开源SFU服务器（比如Janus、Mediasoup、LiveKit），社区活跃
我的建议：如果你只是做原型验证，直接用浏览器的getUserDemo就够了。但如果是生产环境，一定要考虑SFU服务器的选型。我踩过的坑是：一开始用Mesh架构（所有客户端互连），结果5个人视频会议就把带宽吃满了。后来换成SFU，同样的带宽能支持20人。
好了，这一章我们初步认识了WebRTC。下一章我们会动手写第一个demo——用getUserMedia采集摄像头画面。到时候你会发现，原来这么简单几行代码就能看到自己的脸出现在浏览器里。
公众号:蓝海资料掘金营，微信deep3321