上海高端工作室网站/网络推广公司可不可靠

随着移动互联网的迅速发展，很多公司都想介入在线教育、智能家居、多人视频、安防监控等领域，虽然都是视频通讯，但他们服务端的架构与点对点通讯大不想同，

大部分情况下的单人视频通话可能根本不需要用到流媒体服务，而多人视频，在线教育这些则必须用到，所以下面主要介绍多人视频中服务端架构模式，以及各自特点：

 

一，Mesh结构.

这是最简单的多人视频通话架构模式，所有媒体流都不需要经过服务端，客户端直接P2P，可通过webrtc建立多个PeerConnection，结构图如下:

该方案优点:

1，服务端压力最小，大多数情况下不需要用到流媒体服务。

该方案缺点:

2，客户端负载太大，不事宜扩展，特别是移动端，编解码压力会非常大.

 

二，Mixer结构:

视频会议基本上就是种结构，他的最大特点就是服务端做了很多事情，包括转码，混音，合屏，所以服务端负载非常大，结构图如下:

该方案优点:

1.1，客户端负载最小，与一对一负载一样，所以理论上可以支持很多人同时视频。

1.2，因为服务端有做编解码，所以可与现有产品无缝集成。

1.3，可以最大程度利用硬件能力，如硬件MCU，芯片。

该方案缺点:

1.1，服务端负载很大，建设成本很高。

1.2，延迟问题，因为服务端做了很多动作（解码，合屏，混音，编码），所以会带来延迟。

 

三，Router结构

该方案最大特点就是服务端只负责包转发，不负责转码，yy流媒体服务基本上就是这个功能，结构图如下.

该方案优点:

1.1，与Mixer相比服务端压力比较小，而且容易扩展。

1.2，低延迟，特别是与SVC结合能大大提升客户端体验度（貌似h265和vp9才开始集成svc）。

该方案缺点:

1.1，考虑到不同客户端需要不同的接收能力，所以真正实现下来服务端的架构也并不简单。

 

补充说明:

1，因为各种模式都有自己的优缺点，所以实际应用中您应该根据自己的具体业务选择适合的架构模式。

2，现在有很多开源框架和PAAS可以做上面这些事情，但是实际应用中都存在这样的问题，并不成熟。

webrtc的P2P代码结构

先来张图显示实际会话过程中的两种通讯路径：P2P或转发,92%的情况下是通过P2P实现.

注意:实际通讯过程中每个客户端都会不停地发送和接收Stun包，这样做是为了维护响应的连接和端口.

实际通讯过程中的核心组件为P2PTransportChannel，他代表着本地和远程计算机的连接通道，

管理着许多本地和远程计算机上许多不同的连接类型的连接对象，如TCP,udp,

连接对象上包含了本地端口和远程地址信息，当一个连接失败时他会无缝地切换到另一个连接上，下图是P2P数据通道的内部结构图

下面是代码结构中堆栈调用过程：

1，接收和发送数据的AsyncUDPSocket创建过程如下：

2，呼叫方根据remotecandidate创建连接并执行Ping过程如下:

3、接收方根据remotecandidate创建连接并执行Ping过程如下：

4、收到Stun响应更改连接状态调用过程如下：

 

5、连接成功建立开始数据收发调用过程如下：