网站首页设计分析,企业信息系统查询系统官网江苏,外贸推广系统,现在互联网有什么平台可以做目录 三种网络场景介绍
【Mesh】
【MCU】(MultiPoint Control Unit)
【SFU】(Selective Forwarding Unit)
三种网络架构的优缺点
Mesh架构
MCU架构(MultiPoint Control Unit)
SFU架构(Selective Forwarding Unit)
总结
参考文章 三种网络场景介绍 【Mesh】
Mesh架构…目录 三种网络场景介绍
【Mesh】
【MCU】(MultiPoint Control Unit)
【SFU】(Selective Forwarding Unit)
三种网络架构的优缺点
Mesh架构
MCU架构(MultiPoint Control Unit)
SFU架构(Selective Forwarding Unit)
总结
参考文章 三种网络场景介绍 【Mesh】
Mesh架构需要所有参与连接的peer建立与所有其他peer的媒体连接。 该架构需要n-1个上下行以此带来的带宽消耗流量、编/解码消耗手机性能成线性增长。 该架构只能适用3-4个人的小型会议场景。
【MCU】(MultiPoint Control Unit)
所有本房间的peer将本地媒体流推到远程媒体服务器由媒体服务器进行混流然后再推到所有连接的peer端。 该架构的优点就是只需要1路上下行随着peer人数不断增加依然不会对用户造成带宽、手机性能影响。 该架构将压力转嫁到服务端由专用媒体服务器来完成混流转推等功能。
【SFU】(Selective Forwarding Unit)
相对于MCU来说SFU只做转发媒体服务器压力有限。与mesh架构相比只需要n-1个下行1个上行。 在大规模的场合该架构具有伸缩性。
三种网络架构的优缺点 Mesh架构
Mesh架构流量或带宽要求比较大Mesh架构是利用Webrtc对等连接在参与会议的各方之间开辟UDP通道也就是两两进行P2P连接把媒体流发给参与会议的各方同时从参与会议的其它方获取媒体流如上图四个参与方总共8个连接如果每个通道占用1M带宽那每个端需要把自己的流发给其它三个端也就是上行是3M带宽同时从其它3个端获取流也就是下行3M带宽这样每个端上下行总共6M带宽Mesh架构对端的能力要求也是比较高毕竟参与会议的各方的媒体流的编解码都是在端上面来处理的图上面的4个参与会议方那每个端的处理量就是4结合上面可以看出Mesh一个端能承受的同时开视频的人员更少Mesh架构不利于媒体的集中处理例如媒体的录制你如果不觉得带宽或者流量是问题再从端上传一份媒体到存储服务器那又另当别论又或者小哥哥小姐姐直播了一些不该直播的无法进行识别或处理了再者集成我大讯飞的翻译咋办不能没有我大讯飞的翻译啊当然端上做也是可以的但是毕竟端上算力是有限的但是Mesh实现起来技术难度是最小的实现起来最简单Mesh架构对服务器资源占用是最小的只需要一个ICE服务器用来实现P2P穿越就行了Mesh架构是真正的去中心化对服务器资源占用是最小的还有可以充分的利用了端上的算力边缘计算的时代已经来了节省不少成本
MCU架构(MultiPoint Control Unit)
MCU架构对服务器端压力比较大MCU架构需要一个中心化的MCU服务器编码、转码、解码、混合都在服务器端做 如上图MCU架构下的参会的4个端把自己的媒体流上缴到MCU服务器然后MCU服务器对4个媒体流解码后进行合并4个流合并成一个媒体流再发给4个参会人员因此服务器的压力特别大所以单台服务器能承受的参会人员特别少当然一些财大气粗的企业可以加服务器加高级的GPUMCU端上各种控制更加复杂 现在我和漂亮小姐姐聊天小姐姐是我日思夜想的我现在想把她的画面调大这个实现起来就很麻烦了因为下发的媒体流是合并的也就是一个视频流当然不是不可实现通过信令服务器下发一个重新合屏的信令我们还是可以看到清晰的小姐姐的画面的只是相对来讲实现更麻烦 又比如我希望参会的小姐姐们看到群里最靓的我那我对我自己上滤镜美白那可就麻烦了MCU架构占用带宽最小从前面的描述和从上图中我们可以看到4个参会人员每个人上交一份媒体流如果还是按照1M来算那上行每个端1M同时从服务器端获取一份混合过的媒体流还是按照1M算那每个端上下行总共就是2M结合上面所述MCU架构 一个端同时能承受更多的人开启视频
SFU架构(Selective Forwarding Unit)
SFU架构服务端压力相对较小SFU架构看似和MCU一样都有一个中心化的服务器但是SFU的服务器只负责转发媒体或者存储媒体不直接做编码、转码、解码、混合这些算力要求较高的工作SFU服务器接到RTP包后直接转发SFU架构占用带宽适中例如上图SUF架构参与会议的4个端每个端首先要把自己的流发给服务器所以每个端上行1M带宽同时从服务器获取转发过来的其它3个参会人员的媒体流也就是下行3M这样每个端上下行加一起就是4M所以它占用端上的带宽在Mesh架构和SFU之间这种适中的带宽占用在即将到来的5G时代你可以想象SFU架构对端和媒体流的控制更简单还是上面的场景我想仔细端详日思夜想的小姐姐将她的画面调大只需要在端上直接放大就行了另外整个会议中只让我成为最靓的仔进行美颜啥的实现起来也不算是啥问题了虽然对端的要求高但是现在手机或者电脑算力过剩啊边缘计算发挥到极致哈哈……为企业省钱
总结
互联网时代要求更个性化的体验美颜更个性化的控制等等更大的容积率也就是更多的用户同时在线总的来说SFU架构更适合互联网时代ZOOM会议和腾讯会议这两个比较出名的互联网会议系统都是SFU架构所以跟风一波后续深入的研究SFU架构 虽然SUF架构对端的算力要求比较高更多的计算放到了端上不过在视频会议或者直播的场景下面跟多的是一个大画面其它若干个小画面而且通过交互控制例如同时只显示若干个小画面滚动的时候动态的再获取其它的参会人员的视频生成小画面 SFU只负责转发流所以更高的并发同时它逻辑简单更容易的构建高负载架构
参考文章
一文带你了解webrtc基本原理动手实现1v1视频通话_go webrtc-CSDN博客 Webrtc音视频会议之Mesh/MCU/SFU三种架构_webrtc_千里授渔-即构开发者社区 (csdn.net)
