代码改变世界
[登录 · 注册]
  • webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU
  • 问题:为什么要搞这么多架构?

    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的架构文章)

  • 上一篇:webrtc笔记(4): kurento 部署
    下一篇:webrtc笔记(2): 1对1实时视频/语音通讯原理概述
  • 【推广】 阿里云小站-上云优惠聚集地(新老客户同享)更有每天限时秒杀!
    【推广】 云服务器低至0.95折 1核2G ECS云服务器8.1元/月
    【推广】 阿里云老用户升级四重礼遇享6.5折限时折扣!
  • 原文:https://www.cnblogs.com/yjmyzz/p/webrtc-multiparty-call-architecture.html
走看看 - 开发者的网上家园