WebRTC的通信架构

摘要

本文简要描述了WebRTC的端到端和多对多通信架构及相关术语。

WebRTC端到端通信架构

WebRTC最核心的目标是端到端（Peer to Peer）的实时音视频通信。WebRTC如果没有通信功能，就成了本地音视频采集和播放器了。

WebRTC端到端通信架构图

上图的主要节点功能如下：

1. 信令服务器：处理会话命令，比如会话（俗称房间）的创建、拆除。
2. STUN/TURN服务器：在尝试点对点通信时，负责辅助NAT穿透（俗称P2P打洞）；在点对点通信不可用时，负责音视频数据的中继转发。
3. Peer A和Peer B：参与通信的两个浏览器实例。这两个实例可以运行在同一个防火墙后的同一台PC上。

 WebRTC端到端通信实验

为了对WebRTC的特性增加一点感性的认知，我们需要动手搭建一个最简单的WebRTC实验环境。

实验环境只需支持在两个浏览器端进程之间进行1对1的实时音视频通话功能即可。

由于浏览器已经集成了WebRTC原生模块，因此在WebRTC Web开发中，我们不用关心WebRTC项目源码，只需要了解其Web API用法。只有涉及WebRTC原生（Native）开发时，我们才有必要亲自构建WebRTC项目源码，将自己构建的WebRTC模块集成到自研的原生App中。

作者建议初学者先学习WebRTC Web端开发，有了一定基础和感性认识后，再学习WebRTC Native开发。

推荐github示例项目：GitHub - muaz-khan/WebRTC-Experiment: WebRTC, WebRTC and WebRTC. Everything here is all about WebRTC!!

WebRTC在线演示1：ZLM RTC demo

WebRTC在线演示2：RecordRTC | WebRTC Audio+Video+Screen Recording

WebRTC多对多通信架构

通过WebRTC的Web API，我们还可以在览器端实现多对多（包含1对多）的视频会议系统。

WebRTC多对多的通信架构可以分为三种实现方案：

1.Mesh方案，浏览器端与端之间点对点通信，形成一个网状的结构。优点是对服务器带宽和计算性能要求最低，缺点是在规模较大的情况下会对网络造成拥塞，且通信质量难以保证。在国内的网络环境下，点对点的NAT穿透（俗称P2P打洞）的成功率可能不到50%，如果NAT穿透失败，就无法进行点对点双向通信。

2.MCU（Multipoint Conferencing Unit）方案，中文名称是“多点会议单元”。高级的视频会议系统通常有一个专门的负责混合多方视频画面的中心节点设备，将多个参会者的画面合成一张网格布局的画面，然后重新压缩，分发给每一个参会者。这种专用的MCU中心节点设备通常比较昂贵，对视频实时解码和编码性能要求非常高。这种会议系统缺点是每个参会者只能看到一致的画面布局，优点是对带宽的要求相对较低。目前，随着互联网带宽的不断提升，这种方案正在逐渐消失。

3.SFU（Selective Forwarding Unit）方案，中文名称是“选择性转发单元”。这种多人会议系统，每个参会者可以选择观看不同参与者的视频码流，自定义画面布局，中心节点只是根据观察者的画面布局选择性转发即可。优点是对服务器的CPU和视频编解码性能要求低，缺点是对带宽要求比较高。这是目前最常用的一种通信方案。

总结

本文简要介绍了WebRTC通信架构和相关术语，后续文章会经常使用本文定义的概念和术语，希望读者能用心领会。