一：多人互动架构方案（一）WebRTC回顾，两层含义：1.WebRTC是google开源的流媒体客户端，可以进行实时通讯，主要应用于浏览器之间进行实时通讯，也可以单独编译在自己的应用中2.WebRTC也是一套规范，只对客户端做了定义，如何进行媒体协商、通信流程...;对于服务端，比如信令服务端、中继服务，并没有在WebRTC中定义，由厂商定义;对于多人互动方案也没有定义（二）3种框架进行多人互动Mesh方案：从WebRTC客户端演变过来，多人互动--->变为多个1V1通讯，会导致网络连接过多，任一个客户端都需要与其他客户进行连接，带宽占用过多，不适用商业MCU方案：硬件演变为软件，包含一个中心服务器。中心服务器会对多路视频进行混屏（解码、编码），降低带宽，占CPU，支持的同时在线人数有限。此外，客户端无法对其进行控制，灵活性较差。SFU方案：简单、主流，不对数据处理，当服务器收到数据后直接进行数据转发，只进行转发。每个客户端都会收到其他客户端通过服务器转发过来的数据，但是相对于Mesh，建立的连接只和服务器个数有关。并且相对于MCU，客户端对于接受的其他各个客户端的数据可以进行灵活控制。缺点：相对有MCU传输的数据更多，造成客户端到服务端的带宽占用过高，带宽不够时会造成丢包，服务质量无法保证！改进方法：1.降低码流（上传时/发送时）2.根据H264中SVC分层方式,将一路视频分为核心层、扩展层、边缘层，一层比一层清晰（增量累加），当带宽足够时可以全部下发给客户端，不够时可以选择传输核心层或者核心层+扩展层从而降低下行带宽数量，缓解质量不足问题二： 架构模型详解（一）Mesh架构模型详解1. 1V1通讯模型WebRTC学习（八）1V1音视频实时互动直播系统WebRTC学习（八）1V1音视频实时互动直播系统（2）2. Mesh通讯模型（未画出信令服务器）Mesh方案，不依赖于服务器进行数据中转（不会走TURN），是各个端之间建立连接。内部同1V1进行设备检测、数据编解码、媒体协商、建立连接、发送数据。唯一区别就是1V1可以通过TURN转发。Mesh一般使用P2P直连，不会经过TURN服务器转发，太复杂，不易管理。但是国内需要考虑穿透率，所以该方案一般用在局域网中进行使用和学习！（二）MCU架构模型详解在MCU中心服务器中，存在多个Room，这里只选取左侧的进行讲解：1.对于每一个客户端C1、C2...C4，进入房间中，在房间中（服务器端）都有对应的模块进行连接，客户端进行通讯的数据，比如音频数据、视频数据都通过该连接传递给服务端。2.服务端模块收到数据后，会对数据进行解复用，将音视频数据拆解，将音频放入音频处理模块，将视频放入视频处理模块，实现对数据解码，然后进行混屏，之后进行编码压缩。返回压缩数据（一路流）到各个客户端。缺点：服务端无法支持大量客户端，最多支持几十路流处理;客户端获取的数据固定（由服务端处理后的），无法进行编辑（拉伸、改变清晰度）

音视频流媒体高级开发知识点学习视频点击 正在跳转 获取。知识点包括有FFmpeg/WebRTC/RTMP/RTSP/HLS/播放器-音视频流媒体高级开发。

音视频高级开发系统学习视频：【免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发-学习视频教程-腾讯课堂

（三）SFU架构模型详解（主流）与MCU类似，只是对于SFU而言，不对媒体流进行解码、混屏、编码;而是直接进行转发！！对于终端，接受的数据是原始分辨率，可以对数据进行处理，比MCU更加灵活。

缺点：对于接受端的下行带宽有考验，如果带宽不允许，可能导致服务质量不足

解决方案：1.simulcast分层，可以设置成两层、三层或是四层甚至更高层次的分辨率，比如最高层是640X360的分辨率，下一层是240X120的分辨率，再一层是80X60的分辨率。总之就是按比例的缩放。在上传的时候将三层同时上传，下发的时候SFU会判断整个带宽能否承载下行的数据，如果不能承载便选择低一个层次的分辨率看能否承载，若不能承载，再选择更低层次的，依次下去…2.根据H264中SVC分层方式,将一路视频分为核心层、扩展层、边缘层，一层比一层清晰（增量累加，各层之间相互依赖），当带宽足够时可以全部下发给客户端，不够时可以选择传输核心层或者核心层+扩展层从而降低下行带宽数量，缓解质量不足问题。simulcast和SVC不能混用。这两个相比，simulcast的操作更简单一些，实用性更高一些，国内的声网 便使用的这种方式。SVC更复杂一些，国外的zoom 、思科 的解决方案便采用的这种方式。三：流媒体服务器架构和特点已知的多方通信框架有：Mesh MCU SFU 三种。

