（音视频开发）WebRTC进阶流媒体服务器开发-多人互动架构

一：多人互动架构方案

（一）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/播放器-音视频流媒体高级开发。