视频RTC通信常采用的几种架构方式及其应用场景：MCU/SFU、视频会议、应急指挥、即时通信

我们这里常说的RTC可以理解为WebRTC技术，因为WebRTC技术是目前使用最广泛的即时通信技术，虽然在早期我们提到WebRTC、提到视频通话就会想到P2P的方式，但实际的视频通话方式背后的逻辑有很多种，p2p并不能解决所有的网络通信问题，视频通话会采用多种架构相结合的方式，保障用户视频通话的接通率。

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

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

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

在TSINGSEE视频里面，我们也在不断对MCU、SFU的使用场景进行研究和拓展，在许多的应急指挥场景中，我们不仅需要即时的通信，而且需要事后的回溯，所以MCU的录像功能是必不可少的，而当我们在人数众多的集群调度和大班课教学时，我们又需要对感兴趣的视频源选择接听，而对大部分的非相关人员视频屏蔽，在多方连线场景中，我们需要选择性看清楚现场情况，放大单路视频，所以这些情况，MCU和SFU的选择不是绝对的，而将会是相互结合的；

在WebRTC方面，我们已经逐步拓展了EasyRTC视频会议与EasyRTS应急指挥系统，EasyRTC具有MCU和SFU两个版本，EasyRTS则采用SFU接入与后端视频处理的方式，完美地解决了视频即时通信的各种应用场景需求。

视频相关的解决方案都可以到TSINGSEE视频查看一下系统效果：www.tsingsee.com