webRTC进阶-概览-之一：WebRTC 会议的组网技术对比与分析

一、网络拓扑结构

WebRTC除了用于P2P通信外，还可以用作多方呼叫，如视频会议。
当其用于多方呼叫时，我们需要为我们的应用选择一个架构。
这一个非常重要的决定，因为如何组织用户关系到会议系统的扩展规模。

对应于WebRTC, 有两个常用的网络拓扑结构:
  网状网络 和 星状网络

1.1 网状网络

最常见的拓扑结构是网状网络，
在这种网络中，每个端都要发送数据给网络中的其它端。
在一个全连通网状网络中，会有 " N*（N-1) "个连接，其中N为端的个数。
例如，一个4用户的全联通网络，会有12个连接。

图2. 一个4用户的全联通网状网络

在这种网络中，不需要服务端，从而这是一个很便宜的应用选择。
它的缺陷则在于，随着网络中参与者的增加，需要更多的带宽和CPU负载。
因此，这样的架构不适合于更大的网络。

1.2 星状网络

在星状网络架构中，我们可以选择很常用的网络hub，
它的作用是接收会议呼叫方的所有数据，然后再发送一个适当的组合流到每个端。

不像网状网络，星状网络很容易加入新用户或离开网络。
而且，星状网络可以Mix独立的流再将Mix后的流做分发。
这样，对于网络中的每个端来说，只需要传输单个流，它大大节省了带宽和CPU，
只是大量的处理工作都迁移到了Hub(通常称作会议桥)。

它的缺点在于它是依赖于hub的，如果Hub宕机，则整个网络就不能工作。
对于它来说，可加入到网络的端数以及可处理的共享的流的个数取决于Hub的能力。

Fig3 星状网络拓扑结构图

1.3 MCU

Multipoint Control Unit (MCU) 和星状网络相似，在我们后面的分析中，
使用了一个优化过的服务器，它能很好地处理实时数据。
但是，MCU的成本很高，它增加了整个网络成本。

二、网状网络和星状网络的比较

本文比较了网状网络和星状网络对用户增长时网络和CPU负载情况。

2.1 测试方法

将两台电脑直接相连就可以组成一个网状网络。
我发现 https://appear.in/ 有一个网状网络的构建方法，
在它里面有一个组聊的应用，它可以实现基于浏览器的WebRTC API多方会议呼叫，
也不用安装或注册账号。
我在里面创建了一个房间号，这样每当用户连接到这个房间时，
浏览器都会先请求用户权限以获得摄像头和Mic。用户选择确认后即可加入房间。

在测试中，我只使用了声音流，并使用了播放MP3来代替讲话的声音。
CPU的负载测试我使用的是任务管理器。
https://appear.in/只允许最多8个用户在同一个房间中。

星状网络我使用的方案是 https://meet.jit.si/ , 它构建了WebRTC桥。

2.2 结果

相比于星状网络来说，网状网络消耗了大量的CPU。
实际上，我并没有在网状网络测试中达到8个用户的连接，CPU就已经到最大负载了。
而星状网络完全没有问题，还可以加入更多的人。

下面的图显示了两种网络的CPU负载和网络负载。

图4 CPU负载

图5 网络负载
​
在第一张图中，星状网络始终只有10~20%的CPU负载。
在张二张图中，网络网络中的用户增加到多于4个时，会有显著的带宽增长。

2.3 分析

比较来看，星状网络有更好的可扩展性。
而网状网络有多于7个用户在同一个房间中时，会导致CPU负载的剧烈增长。

而网状网络在2-4用户位于同一个房间中的情况能工作得很好，
但是这之后，用户再增长的话会导致延时增长很快。
这主要是因为，在网状网络中，房间中的每个用户都要发送和接收数据。
因此，用户越多，带宽的增长越快。
而且，因为浏览器会随着用户的增长而增加更多的编码和解码的工作，
从而导致了CPU负载的增长。

但在星状网络中，它的负载是由Hub承担的，所以本机端的CPU和带宽负载无影响。
从而可以支撑更多的用户加入到房间中。

原文:
《Comparing different network topologies for WebRTC conferencing》