【流媒体服务器Mediasoup】多人音视频架构、流媒体的比较、mediasoup介绍 (一)

前言

WebRtc有两种含义，其一是Google开源的流媒体实时通讯客户端，主要运用于浏览器之间的实时通讯，当然也可以通过提取完成移动端，PC端的通讯;另外WebRtc也是一套规范，这套规范只对客户端做了定义，如客户端应该是一种什么行为，应该是一种什么样的流程，如何进行媒体协商，，如何进行通讯，这些是在规范中进行定义的。

相对于服务端来讲包括信令或者中继服务端并没有规范的定义，这个是由使用WebRtc各个厂商自己去定义的，对于多人实时互动的服务端也是没有规范的定义。那么实现多人实时互动通讯目前有3种比较流行的框架，具体请移至【多人音视频架构】阅读。

在了解完各个音视频架构过后，对比当前主流的流媒体服务器 - Licode、Janus、Medooze、Mediasoup。在后续博文中笔者会对MedouSoup进行详细的分析，后面会对这四种流媒体服务器进行比较，当然只是纯粹的比较不分好坏，具体还要根据各大厂商或者研发人员钟爱于哪一套有。比较流媒体服务器章节请移至【流媒体服务器的比较】阅读。

Mediasoup官网：https://mediasoup.org
Mediasoup官方演示：https://v3demo.mediasoup.org
Demo git地址及部署说明：https://github.com/versatica/mediasoup-demo

多人音视频架构

Mesh方案

由WebRtc客户端演变过来的，那么对于Goggle主要实现P2P或者说端与端的通讯，而且是在浏览器之间，如果想让多人进行通讯，那么就是是多个一对一的通信，比如ABC三者通讯，那么A和B，C相连，B也要和A，C相连，C也是如此，形成一个交叉的连接，这样就可以实现多方的通讯。

但其存在一些弊端，弊端在于如果参与人数过多，每个端都要有很多链接，如果网络无法保障的话那么会出现很大的问题或者带宽有限，链接过多带宽会不足，目前商用暂时基本不用Mesh方案。

MCU（Multipoint Conferencing Unit）方案

其是由硬件演变而来的,由于硬件MCU成本过高那么就想着通过软件方式去实现，于是有了现在MCU方案，,MCU可以提供更多扩展性的功能实现，且降低了带宽。

当然其也存在一些弊端，主要有2个弊端，其一是当有多个用户通过MCU进行实时互动，首先要多个音视频进行混合，好处在于把整个带宽降低了，每个人都只发一路，但服务端CPU编解码压力过大，如果会议越多会导致CPU过渡负载，因此支持的人数或者会议室极其有限。其次是当混合完的音视频数据发送给客户端，客户端没办法控制一些数据的参数如视频的大小位置等。

SFU (Selective Forwarding Unit)方案

纯粹的数据转发，那么转发到对端之后可以接收到多人的数据，对数据进行做各种控制或者操作但是带了一个坏处，相对于MCU来说数据是多路流多来，接收端来说接收的流也多了，如果传输的音视频是采样率大或者高清视频，那么客户端与服务端之间带宽不够的话会导致大量的丢包并影响一些音视频的质量；但SFU也有一系列的配套方案来解决这个问题，如降码率、SVC分层方式（核心层，拓展层，边缘层）根据带宽来传输不同层的数据。

随着网络带宽不断得加强，设置的质量越来越高，因此相对于SFU的优劣势来说，SFU更受欢迎。

流媒体服务器的比较

这里只针对MediaSoup流媒体服务器详解，其余看个大体结构并简单说明

Licode流媒体服务器架构和特点

Mediasoup流媒体服务器架构及特点

Mediasoup也是一个SFU的架构模型，他与Medooze非常的类似，都是通过nodeJs来实现信令的服务，媒体部分的处理音频视频流实际是在C++程序处理的，node和C++通过管道进行通讯。其客户端机制基本一样。对于MediaSoup来说它的nodeJs只起到两个作用，其一是www服务也就是执行客户端的启动代码，它在www服务上，其次是客户端和服务端的https连接，通过连接来达到信令的通讯。

Nodejs，负责 Mediasoup 的信令接收与业务管理。如创建/消毁房间，创建/关闭生产者，创建/关闭消费者等。
Mediasoup(C++)，这是一个单独的程序，但该程序无法直接启动。因为它在内部会判断是否是 Nodejs 将它启动起来了。只有在Nodejs 的 Mediasoup 管理模块加载之后，再将 Mediasoup(C++)启动起来，这样它才能正常工作。

Mediasoup其实底层是一个库，其实可以根据自身的需求去开发，当然官方也提供了一个demo，可以实现多人的实时互动，如果要实现商用的多人实时互动，其实是需要自己去重构这部分的逻辑。通过底层流媒体库来搭建自己想要的服务器。

从整个架构模型来讲，设计得合理，整体性能相对来说比较高,底层C++更是使用使用libuv处理I/O时间，而且它是一个库，可以容易和自己的业务模型相结合，即不轻量级也不重量级。但整体的应用来说不及licode。