其中SFU是目前最优的一种多方通信架构方案，而且这种方案目前已经有比较流行的开源项目：Licode Janus-gateway Mediasoup Medooze

下面简单的对这4种方案进行分析：

（一）Licode架构

Licode 既可以用作SFU 类型的流媒体服务器，也可以用作 MCU 类型的流媒体服务器。一般情况下，它都被用于SFU类型的流媒体服务器。

Licode 不仅仅是一个流媒体通信服务器，而且还是一个包括了媒体通信层、业务层、用户管理等功能的完整系统，并且该系统还支持分布式部署。

Licode 是由 C++ 和 Node.js 语言实现。其中，媒体通信部分由 C++ 语言实现，而信令控制、用户管理、房间管理用 Node.js 实现。它的源码地址为： 。

下面这张图是 Licode 的整体架构图：

如上图所示，从大的框架上来看，Licode框架被分为2部分：服务端和客户端

1.客户端讲解（简单）

客户端被分为了3个部分：ClientAPP（信令通讯，比如房间操作、媒体协商...）、Eriza.js（对房间相应逻辑进行控制）、WebRTC（抓取音视频数据分享和展示）

2.服务端讲解通过上图可以看出，Licode 从功能层面来讲分成三部分，即 Nuve 、ErizoController 和 ErizoAgent 三部分，它们之间通过消息队列进行通信。Nuve 是一个 Web 服务，用于管理用户、房间、产生 token 以及房间的均衡负载等相关工作。它使用 MongoDB 存储房间和 token 信息，但不存储用户信息。ErizoController，用于管理控制，信令和非音视频数据都通过它接收。它通过消息队列与 Nuve 进行通信，也就是说 Nuve 可以通过消息队列对 ErizoController 进行控制。ErizoAgent，用于音视频流媒体数据的传输，可以分布式布署。ErizoAgent 与 ErizoController 的通信也是通过消息队列，信令消息通过 ErizoController 接收到后，再通过消息队列发给 ErizoAgent，从而实现对 ErizoAgent 进行控制。

通过上面的描述，可以知道 Licode 不仅仅是一个 SFU 流媒体服务器，它还包括了与流媒体相关的业务管理系统、信令系统、流媒体服务器以及客户端 SDK 等等，可以说它是一个比较完善的产品。

Licode缺点：

在 Linux 下目前只支持 Ubuntu 14.04 版本，在其他版本上很难编译通过。（现在不清楚，毕竟已经过去一段时间）Licode 不仅包括了 SFU，而且包括了 MCU，所以它的代码结构比较重，学习和掌握它要花不少的时间。Licode 的性能一般， 如果你把流媒体服务器的性能排在第一位的话，那么 Licode 就不是特别理想的 SFU 流媒体服务器了。（二）Janus SFU架构

Janus 是一个非常有名的 WebRTC 流媒体服务器，它是以 Linux 风格编写的服务程序，采用 C 语言实现，支持 Linux/MacOS 下编译、部署，但不支持 Windows 环境。

它是一个开源项目，其源码的编译、安装非常简单

Janus 的架构组成：

流程如Medooze架构图流程一致！！（后面）

上面这张图是 Janus 的整体架构图。Janus 可以被分为以下三部分： Janus CORE、Janus Plugin 以及信令接口组成

1.信令接口，Janus 支持的信令协议比较多，如 HTTP、WebSocket、RabbitMQ 等。这些信令协议使得 Janus 具有非常好的接入性。因为很多公司喜欢各种不同的协议，如有的喜欢 websocket，有的喜欢http，proto等。因此 Janus 在信令接入方面具有很大的优势。

2.Janus Plugin，Janus 的业务管理是按照 Plugin 的方式管理的，因此你可以在Janus中根据自己的需要实现自己的业务插件。实际上，对于一般性的需求 Janus 已经相关的插件。如：

