1、WebRTC初探:WebRTC是什么、WebRTC发展史、WebRTC能做什么、WebRTC整体架构

各位同学,欢迎来到《WebRTC多人视频会议实战》的第一课。

在正式开始写代码之前,我觉得有必要先聊聊WebRTC到底是什么。说实话,我刚开始接触WebRTC的时候,也以为它只是个“浏览器里开视频”的API。后来踩了不少坑,才真正理解它的价值。

1.1 WebRTC是什么?

WebRTC,全称是 Web Real-Time Communication(网页实时通信)。

说白了,它就是一套让浏览器之间能直接进行音视频通话、文件传输的技术标准。不需要装插件,不需要第三方软件,打开网页就能聊。

核心特点:

  • 点对点通信:数据不经过服务器中转,延迟极低
  • 浏览器原生支持:Chrome、Firefox、Safari、Edge 都支持
  • 开源免费:Google 主导,代码完全开放
  • 加密传输:所有媒体流默认强制加密

嗯,这里要注意:WebRTC 不是某个库,也不是某个框架。它是一整套协议 + API 的集合。你在浏览器里调用的 getUserMediaRTCPeerConnection,只是它的冰山一角。

1.2 WebRTC发展史

聊历史之前,我先讲个小故事。2010年左右,Google 想做一个浏览器内的视频通话功能,但发现当时的技术方案都不靠谱——Flash 太卡,插件不安全,SIP 协议又太重。于是 Google 干脆自己搞了一套。

2011年,Google 开源了 WebRTC 项目。我记得当时圈内很多人都不看好,觉得“浏览器做实时通信?太天真了”。结果呢?

时间 里程碑事件
2011年 Google 开源 WebRTC,Chrome 率先支持
2013年 Firefox 加入支持,跨浏览器通话成为可能
2017年 W3C 发布 WebRTC 1.0 候选推荐标准
2021年 WebRTC 成为 W3C 正式推荐标准
至今 几乎所有现代浏览器都原生支持

为什么会发展这么快?你想想看,疫情期间 Zoom、腾讯会议爆发式增长,背后都有 WebRTC 的影子。它已经成了实时通信的事实标准。

1.3 WebRTC能做什么?

这个问题,我建议你从两个维度来看:媒体能力数据能力

媒体能力

  • 音视频通话:一对一、多人会议
  • 屏幕共享:分享整个屏幕或某个窗口
  • 直播推流:用浏览器做直播源
  • 视频录制:结合 MediaRecorder 实现

数据能力

  • 文件传输:点对点传文件,不经过服务器
  • 实时游戏:低延迟的多人对战
  • 远程桌面:控制另一台电脑
  • IoT 控制:智能设备间的实时通信

避坑指南:我曾经在做一个远程医疗项目时,想用 WebRTC 传高清医学影像。结果发现 WebRTC 默认的编码器对静态图像并不友好。后来改用 RTCDataChannel 传原始数据,才解决问题。所以,选对场景很重要。

1.4 WebRTC整体架构

这部分是重点。我画了一张架构图,帮你理清 WebRTC 的各个模块。

WebRTC 整体架构 应用层(Application) 你的代码:getUserMedia / RTCPeerConnection / RTCDataChannel WebRTC API 层 浏览器暴露的 JavaScript 接口 WebRTC 引擎(C++ 实现) Voice Engine 音频编解码 / 回声消除 Video Engine 视频编解码 / 抖动缓冲 Transport SRTP / ICE / DTLS 网络传输层 UDP / TCP / STUN / TURN / ICE

从上往下看,架构分四层:

  1. 应用层:你写的 JavaScript 代码。调用 getUserMedia 获取摄像头,创建 RTCPeerConnection 建立连接。
  2. API 层:浏览器暴露给 JS 的接口。不同浏览器实现略有差异,但标准是统一的。
  3. 引擎层:这是 WebRTC 的核心,用 C++ 实现。包括音频引擎(回声消除、降噪)、视频引擎(编解码、自适应码率)、传输引擎(ICE、DTLS、SRTP)。
  4. 网络层:处理 NAT 穿透(STUN/TURN)、连接管理(ICE)、数据加密(DTLS/SRTP)。

注意:很多初学者以为 WebRTC 只是前端的事。其实它涉及大量网络知识——NAT 穿透、ICE 候选、SDP 协商。我在做第一个项目时,就因为不理解 ICE 流程,卡了整整两天。后面我们会专门讲这部分。

1.5 为什么选择 WebRTC?

你可能要问:市面上那么多实时通信方案,为什么偏偏选 WebRTC?

我个人习惯从三个角度判断:

  • 延迟:WebRTC 基于 UDP,延迟可以做到 200ms 以内。传统的 HTTP 轮询动辄几秒。
  • 成本:点对点通信不需要昂贵的服务器中转带宽。多人会议才需要 SFU/MCU 服务器。
  • 生态:Google、Apple、Microsoft 都在推。你不用担心技术被淘汰。

嗯,当然它也不是万能的。比如你要做万人直播,WebRTC 就不太合适——它设计之初就是为小规模、低延迟场景服务的。

1.6 本章小结

这一章我们聊了 WebRTC 是什么、怎么来的、能做什么、底层长什么样。说白了,它就是浏览器里的实时通信工具箱。

下一章开始,我们会动手写代码。我会带你从零搭建一个多人视频会议系统。到时候你会发现,理解了架构,写代码其实没那么难。

一句话记住:WebRTC = 浏览器原生支持的、点对点的、低延迟的实时通信技术。


公众号:蓝海资料掘金营,微信deep3321