【流媒体服务器Mediasoup】多人音视频架构、流媒体的比较、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流媒体服务器架构和特点
相关介绍 :
Licode—基于webrtc的SFU/MCU实现
Licode整体框架还是非常不错，但是过于重量型。包括很多功能很完善，但是对于一些定制一些业务需求的时候相对于会比较困难一些。
Janus流媒体服务器的架构及特点
相关介绍 :
Janus架构以及基本开发
janus通过插件的形式完成各个业务，整个框架也是非常不错的，从整个模型来讲，可以满足一些定制需求的修改。
上面这张图是 Janus 的整体架构图。在这张图中我们可以看到， 从大的方面说 Janus 由 Janus CORE、Janus Plugin 以及信令接口三部分组成。
- 信令接口，Janus 支持的信令协议比较多，如 HTTP、WebSocket、RabbitMQ 等。这些信令协议使得 Janus 具有非常好的接入性。因为很多公司喜欢各种不同的协议，如有的喜欢 websocket，有的喜欢http，proto等。因此 Janus 在信令接入方面具有很大的优势。
- Janus Plugin，Janus 的业务管理是按照 Plugin 的方式管理的，因此你可以在Janus中根据自己的需要实现自己的业务插件。实际上，对于一般性的需求 Janus 已经相关的插件。如：
- VideoRoom，用于多人音视频互动，像音视频会议，在线教育都可以通过该插件来实现。
- VideoCall，用于 1:1 的音视频通信。
- SIP，用于与传统电话设备对接。
- Streaming，用于广播，也就是我们通常所说的一人共享，多人观看的直播模式。
- TextRoom，它是一个聊天室，通过它可以进行文本聊天。
- RecordPlay，用于录制和回放。
- Janus Core 是Janus的核心，其作用是处理流的转发，各种协议的接入。以浏览器为例，要想让浏览器接入到 WebRTC 流媒体服务器上，那流媒体服务器必须要支持 STUN、DTLS、SRTP、ICE 等协议。而 Janus Core 就是专门做这事儿的。
Janus 是由 C语言开发的，因此它的性能非常优秀。要说不足的话，janus 底层没有使用 epoll 这类异步I/O事件处理机制，这应该说是它的一大缺陷；另外，Janus还使用 glib 库，由于 glib 库对于国内的很多开发同学来说用的比较少，所以会有一定的学习成本。
整体上看，Janus采用了插件的架构设计方案。这种方案非常适合于有多种业务模型或业务经常发生变化的公司或项目。另外 Janus 支持多种消息传输协议，这对于开发人员来说具有极大的吸引力。
Medooze流媒体服务器架构及特点
Medooze 的整体架构与 Mediasoup 类似，不过它的信令处理、业务管理以及媒体数据的转发功能都是放在 Nodejs下进行统一管理的。实际上，这样的管理方式也不会对性能造成什么影响，因为重的媒体流的转发工作仍然是使用的 C++ 在 Nodejs 底层实现的。
Medooze 的业务功能要比 Mediasoup 强大，像服务端录制、推流这些 Mediasoup 没有的功能它都支持。但它性能没有 Mediasoup 做的极致，在Medooze的底层使用的poll来处理I/O事件，poll与epoll性能相差距大。除此之外，Medooze的业务逻辑也没有Mediasoup简洁；另外与 Janus 相比，它的业务管理不如 Janus 灵活，Janus 的插件管理方式显然要优于 Medooze 和 mediasoup。
但总的来说，Medooze还是一款非常不错的 WebRTC 流媒体服务器。虽然有一些小的暇疵，但还是非常不错的一款流媒体服务器。
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。