19. 各流媒体服务器对比

WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信架构

WebRTC 本身提供的是 1 对 1 的通信模型，在 STUN/TURN 的辅助下，如果能实现 NAT 穿越，那么两个浏览器是可以直接进行媒体数据交换的；如果不能实现 NAT 穿越，那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看，Google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。

如果你想要通过 WebRTC 实现多对多通信，该如何做呢？
其实，基于 WebRTC 的多对多实时通信的开源项目也有很多，综合来看，多方通信架构无外乎以下三种方案。

• Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
• MCU（Multipoint Conferencing Unit）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
• SFU（Selective Forwarding Unit）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

多人音视频架构

1 对 1 通信

在多对多架构模型之前，咱们得先回顾一下 WebRTC 1 对 1 通信的模型，因为只有在 1 对 1 通信模型非常清楚的情况下，我们才能知道多对多通信模型的复杂度到底体现在哪儿。
在 1 对 1 通信中，WebRTC 首先尝试两个终端之间是否可以通过 P2P 直接进行通信，如果无法直接通信的话，则会通过 STUN/TURN 服务器进行中转，如下图：

WebRTC 1 对 1 音视频实时通话示意图
目前咱对上图已经非常熟悉了。实际上，1 对 1 通信模型设计的主要目标是尽量让两个终端进行直联，这样即可以节省服务器的资源，又可以提高音视频的服务质量。

如果端与端之间可以直接通信，那么上图中的 STUN/TURN 服务器的作用就只是用于各终端收集 reflx 类型的 Candidate 。而如果端与端之间无法直接进行通信的话，那么 STUN/TURN 服务器就变成了中继服务器，可以利用它进行端与端之间数据的中转。

Mesh

1 对 1 通信模型下，两个终端可以互相连接，那么我们是否可以让多个终端互相连接起来，从而实现多人通信呢？
理论上这是完全可行的。Mesh 方案的结构如下图所示：

Mesh 方案架构图

在上图中，C1、C2、C3、C4 分别表示 4 个浏览器，它们之间两两相连，同时还分别与 STUN/TURN 服务器进行连接（此时的 STUN/TURN 服务器不能进行数据中转，否则情况会变得非常复杂），这样就形成了一个网格拓扑结构。
当某个浏览器想要共享它的音视频流时，它会将共享的媒体流分别发送给其他 3 个浏览器，这样就实现了多人通信。
这种结构的优势有：

• 不需要服务器中转数据，STUN/TUTN 只是负责 NAT 穿越，这样利用现有 WebRTC 通信模型就可以实现，而不需要开发媒体服务器。
• 充分利用了客户端的带宽资源。
• 节省了服务器资源，因为服务器带宽往往是专线，价格昂贵，所以这种方案可以很好地控制成本。

当然，有优势自然也有不足之处，主要表现在：

• 共享端共享媒体流的时候，需要给每一个参与人都转发一份媒体流，这样对上行带宽的占用很大。参与人越多，占用的带宽就越大。除此之外，对 CPU、Memory 等资源也是极大的考验。一般来说，客户端的机器资源、带宽资源往往是有限的，资源占用和参与人数是线性相关的。这样导致多人通信的规模非常有限，通过实践来看，这种方案在超过 4 个人时，就会有非常大的问题。
• 另一方面，在多人通信时，如果有部分人不能实现 NAT 穿越，但还想让这些人与其他人互通，就显得很麻烦，需要做出更多的可靠性设计。

MCU

MCU 主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。
MCU 技术在视频会议领域出现得非常早，目前技术也非常成熟，主要用在硬件视频会议领域。不过我们今天讨论的是软件 MCU，它与硬件 MCU 的模型是一致的，只不过一个是通过硬件实现的，另一个是通过软件实现的罢了。MCU 方案的模型是一个星形结构，如下图所示：

MCU 主要的处理逻辑是：接收每个共享端的音视频流，经过解码、与其他解码后的音视频进行混流、重新编码，之后再将混好的音视频流发送给房间里的所有人。
MCU 技术在视频会议领域出现得非常早，目前技术也非常成熟，主要用在硬件视频会议领域。不过我们今天讨论的是软件 MCU，它与硬件 MCU 的模型是一致的，只不过一个是通过硬件实现的，另一个是通过软件实现的罢了。MCU 方案的模型是一个星形结构，如下图所示：

MCU 方案架构图
我们来假设一个条件，B1 与 B2 同时共享音视频流，它们首先将流推送给 MCU 服务器，MCU 服务器收到两路流后，分别将两路流进行解码，之后将解码后的两路流进行混流，然后再编码，编码后的流数据再分发给 B3 和 B4。
对于 B1 来说，因为它是其中的一个共享者，所以 MCU 给它推的是没有混合它的共享流的媒体流，在这个例子中就是直接推 B2 的流给它。同理，对于 B2 来说 MCU 给它发的是 B1 的共享流。但如果有更多的人共享音视频流，那情况就更加复杂。

