---

一、三种架构

webrtc大致可以分为三种架构：

• MESH
  mesh架构需要所有参与连接的peer简历和所有其他peer的媒体的连接，如图一。
  该架构需要n-1个上下行，以此带来的带宽消耗（流量）、编/解码消耗（手机性能）成线性增长。（注: 上行和下行是电脑宽带方面的名次，指的是上行带宽和下行带宽，上行带宽指的是上传的速度，下行带宽指的是下载数据的速度。）
  该架构只能适用3-4个人的小型会议场景。

下图就是mesh结构的另外一种形式，即引入turn协议服务器来做转发。

与一对一通话一样，如果两个端能够顺利建立 P2P 的连接，则直接通过 P2P 互相交换数据；如果无法打通，则利用 Turn Server 来中转数据。

• SFU
  SFU 的全称是：Selective Forwarding Unit，是一种通过服务器来路由和转发 WebRTC 客户端音视频数据流的方法。相对于MCU来说SFU只做转发，媒体服务器压力有限。与mesh架构相比，只需要n-1个下行，1个上行。在大规模的场合该架构具有伸缩性。

如图所示，SFU 服务器最核心的特点是把自己 “伪装” 成了一个 WebRTC 的 Peer 客户端，WebRTC 的其他客户端其实并不知道自己通过 P2P 连接过去的是一台真实的客户端还是一台服务器，我们通常把这种连接称之为 P2S，即：Peer to Server。除了 “伪装” 成一个 WebRTC 的 Peer 客户端外，SFU 服务器还有一个最重要的能力就是具备 one-to-many 的能力，即可以将一个 Client 端的数据转发到其他多个 Client 端。

这种网络拓扑结构中，无论多少人同时进行视频通话，每个 WebRTC 的客户端只需要连接一个 SFU 服务器，上行一路数据即可，极大减少了多人视频通话场景下 Mesh 模型给客户端带来的上行带宽压力。

SFU 服务器跟 TURN 服务器最大的不同是，TURN 服务器仅仅是为 WebRTC 客户端提供的一种辅助的数据转发通道，在 P2P 不通的时候进行透明的数据转发。而 SFU 是 “懂业务” 的， 它跟 WebRTC 客户端是平等的关系，甚至 “接管了” WebRTC 客户端的数据转发的申请和控制。

• MCU
  所有本房间的peer将本地媒体流推到远程媒体服务器，由媒体服务器进行混流，然后再推到所有连接的peer端。该架构的优点就是只需要1路上下行，随着peer人数不断增加，依然不会对用户造成带宽、手机性能影响。该架构将压力转嫁到服务端，由专用媒体服务器来完成混流，转推等功能。

从上述 SFU 的定义可以看到，SFU 这种网络拓扑模型，通过由 SFU Server 来实现 one-to-many ，减轻了多人视频通话场景下每个客户端的上行带宽压力，但是下行依然是多路流，随着通话人数的增大，下行带宽的压力依然会成比例的增大，那能否让下行也只剩一路流呢？—— 可以，通过在服务器端合流后再下发即可解决，如上图所示：

这种网络拓扑结构，被称之为 MCU，它的特点是，由 MCU Server 将各路客户端上行的视频流合成为一路，再转发给其他客户端。这种模型相比于 SFU 降低了多人视频通话场景下客户端的下行带宽压力，但是由于合流需要转码操作，对服务器端压力比较大，而且下发给客户端的流是固定的合流画面，灵活性不是特别好。

二、为什么SFU最为常用？

综上所述，纯 mesh 方案无法适应多人视频通话，也无法实现服务端的各种视频处理需求，最先排除在商业应用之外。

SFU 相比于 MCU，服务器的压力更小（纯转发，无转码合流），灵活性更好（可选择性开关任意一路数据的上下行等），受到更广泛的欢迎和应用，常见的开源 SFU 服务器有：Licode，Janus，Jitsi，mediasoup，Medooze 等等，各有特点，大家可以去项目主页了解更详细的情况。

当然，也可以组合使用 SFU + MCU 的混合方案，以灵活应对不同场景的应用需要。

---