问题：为什么要搞这么多架构？
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相对更适合。
附上几个github上比较火的webrtc MCU/SFU server项目：
https://github.com/Kurento/kurento-media-server (kurento官网的文档和示例很齐全，对于开发者来说，非常友好)
https://github.com/lynckia/licode (官网文档很少，学习曲线略陡峭)
https://github.com/jitsi/jitsi (据说性能不错，而且还提供了一个视频会话的子项目jitsi-meet，但是文档仍然不多，得生啃代码）
https://github.com/pion/webrtc/ (github上star很高，go语言开发，但目前好象尚不太成熟，文档也不是太全，未来看好)
参考文章：
https://webrtcglossary.com/mcu/
https://antmedia.io/webrtc-servers/
https://www.html5rocks.com/en/tutorials/webrtc/basics/
https://webrtcglossary.com/sfu/
https://www.jianshu.com/p/ac307371def4 (写得不错的一篇关于webrtc的架构文章)
