最简单的WebRTC实例可以让你在两个浏览器之间建立一个实时的端对端连接，在其中交换个人视频、音频和数据。具体过程如图：

最简单的WebRTC形式

当然，大家都知道还需要信令和几个STUN/TURN服务器来完成上述操作。目前，我们先假设这些部分都已齐全。

办个派对

如果我们在上述连接中加入一个用户，两个用户，三个用户，会发生什么呢？这就是被定义为多方参与的一种情况。此种情况下的规则有所不同，甚至可以说大不相同。

涉及到如何处理WebRTC上的多方连接时，有三种策略可供选择——Mesh、SFU和MCU。Mesh是最简单，也可能是最常用的解决方案。今天我们要讨论的就是它。

Mesh

为了保证连接成功，使用RTCPeerConnection API的每一端都必须创建一个连接对象。这个连接对象需要添加所有相关的信息，如视频和音频流、STUN/TURN服务器地址，以及创建 Interactive Connectivity Establishment (ICE)候选者，或接收任何数据时所需的处理程序。

然后，API负责使用所有已传递的数据建立连接，这其中会有一个信令处理的过程。

最后，我们只需对添加到呼叫中的每一位重复这一过程。换句话说，我们会为每一位都创建另外的RTCPeerConnection对象。

因此，如果我们使用该策略，在上述图表中添加一端，过程看起来会是这样的：

可以看到，现在每一端都在通过向其他两端发送媒体流和数据，来维护另外的一个连接。同时，每一端也会从另两端那里接收媒体流和数据。

谁负责邀请大家来参加派对

那么，如果再增加几个对等端会是什么样子呢？

若用户数量持续增加，处理和带宽的消耗会过大。该问题在移动设备或低配电脑上会更为明显，因为他们的资源更有限。此外，宽带连接也是如此。因为宽带连接通常与合同挂钩，规定了每月的流量使用限制。

若总计有五个用户，每个浏览器都需要维持四个额外的连接，用于发送、接收流和数据，以及与其他对等端进行交流。

综上所述，我们可以说Mesh是实现多方交流的最简单的方法。因为它不需要对基础设施进行任何改变。所有的工作都可以在浏览器上完成。问题是，这种架构只适用于少量的用户。

替代方案

如果想在不产生任何问题的前提下支持更多的用户，我们需要找到另一种可替代策略，一种允许我们混合所有由Mesh创建的连接，或以某种方式路由它们，以避免客户端的高CPU和带宽消耗。比如说MCU (mixing connections) ，以及 SFU (routing connections) 等方法。

使用WebRTC搭建应用程序比大家想象中要难。该操作需要一个专家团队来完成。

文章地址：One for All, All for One: WebRTC Mesh Architecture – WebRTC.ventures

原文作者：Hector Zelaya