WebRTC / Jitsi / 多人视频通讯常用架构 Mesh / MCU / SFU

问题：为什么要搞这么多架构？

WebRTC 虽然是一项主要使用 P2P 的实时通讯技术，本应该是无中心化节点的，但是在一些大型多人通讯场景，如果都使用端对端直连，端上会遇到很带宽和性能的问题，所以就有了下图的三种架构。

一、Mesh

每个端都与其它端互连。

以上图最左侧为例，5个浏览器，二二建立 P2P 连接，每个浏览器与其它 4 个建立连接，总共需要10个连接。如果每条连接占用1M带宽，则每个端上行需要4M，下行带宽也要4M，总共带宽消耗20M。而且除了带宽问题，每个浏览器上还要有音视频“编码/解码”，CPU使用率也是问题，一般这种架构只能支持4~6人左右，不过优点也很明显，没有中心节点，实现很简单。

二、MCU (MultiPoint Control Unit)

这是一种传统的中心化架构(上图中间部分)，每个浏览器仅与中心的MCU服务器连接，MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑，每个浏览器只要1个连接，整个应用仅消耗5个连接，带宽占用(包括上行、下行）共10M，浏览器端的压力要小很多，可以支持更多的人同时音视频通讯，比较适合多人视频会议。但是MCU服务器的压力较大，需要较高的配置。

三、SFU(Selective Forwarding Unit)

上图右侧部分，咋一看，跟MCU好象没什么区别，但是思路不同，仍然有中心节点服务器，但是中心节点只负责转发，不做太重的处理，所以服务器的压力会低很多，配置也不像MCU要求那么高。但是每个端需要建立一个连接用于上传自己的视频，同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5，消耗的带宽也是最大的，如果每个连接1M带宽，总共需要25M带宽，它的典型场景是1对N的视频互动。

目前，随着5G技术的推广，可以预见带宽越来越不是问题，所以SFU在未来，可能会更有优势。

建议：如果规模不大(5人以下) Mesh框架就够用了，毕竟实现简单；如果50人以下，且带宽有限，选择MCU比较适合；如果规模更大，且带宽良好，SFU相对更适合。

四、拓展

附上几个github上比较火的webrtc MCU/SFU server项目：

1. https://github.com/Kurento/kurento-media-server  (kurento官网的文档和示例很齐全，对于开发者来说，非常友好)。
2. https://github.com/lynckia/licode (官网文档很少，学习曲线略陡峭)。
3. https://github.com/jitsi/jitsi (据说性能不错，而且还提供了一个视频会话的子项目jitsi-meet，但是文档仍然不多，得生啃代码）。
4. https://github.com/pion/webrtc/ (github上star很高，go语言开发，但目前好象尚不太成熟，文档也不是太全，未来看好)

 

（SAW：Game Over！）