目录
前言
正文
简介
缺点
优点
2. MCU（Multi-point Control Unit）
简介
缺点
优点
3. SFU（Selective Forwarding Unit）
简介
缺点
优点
结论
前言
WebRTC 在构建浏览器视频会话的时候，肯定少不了服务器的支持。目前，WebRTC 主要有三种网络架构：Mesh、MCU、SFU。今天就来分别介绍一下三者，带大家认识一下它们的优点和缺点。
正文
1. Mesh（P2P）
简介
Mesh 服务器架构其实就是标准 P2P 通讯模式的混用，每一个 P2P 连接有独立的传输策略控制，通讯质量有一定的保障。但是，这种架构对于客户端系统是一种浪费，一方面需要分配更多的端口，消耗更多的系统资源；另一方面，由于要向其它三个客户端发送本地音视频数据，增加了上行网络带宽的消耗，在同等带宽条件下，支持的多人通话路数就相对有限，视频质量(码率)也比较低。这种架构比较适合网络状况较好，人数较少，比如一对一的场景中。
缺点
a. 占用大量带宽。以上图为例，假设所有上下行媒体流占用带宽都是 1MB，那么，每个客户端需要提供 3MB 的上行带宽和 3MB 的下行带宽，每个客户端总体消耗的带宽是 6MB。如果复用 PeerConnection 通道的话，也需要建立六条链路。
b. 占用客户端资源。如上图所示，每个客户端在通讯过程中需要同时编码三路媒体流，分别发送给另外三个参会者，而不是共用一路编码媒体流。因此，会占用比较多的客户端资源。
优点
a. 对服务器资源占用最小。这一点也非常好理解，因为压根儿就没有用到流媒体服务器，只需要一个 ICE 穿透服务器就可以满足 P2P 打洞从而建立连接。
b. 成本最低。不像其他架构类型需要对流媒体服务器投入大量的资金和人力成本，节省了在服务器方面的绝大多数支出费用。
c. 去中心化。充分利用了客户端的算力，在边缘计算的大时代下，可能未来还会迎来新的机遇和挑战。
2. MCU（Multi-point Control Unit）
简介
MCU 将接收到的多路流进行转码和混合，并向每个终端输出单路流的做法，节省了终端用户的下行带宽，并且还能够对不同网络条件的用户，订制不同码率的输出视频流，让多人场景有更好的用户体验。典型的应用场景是多人音视频通话。这种架构比较适合客户端条件较差的场景，比如使用手机进行多人的视频通话，由服务端来抵消移动端的资源消耗。
缺点
a. 对服务器压力最大。MCU 服务架构需要系统提供一个中心化的 MCU 混流服务器，所有媒体流的解码、编码、转码、混合都在服务器端完成。如上图所示，四个客户端需要把自己的媒体流推流到 MCU 服务器，然后 MCU 服务器再对这四路媒体流进行解码、混流，最后把合并的媒体流发送给四个参会者。因此，MCU 架构的服务器压力非常大，也是三种服务架构中压力最大的。
b. 自定义布局复杂。一般情况下，MCU 服务器仅混流编码一路合并之后的媒体流，上图中的四个参会者接收到的混流媒体流是同一路，看到的视频画面也是一致的。如果某个参会者想改变视频画面的布局，比如放大某个人的视频画面，或者关闭某个人的视频画面，通常是无法满足的。但是，我们也可以定义单独的信令逻辑，请求 MCU 服务器单独编码一路媒体流发送给特定需求的参会者。但是，需要限制或者避免所有参会者都有类似的需求，否则 MCU 服务架构会退化成 SFU 服务架构。
c. 成本最高。如果资金允许的话，还是应该考虑引入高级的 GPU 加速服务器，用来提高流媒体服务器的混流能力。但是，成本也会相应提高。
优点
a. 带宽占用最小。还以上图为例，假设每路媒体流所占带宽大小为 1MB，每个客户端总体消耗的带宽是 2MB。如果复用 PeerConnection 通道的话，只需要建立四条链路。
b. 客户端解码压力小。因为每个参会的客户端都只需要解码一路媒体流，就可以代替分别解码每个参会者媒体流的情况，而另外两种服务架构都需要单独解码其他参会者的媒体流。
3. SFU（Selective Forwarding Unit）
简介
SFU 是解决服务器性能问题最有吸引力的方法，因为它不涉及视频解码和编码的计算费用，它以最低的开销来转发各路媒体流，典型的应用场景是1对多的直播服务。这种架构适用于大多数的情况，人数中等的场景，比如大班课，多人语音通话等。
缺点
a. 客户端解码压力大。这一点和 Mesh 服务架构相似，每个客户端需要解码 n-1 路媒体流。如上图所示，每个客户端需要编码一路媒体流同时解码三路媒体流。
b. 服务器成本也相对较高。其实，一般情况下，SFU 架构的服务器成本介于 Mesh 架构和 MCU 架构之间。但是，这也取决 SFU 服务架构的规模和复杂程度。
优点
a. 服务器压力适中。尽管都需要部署流媒体服务器，但是 SFU 架构和 MCU 架构不一样，它不需要对媒体流解码再混流。SFU 的服务器只负责媒体流的转发或者存储，不做编码、解码、转码、混合等算力要求比较高的任务。所以，服务器端的压力比 MCU 要低很多。
b. 带宽占用适中。以上图为例，依然假设每路媒体流所占带宽为 1MB，那么每个客户端的上行带宽为 1MB，下行带宽为 3MB，每个客户端总体消耗的带宽是 4MB。很明显，占用带宽（4MB）介于 Mesh 架构（6MB）和 MCU 架构（2MB）之间。
c. 布局控制灵活。因为每个参会者都拉取了其他参会者的媒体流，所以，每个用户都可以动态改变自己本地的画面布局，比如放大、缩小等。如果不希望观看某个人的视频画面，还可以不订阅这个人的媒体流。
结论
本文介绍了 Mesh、MCU、SFU 三种 WebRTC 服务架构的基本情况，也论述了它们各自的优缺点。尽管它们都有各种不足，但是它们对 WebRTC 实时音视频通讯技术的发展都起到了一定的推动作用。Mesh、MCU、SFU 三种服务架构有非常多值得我们学习和借鉴的地方。现在很多先进的服务器方案不是单单使用某一种服务架构，更多的是搭配使用。比如我们自己的 WebRTC 流媒体服务器就是使用了 MCU+SFU 的混合模式。所以说，在技术选型时没有绝对的，我们需要根据自己具体的业务场景和技术储备情况挑选最合适的方案。希望本文介绍的内容可以帮到大家，感谢！
作者简介：😄大家好，我是 Data-Mining（liuzhen007），是一位典型的音视频技术爱好者，前后就职于传统广电巨头和音视频互联网公司，具有丰富的音视频直播和点播相关经验，对 WebRTC、FFmpeg 和 Electron 有非常深入的了解，😄公众号：玩转音视频。同时也是 CSDN 博客专家、华为云享专家（共创编辑）、InfoQ 签约作者，欢迎关注我分享更多干货！😄
