WebRTC服务端架构

一、为什么需要流媒体服务？

众所周知webrtc原生的网络连接方式是P2P通信模型，即通信双方是对等的。如下图左侧图，通信双方直接进行音视频传输，中间的服务器仅做两端的信令交互。
将这种P2P方式扩展到多人通信也就是所谓的mesh架构，将会演变成下图右侧，这种去中心化架构在人数少（比如只有3、4个人）的时候还是有一定的优势：1、不需要额外的服务器 2、音视频直接传输质量和速度都很好。
但是随着人数的增加，网络拓扑将变得复杂，每个端点的网络带宽负担也会增加。这也就是为什么多人通话需要流媒体服务器的根本原因。

二、有哪些流媒体服务器架构？

本文我们将研究旨在支持浏览器中低延迟视频流的3种拓扑的优缺点：mesh、SFU、MCU。

2.1 mesh点对点（P2P）

P2P是WebRTC应用程序中最容易设置和最具成本效益的体系结构；它也是最不可扩展的体系结构。在网格拓扑中，两个或多个对等方（客户端）直接交谈，或者在防火墙的对面时，通过向它们转发音频、视频和数据流的TURN服务器交谈。

P2P应用程序可能是资源密集型的，因为编码和解码流的负担被卸载到每个对等机，这就是为什么当您只有少数并发用户时，它们性能最佳。虽然您可以通过配置P2P网格网络实现一定程度的可伸缩性，但最终还是会得到一个资源密集型和低效的应用程序。从好的方面来说，网格提供了最好的端到端加密，因为它不依赖于集中服务器对流进行编码/解码。
点对点流：n-1上游和n-1下游
优势

使用基本的WebRTC实现轻松设置
更好的隐私
成本效益高，因为它不需要媒体服务器
缺点

只能连接少数参与者，而不会显著降低流媒体质量
CPU密集型，因为流的处理被卸载到每个对等机

2.2 选择性转发单元SFU

SFU可能是现代WebRTC应用程序中最受欢迎的架构。简而言之，SFU是一个直通路由系统，旨在将一些流处理从客户端卸载到服务器。每个参与者将加密的媒体流发送到一次集中服务器，然后集中服务器将这些流转发给其他参与者，而无需进一步处理。虽然SFU比网格拓扑更高效——例如，在与n个参与者的通话中，每个客户端只有一个上游，而不是n-1上游——但客户端仍然需要解码和渲染多个（n-1）下游，随着参与者数量的增加，这将消耗客户端资源，降低视频质量，从而限制可伸缩性。
SFU流媒体：1个上游和n-1下游

优势

与P2P网格相比，上传带宽要求更低
流是分开的，因此每个流都可以单独呈现——允许完全控制客户端的流布局
缺点

可伸缩性有限
随着一些CPU负载转移到服务器，运营成本更高

2.3 多点会议单元（MCU）

多年来，MCU一直是大集团会议系统的支柱。这并不奇怪，因为它能够通过将大部分CPU密集型流处理从客户端卸载到集中服务器来提供稳定、低带宽的音频/视频流。

在MCU拓扑中，每个客户端连接到集中的MCU服务器，该服务器解码、重新缩放和混合所有传入的流到单个新流中，然后对其进行编码并将其发送给所有客户端。虽然客户端的带宽友好且CPU密集度较低——客户端不必处理多个流，而只需要解码和渲染一个流——但服务器端的MCU解决方案相当昂贵。将多个音频和视频流转码到单个流中，然后以多个分辨率实时编码，CPU非常密集，连接到服务器的客户端越多，其CPU要求就越高。

然而，MCU的最大好处之一是它易于与外部（遗留）业务系统集成，因为它将所有传入的流合并到一个易于消费的出库流中。

MCU流媒体

优势

带宽友好
复合输出简化了与外部服务的集成
当您需要合并许多流时，您唯一的选择（除非您使用XDN方法，我们将在下讨论）
缺点

CPU密集型；流越多，服务器就越大
由于集中处理，单一故障点风险
由于服务器上的计算负载，运营成本高昂

参考：
WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信架构 - 地铁程序员 - 博客园
webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU - 菩提树下的杨过 - 博客园
3 Key Approaches for Scaling WebRTC: SFU, MCU, and XDN