WebRTC之旅--概念篇(二)Mesh/MCU/SFU

发表于 分类于 阅读次数： Valine：

前言

WebRTC服务端常见的三种架构模式，Mesh，MCU，SFU

Mesh

这种方案比较简单，但是也极少使用，简单的说就是端到端进行通讯的时候进行直接连接，中间无服务器对数据的进行转发，两个端或者多个端之间通过NAT打洞获得到对方的IP及端口号后进行直接连接，如下图：
mesh_image

优点：

  • 无服务器进行数据中转，STUN/TURN 只进行NAT穿透
  • 这种架构模式无需开发媒体中转服务器，所以无论开发成本还是服务器成本都比较低

缺点：

  • 使用Mesh架构时如果进行多人通讯的时候，其中任何一端都需要向会议中的每个端发送音视频数据，增加了客户端带宽要求，另外每个端都需要建立多个音视频流的解码器，对端性能要求比较高，低端及比较低端手机性能基本无法满足，同样带宽要求过高会引起卡顿等问题。

MCU

MCU（Multipoint Control Unit）是比较传统的中心化网络结构，音视频参会者只与MCU媒体服务器进行连接，只将音视频数据推送到MCU媒体服务器，MCU媒体服务器负责将所以参会者的视频进行混合，混合后生成包含所有参会者的视频流，将混合后的视频推送到其他参会者。如下图：
mcu_image
优点：

  • 使用MCU架构，参会者只需要推送一路音视频流到MCU媒体服务器，同样拉流也只有一路，与Mesh相比减轻了参会终端的带宽要求及性能消耗

缺点：

  • MCU架构中减轻的网络及性能消耗都转嫁到了MCU媒体服务器，MCU需要接收每一路音视频流，并且对音视频流进行转码，解码，混流，再重新编码，这个过程会增加服务器压力，也会造成延时，另外如果业务需要对视频画面进行不同布局的话，MCU也需要支持，实现起来比较麻烦。

SFU

SFU（Selective Forwarding Unit）架构相对来说是一种折中的方案，与MCU类似是一个中心化网络架构，但是相比MUC在SFU架构中服务器只进行媒体数据的转发，没有多余的编解码等动作，减轻了服务器的压力。
相较Mesh架构中客户端需要向每个参会者推送视频来说，SFU架构中客户端只需要一路上行到SFU，但是下行链路数不会减少。
sfu_image

优点：

  • SFU 只对媒体数据进行转发，没有经过多余的编解码及混流步骤，可以减少CPU消耗，不会产生过多的时间消耗增加延迟
  • SFU 架构比较灵活，可以在服务端进行按需数据转发，如推流端推送不同分辨率的视频流到SFU，拉流端根据实际带宽情况按需订阅不同分辨率的视频流（Simulcast）
  • SFU 是现在比较流行的架构，有很多开源框架可以使用，如Janus, Mediasoup等

总结

  • Mesh：真实场景使用很少
  • MCU：可以根据业务场景需要选择使用
  • SFU：目前比较流行，涉及多方通讯的场景基本都是使用SFU架构，SFU配合Simulcast，SVC可以提高音视频服务质量