【MediaSoup---初级篇】（三）各流媒体服务器的比较

多人音视频架构

Mesh方案

多对多大多进行P2P，在国内P2P直连穿越会出现很大问题。

MCU方案

客户端连接后，对应每个终端都有一个模块进项上传。再将音视频进行拆分解码。进行混屏，压缩编码分别推动给每个终端。

SFU方案

sfu不进行编解码，只是进行转发。只对订阅的终端进行转发。

1V1的通信模型

Licode架构

缺点：太复杂

客户端：

Client APP作为信令通信模块；

发送信令后创建一个房间，先进入SeverApp然后将消息传给Nuve,将消息插入到MQ的消息队列。

Eriza.js:

对房间逻辑配置信令进行传输

WebRTC:

进行通信

服务端：

ErzoController逻辑处理：(服务集)

roomcontroller从MQ中取出消息创建房间。

ErizoAgent:(分布服务)

进行资源分发

Janus SFU架构

缺点：没有使用异步IO事件处理，线程模型主要使用Jlib

1.先访问服务端的HTTPS的服务获取到浏览器要执行的代码。（获取发布的客户端程序）

2.选择任意一种方式进行信令通信。(信令处理层)

3.Janus使用插件式服务。例如常见的插件（业务层）

VideoRoom 多人教育实时互动

VideoCall 两个人之间的实时通信

Streaming 通过ffmpeg 等其他进行推流至此

SIP 可以通过网络与传统数字电话进行通信

TextRoom 文本聊天室

RecordPlay  音视频录制与播放

4.Janus Core是核心层,控制整个传输，协议实现等等。

Medooze架构

缺点：有卡顿现象

Mediosoup架构

与Medooze的区别是媒体音视频部分传输实在独立的C++程序中，Nodejs与它利用管道通信。使用Epoll异步处理模型，使用多进程模型，每个CPU绑定一个进程。只提供一个底层媒体库，业务逻辑需要自行实现。

总结

场景1：

性能最好的  ，Mediosoup架构。

场景2：

完备性（应用，负载等）：Licode架构。

场景3：

性能，完备性兼容：Janus SFU架构。

场景4：

各方面功能性能都比较兼容的：Medooze架构。