MCU 主要的处理逻辑如下：

那 MCU 的优势有哪些呢？大致可总结为如下几点：
技术非常成熟，在硬件视频会议中应用非常广泛。
作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。
将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验非常好。
同样，MCU 也有一些不足，主要表现为：
重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大。
重新解码、编码、混流还会带来延迟。
由于机器资源耗费很大，所以 MCU 所提供的容量有限，一般十几路视频就是上限了。

SFU 方案

SFU 像是一个媒体流路由器，接收终端的音视频流，根据需要转发给其他终端。SFU 在音视频会议中应用非常广泛，尤其是 WebRTC 普及以后。支持 WebRTC 多方通信的媒体服务器基本都是 SFU 结构。SFU 的拓扑机构和功能模型如下图：

在这个图中，B1、B2、B3、B4 分别代表 4 个浏览器，每一个浏览器都会共享一路流发给 SFU，SFU 会将每一路流转发给共享者之外的 3 个浏览器。

下面这张图是从 SFU 服务器的角度展示的功能示意图

相比 MCU，SFU 在结构上显得简单很多，只是接收流然后转发给其他人。然而，这个简单结构也给音视频传输带来了很多便利。比如，SFU 可以根据终端下行网络状况做一些流控，可以根据当前带宽情况、网络延时情况，选择性地丢弃一些媒体数据，保证通信的连续性。

目前许多 SFU 实现都支持 SVC 模式和 Simulcast 模式，用于适配 WiFi、4G 等不同网络状况，以及 Phone、Pad、PC 等不同终端设备。

SFU 的优势有哪些呢？：

• 首先 由于是数据包直接转发，不需要编码、解码，对 CPU 资源消耗很小。
• 其次是 直接转发也极大地降低了延迟，提高了实时性。
• 最后 带来了很大的灵活性，能够更好地适应不同的网络状况和终端类型。

同样，SFU 有优势，也有不足，主要表现是：
由于是数据包直接转发，参与人观看多路视频的时候可能会出现不同步；相同的视频流，不同的参与人看到的画面也可能不一致。

参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难。总之，整体在通用性、一致性方面比较差。

通过上面的分析和比较，综合它们各自的优劣情况，我们可以得出 ，SFU 是三种架构方案中优势最明显而劣势又相对较少的一种架构方案。

无论是从灵活性上，还是音视频的服务质量、负载情况等方面上，相较其他两种方案，SFU 都有明显的优势，因此这种方案也被大多数厂商广泛采用。

另外，在上面介绍 SFU 方案时，我们还提到了视频的 Simulcast 模式和 SVC 模式，他们是什么呢，又对 SFU 架构来说都带来了哪些好处呢。

Licode架构

Licode 既可以用作SFU 类型的流媒体服务器，也可以用作 MCU 类型的流媒体服务器。一般情况下，它都被用于SFU类型的流媒体服务器。
Licode 不仅仅是一个流媒体通信服务器，而且还是一个包括了媒体通信层、业务层、用户管理等功能的完整系统，并且该系统还支持分布式部署。
Licode 是由 C++ 和 Node.js 语言实现。其中，媒体通信部分由 C++ 语言实现，而信令控制、用户管理、房间管理用 Node.js 实现。它的源码地址为： https://github.com/lynckia/licode 。
下面这张图是 Licode 的整体架构图：

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流媒体服务器的架构及特点

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

它是一个开源项目，其源码的编译、安装非常简单，只要按 GitHub 上的说明操作即可。源码及编译手册的地址为： https://github.com/meetecho/janus-gateway 。

Janus 的部署也十分简单，具体步骤详见文档，地址为： https://janus.conf.meetecho.com/docs/deploy.html 。

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 官网的例子类似（https://apprtc.appspot.com），不一样点是这个插件要通过服务端进行音视频流中转，而 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 等。其源码地址为： https://github.com/medooze/media-server 。

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

1.浏览器从服务器获取客户端代码，通过V8引擎，启动底层WebRTC

2.浏览器与服务端的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 在音视频的内容上以及网络传输的质量上都作了大量优化。

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 流媒体服务器开源库，其地址为： https://github.com/versatica/mediasoup/ 。

下图是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++)部分实现的。 

Mediasoup是多进程程序，他会在业务层控制进程的个数，监听系统的CPU核数，会对每一个CPU绑定一个Mediasoup进程

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

Meidasoup多进程图：

Host（最大的灰色底框）中，包含worker一、worker二、worker3（3个白色框），能够认为是进程。
每一个worker中，包含1个或多个router（蓝色的方片花），进程中有1个或多个房间。

• router周围有：音视频生产者（红色的输入）+ 音视频消费者（绿色的输出），每一个房间有多个生产者和消费者。
• producer：一路视频是一个生产者，一路音频也是一个生产者 。
• consumer：一路视频是一个消费者，一路音频也是一个消费者 。
• transport：一个Transport 就只关联一个用户。
• 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 左右。

转自:
https://blog.51cto.com/u_15075520/4103096