SIP：用于与传统电话设备对接，这个插件使得 Janus 成了 SIP 用户的代理，从而容许 WebRTC 终端在 SIP 服务器（如 Asterisk）上注册，并向 SIP 服务器发送或接收音视频流。TextRoom：该插件使用 DataChannel 实现了一个文本聊天室应用。Streaming：用于广播，也就是我们通常所说的一人共享，多人观看的直播模式;它容许 WebRTC 终端观看 / 收听由其余工具生成的预先录制的文件或媒体。VideoRoom：它实现了视频会议的 SFU 服务，实际就是一个音 / 视频路由器，用于多人音视频互动，像音视频会议，在线教育都可以通过该插件来实现。VideoCall：这是一个简单的视频呼叫的应用，容许两个 WebRTC 终端相互通讯，用于 1:1 的音视频通信。它与 WebRTC 官网的例子类似（），不一样点是这个插件要通过服务端进行音视频流中转，而 WebRTC 官网的例子走的是 P2P 直连。RecordPlay：该插件有两个功能，一是将发送给 WebRTC 的数据录制下来，二是能够经过 WebRTC 进行回放。

3.Janus Core 是Janus的核心，其作用是处理流的转发，各种协议的接入。以浏览器为例，要想让浏览器接入到 WebRTC 流媒体服务器上，那流媒体服务器必须要支持 STUN、DTLS、SRTP、ICE 等协议。而 Janus Core 就是专门做这事儿的。

Janus 的整体架构：Janus 分为两层，即应用层和传输层插件层又称为应用层，每一个应用都是一个插件，能够根据用户的须要动态地加载或卸载掉某个应用。插件式架构方案是很是棒的一种设计方案，灵活、易扩展、容错性强，尤为适用于业务比较复杂的业务，但缺点是实现复杂，成本比较高。传输层包括媒体数据传输和信令传输。媒体数据传输层主要实现了 WebRTC 中须要有流媒体协议及其相关协议，如 DTLS 协议、ICE 协议、SDP 协议、RTP 协议、SRTP 协议、SCTP 协议等。信令传输层用于处理 Janus 的各类信令，它支持的传输协议包括 HTTP/HTTPS、WebSocket/WebSockets、NanoMsg、MQTT、PfUnix、RabbitMQ。不过须要注意的是，有些协议是能够经过编译选项来控制是否安装的，也就是说这些协议并非默认所有安装的。另外，Janus 全部信令的格式都是采用 Json 格式。

Janus 总体架构采用了插件的方案，这种架构方案很是优秀，用户能够根据本身的须要很是方便地在上面编写本身的应用程序。并且它目前支持的功能很是多，好比支持 SIP、 RTSP、音视频文件播放、录制等等，因此在与其余系统的融合性上有很是大的优点。另外，它底层的代码是由 C 语言编写的，性能也很是强劲。Janus 的开发、部署手册也很是完善，所以它是一个很是棒的开源项目。因此，它的架构设计比较复杂，对于初学者来讲难度较大。

（三）Medooze架构

Medooze 的整体架构与 Mediasoup 类似，不过它的信令处理、业务管理以及媒体数据的转发功能都是放在 Nodejs下进行统一管理的。实际上，这样的管理方式也不会对性能造成什么影响，因为重的媒体流的转发工作仍然是使用的 C++ 在 Nodejs 底层实现的。

Medooze 是一款综合流媒体服务器，它不仅支持 WebRTC 协议栈，还支持很多其他协议，如 RTP、RTMP 等。其源码地址为： 。

Medooze架构流程图：Medooze架构模型如图中所示：使用NodeJs实现整个服务（信令交互），在NodeJs下面使用MediaServer C++作为底层服务器进行使用（实现媒体流传输）

1.浏览器从服务器获取客户端代码，通过V8引擎，启动底层WebRTC2.浏览器与服务端的MediaServer JS进行信令交互、房间操作、媒体协商3.数据传输WebRTC到MediaServer C++

多客户端流程一致！！！

Medooze整体架构图：Medooze 的核心层：

从大的方面来说，Medooze 支持 RTP/RTCP、SRTP/SRCP 等相关协议，从而能够实现与 WebRTC 终端进行互联。除此以外，Medooze 还能够接入 RTP 流、RTMP 流等，所以你可使用 GStreamer/FFmpeg 向 Medooze 推流，这样进入到同一个房间的其余 WebRTC 终端就能够看到 / 听到由 GStream/FFmpeg 推送上来的音视频流了。另外，Medooze 还支持录制功能，即上图中的 Recorder 模块的做用，能够经过它将房间内的音视频流录制下来，以便后期回放。为了提升多方通讯的质量，Medooze 在音视频的内容上以及网络传输的质量上都作了大量优化。

是经过 Node.js 实现的，Medooze 经过 Node.js 对外提供了完整的控制逻辑操做相关的 API，经过这些 API 你能够很容易的控制 Medooze 的行为了。 

