WebRtc 框架学习(一)

相关连接

1. WebRtc 框架学习(一)
2. Mediasoup基本框架学习
3. 使用docker 搭建MediaSoup服务
4. MediaSoup-demo模块增加nginx

WebRtc

​ WebRTC是由Google主导的，由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端之间）的音频、视频及数据共享。WebRTC不需要安装任何插件，通过简单的JavaScript API就可以使得实时通信变成一种标准功能。

WebRtc协议详解

​ WebRTC 传输层主要采用UDP协议，因为TCP讲究可靠、有序，如果丢包，后续包会被缓冲起来，UDP正好相反，对于实时视频传输来说，这是满足需求的。WebRtc由于对事实性要求高于准确性，所以才有UDP。

RTCPeerconnection: WebRtc客户端之间相互建立连接、进行流媒体数据通信的接口。

DataChannel：WebRtc客户端用该接口进行其它非流媒体数据通信。

• STUN(UDP协议)服务器

  ​ UDP服务只是在IP层的基础上做了一些简单的封装而已，要实现端到端通信必须面临防火墙，NAT阻隔等问题。为了解决这些问题，WebRtc客户端通过STUN服务器获取对方客户端的公网IP地址(内网NAT原理)。然后WebRtc客户端自行连接，相互通信。由于大部分路由器不容许获对方取连接设备的公网ip地址。STUN无法用于生产环境。

• TURN(UDP协议)服务器

  ​ 如果STUN无法获取对方公网IP的情况下，可以通过TURN服务器转发，ICE将 会使用TURN中继服务器，TURN服务器实际上在WebRTC对等体之间中继媒体，所以我这里理解的话使用TURN就很难被称为端对端之间通信了。但是TURN。

  ​ TURN的服务器只能作为STUN的辅助模式，n个客户端通过TURN相互通信，每个客户端需要上传n路音视频流，同时需要下载n对方音视频流。通话质量取决于每个客户端的网络环境，而且无法支持很多人进行视频会议，也不能用与生产环境。

  

• Signal(信令)服务器

  ​ Signal服务用于客户端之间相互交换媒体消息(SDP数据)，同步来获取对方的视频封装，编码格式等。还要进行房间进行管理，交换双方的candidate数据。Signal需要准确性，所以是TCP协议通信。

  

WebRtc框架常见模式

• SFU模式

  ​ 所有客户端同时连接SFU模式，n个客户端通过SFU互换媒体数据，客户端上传一路音视频流，通过SFU转发到其他客户端，同时向SFU拉取n-1路视频流。这样客户端上传带宽只占一路，下载要n-1路。现在常用框架都是基于这种模式。

  

• MFU模式

  ​ SFU模式虽然上传带宽只占一路，但是要下载n-1路流。下载仍然要对带宽有要求，这时候MFU模式就用来解决这种问题，MFU服务器将n个客户端的视频流，合成一路，这样WebRtc客户端只要下载一路流就好了，但是这样有缺点，首先MFU需要合成n-1路视频流，对服务器CPU资源有较大消耗。而且合成一路视频流后接收者无法自由配置其他客户端视频信息(打开、关闭任意一路视频)。所以一般选用SFU模式。

WebRtc成熟的开源架构

• mediasoup

  优点：性能优秀，支持很多WebRtc新特性(PlanB UnifiedPlan simulcast)，同时支持ORTC和WebRTC互通

  缺点：功能较少，代码架构比较难懂，信令只提供node.js版本。

  Mediasoup基本框架学习

• kurento

  优点：文档齐全，功能、封装API都比较齐全，对Android和IOS也有原生API支持，支持h264。

  缺点：bug较多，不是很稳定，接口太多，所以使用起来相对复杂，Android和IOS缺少官方demo，因其中增加了视觉增强等图像处理功能，所以会有视频延迟风险。

• jitsi

  优点：比较稳定，家族产品较多，即时通讯，电子白板，文件共享都有。2017年8月发布android和IOS原生API接口。

  缺点：协议用的是SIP和XMPP，编译部署过程过于复杂，依赖库较多，且文档比较少。缺少android和IOS的demo和文档。多人对讲时采用的是单路分发机制，对服务器网络等要求较高。

• licode

  优点：接口简洁，服务轻量级，支持h264。

  缺点：API文档比较简单且其他文档较少；客户端接口只有js的，没有android和IOS原生API；不是很稳定，经常中断。

​ 这么多服务器怎么选择，有团队能力可以尝试Kuernto，讲求平衡快速选择Licode，追求极致选择Mediasoup很符合选择