多人音视频实时通讯是怎样的架构？ _架构

文章插图

在前面的章节里，我们通过大量的篇幅介绍了 WebRTC 在浏览器上对实时通信的各种支持。WebRTC 本身提供的是 1 对 1 的通信模型，在 STUN/TURN 的辅助下，如果能实现 NAT 穿越，那么两个浏览器是可以直接进行媒体数据交换的；如果不能实现 NAT 穿越，那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看，google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。
如果你想要通过 WebRTC 实现多对多通信，该如何做呢？其实，基于 WebRTC 的多对多实时通信的开源项目也有很多，综合来看，多方通信架构无外乎以下三种方案。

Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
MCU（Multipoint Conferencing Unit）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
SFU（Selective Forwarding Unit）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

了解了上面几种通信架构后，接下来，我们分别论述一下这几种架构。
1 对 1 通信不过在讲解多对多架构模型之前，咱们得先回顾一下之前讲的 WebRTC 1 对 1 通信的模型，因为只有在 1 对 1 通信模型非常清楚的情况下，你才能知道多对多通信模型的复杂度到底体现在哪儿。
在 1 对 1 通信中，WebRTC 首先尝试两个终端之间是否可以通过 P2P 直接进行通信，如果无法直接通信的话，则会通过 STUN/TURN 服务器进行中转，如下图：

文章插图

WebRTC 1 对 1 音视频实时通话示意图
上面这张图咱们已经见过无数次了，相信你对它已经十分熟悉了。实际上，1 对 1 通信模型设计的主要目标是尽量让两个终端进行直联，这样即可以节省服务器的资源，又可以提高音视频的服务质量。
如果端与端之间可以直接通信，那么上图中的 STUN/TURN 服务器的作用就只是用于各终端收集 reflx 类型的 Candidate。而如果端与端之间无法直接进行通信的话，那么 STUN/TURN 服务器就变成了中继服务器，可以利用它进行端与端之间数据的中转。
Mesh 方案1 对 1 通信模型下，两个终端可以互相连接，那么我们是否可以让多个终端互相连接起来，从而实现多人通信呢？理论上这是完全可行的。Mesh 方案的结构如下图所示：

文章插图

Mesh 方案架构图
在上图中，B1、B2、B3、B4 分别表示 4 个浏览器，它们之间两两相连，同时还分别与 STUN/TURN 服务器进行连接（此时的 STUN/TURN 服务器不能进行数据中转，否则情况会变得非常复杂），这样就形成了一个网格拓扑结构。
当某个浏览器想要共享它的音视频流时，它会将共享的媒体流分别发送给其他 3 个浏览器，这样就实现了多人通信。这种结构的优势有如下：