Medooze 的业务功能要比 Mediasoup 强大，像服务端录制、推流这些 Mediasoup 没有的功能它都支持。但它性能没有 Mediasoup 做的极致，在Medooze的底层使用的poll来处理I/O事件，poll与epoll性能相差距大。除此之外，Medooze的业务逻辑也没有Mediasoup简洁；另外与 Janus 相比，它的业务管理不如 Janus 灵活，Janus 的插件管理方式显然要优于 Medooze 和 mediasoup。

但总的来说，Medooze还是一款非常不错的 WebRTC 流媒体服务器。虽然有一些小的暇疵，但还是非常不错的一款流媒体服务器。

（四）Mediasoup架构

Mediasoup 是推出时间不长的 WebRTC 流媒体服务器开源库，其地址为： 。

下图是Mediasoup整体架构图:流程如Medooze一致（前面）！

通过该图我们可以知道 Mediasoup 流媒体服务器是由 Nodejs 和 Mediasoup(C++) 两部分组成。

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

在众多的 WebRTC 流媒体服务器中，Mediasoup 可以说是性能最优秀的WebRTC流媒体服务器。它使用 C++ 作为开发语言，底层使用 libuv 处理 I/O 事件。

有很多人对 Nodejs 比较诟病，认为 Nodejs 提拱不了高性能的流媒体服务器。

实际上，如果按照传输的 Nodejs 应用开发出的流媒体服务器肯定是不能胜任这项工作的。但对于 Mediasoup 来讲，它只不过使用 Nodejs 做 信令处理 及 业务的管理 工作，所以它的负担并不重。对性能要求高的是媒体数据流的转发工作，而这部分工作是由 Mediasoup(C++)部分实现的。 

比如说你的服务器是个 8 核的CPU，那么在业务层你就该启动 8 个Mediasoup进程。通过这种方式来达到对 CPU 的充分利用。

Mediasoup中的每个进程称为一个 Worker, 你也可以把它理解为一个节点，在每个 Worker 中可以有多个 Router。

对于 Router，你站在不同的解度可以有不同的理解。如果你占在应用层的角度，你可以把它理解为一个房间；如果你站在数据流转的角度，可以把它理解为一个路由器，数据通过 路由器 转发给目标用户。

大的绿色箭头下面，有灰色的Transport字体，分为三种类型，即 WebRtcTransport、PlainRtpTransport 和 PipeTransport。

WebRtcTransport 用于与 WebRTC 类型的客户端进行链接，如浏览器。PlainRtpTransport 用于与传统的 RTP 类型的客户端链接，经过该 Transport 能够播放多媒体文件、FFmpeg 的推流等。PipeTransport 用于 Router 之间的链接，也就是一个房间中的音视频流经过 PipeTransport 传到另外一个房间。

在每一个 Transport （每一个用户）中能够包括多个 Producer 和 Consumer。

Producer 表示媒体流的共享者，它又分为两种类型，即音频的共享者和视频的共享者。Consumer 表示媒体流的消费者，它也分为两种类型，即音频的消费者和视频的消费者。

Mediasoup 的实现逻辑很是清晰，它不关心上层应用该如何作，只关心底层数据的传输，并将它作到极致。

（五）如何选择SFU（选择合适的）实现语言：

1.Meooze、Mediasoup、Licode 这三个流媒体服务器的媒体通讯部分都是由 C++ 实现的，而控制逻辑是经过 Node.js 实现，所以若是你是 C++ 开发人员，且有 JavaScript 技术背景，那么你就应该在这三种流媒体服务器之间选择，由于这样更容易入门。

2.而 Janus-gateway 是彻底经过 C 语言实现的，服务部署是传统的 Linux 风格，所以若是你是 Linux/C 开发者，则应该选择 Janus 做为你的流媒体服务器。

系统特色：

1.像 Licode 是一个完整的系统，支持分布式集群部署，因此系统相对复杂，学习周期要长一些。它能够直接布署在生产环境，可是二次开发的灵活性不够。

2.Janus-gateway 是一个独立的服务，支持的信令协议很丰富，并且支持插件开发，易扩展，对于 Linux/C 背景的开发者是很不错的选择。

3.Medooze 和 Mediasoup 都是流媒体服务器库，对于须要将流媒体服务器集成到本身产品中的开发者来讲，应该选择它们。

性能特色：

1.Licode、Meooze、Mediasoup、Janus-gateway 单台服务均可以支持 500 方参会人，因此它们的性能都仍是不错的。

2.相对来讲，Licode 的性能与其余流媒体服务器相比要低一些；

3.Medooze 因为没有使用 epoll 来处理异步 IO 事件，因此性能也受到一些影响。

不过总的来讲，它们在 500 方的容量下，视频质量均可以获得很好的保证，延迟在 100ms 左右。