如何打造自己的WebRTC 服务器

1. 引言

 

近年来,直播竞答、网络游戏直播等新的实时音视频通讯场景不断推陈出新,并成为引领互联网娱乐风向的弄潮儿。实时音视频应用的爆发,也使得WebRTC(Web Real-Time Communication,网页实时通信技术,)技术成为了人们关注的焦点。如何打造自己的WebRTC 服务器呢?下面我先来介绍一下WebRTC 服务器的一些基本内容:

 

  • 开源的WebRTC 服务器介绍

  • WebRTC服务端整体分析

  • 通信优化

  • WebRTC的未来展望

     

 

首先,我们会先来了解下一些开源的服务器是怎么做的,我们做事情,在没有头绪的基础上,参考和模仿可能是一种必然流程,毕竟站在巨人的肩膀上,我们的视野才更加开阔。

其次,通过形形色色的开源服务器介绍和理解,我们初步的去分析一个WebRTC 服务器究竟包含哪些模块,又是一个什么样的组织架构和层次关系。后面在服务器搭建后面临的丢包和多人通话问题又有什么解决方式。最后就是展望一下整个WebRTC未来发展。

 

2. 开源的WebRTC 服务器介绍

 

我们进入第一部分:WebRTC开源服务器介绍,这个模块我选择了我认为很有代表意义的3种类型的WebRTC 开源服务器

 

  • 大而全的Kurento

  • 务实主义的Licode

  • 小而美的Mediasoup

 

大而全的Kurento

 

之所以称Kurento为大而全,是因为Kurento 强大的滤镜和计算机视觉,我们看这张图:

 

 

Kurento功能图                          

 

通过这张图我们了解到Kurento不仅仅包含了普通流媒体服务器的SFU MCU Transcoding  Recording等基本功能,还包含了强大的滤镜和计算机视觉处理功能,而且,在整体的功能上不仅仅包含WebRTC 模块还有很多其他协议支持,诸如SIP RTMP RTSP 等协议,更准确的说Kurento 更像是一个融合通信平台,而且Kurento,基于插件式编程方式,很容易扩展自己的功能模块。

 

Kurento 在应用中有哪些问题,或者说,哪些是优势,哪些是劣势呢,我们看下面:

 

优势:

 

  • 文档齐全无论API使用文档,还是部署文档都很齐全

  • 功能强大,强大的路径和计算机视觉处理

  • 模块化编程,方便扩展,这是对开发者很友好的地方

  • 使用方便,客户端服务端都有专门的API 组件 接入系统,而且服务器端提供了J2EE node.js两种接口文档,覆盖很齐全

 

劣势:

 

  • 代码太多太庞大,可能需要开发者有足够的功力才能驾驭这把屠龙刀

  • 还一个重要原因就是性能比较差

 

小而美的Mediasoup

 

Mediasoup是一个很新的WebRTC服务器,专注WebRTC 的相关功能开发,专注做好这一件事,很小确很美。下面这样图是Mediasoup 大致的一个基本架构图:

 

Mediasoup 架构

 

Mediasoup

 

优势:

 

  • 性能优秀

  • 支持很多的WebRTC 新特性(PlanB  UnifiedPlan simulcast)

  • 同时支持ORTC和WebRTC 的互通

 

劣势:

 

  • 功能比较少

  • 代码和架构相对来比较晦涩一点

  • 信令模块只提供node.js 版本

     

 

务实主义的Licode

 

说了两款极端的WebRTCserver ,我们最后讲一个务实主义的Licode ,为什么称Licode 为务实主义?Licode 这款服务器完全是站在一个PAAS 平台,一个业务的角度去思考问题,去构建整个系统,很务实,很实际,我们看Licode架构图:

 

Licode 架构图

架构很清晰:

 

用户端:

  • 房间信令模块

  • WebRTC媒体模块

 

服务端:

 

开发者方面:

 

业务接入的API模块

 

服务器内部:

 

  • 面向开发的API 服务模块,提供基本的房间和用户操作

  • 房间服务器模块,提供基本的房间信令支持

  • 媒体模块,完成服务端的WebRTC 媒体功能

 

整个服务架构内部各个服务模块通过MQ 消息总线进行数据通信,做了一个服务器要做的基本功能,同时微服务化,很符合现在服务器开发的方向。

 

Licode 作为WebRTC 服务器有很多优势

 

  • 功能齐全扩展方便,鉴权,存储,融合通信一应俱全

  • 代码扩展简单,预留了足够的扩展接口

  • 部署简单,一键脚本安装,很方便

 

缺点:

  • 内部模块说明比较少

  • 性能一般

  • 服务端只提供的node.js 版本

 

总结

 

这么多服务器怎么选择呢?看自己的业务需求,团队能力,项目周期。

 

有能力的团队可以尝试选Kurento,讲求平衡快速选择Licode,追求极致Mediasoup 很符合选择。

 

3 WebRTC 服务端分析

 

前面我们讲了很多开源WebRTC服务器,到底WebRTC 是个什么东西,又包含哪些模块呢,我们从下面几个方面逐一分析:

  • 基本组件

  • 层次架构

 

基本组件

基本模块

图中我列出了基本的组件:

 

  • Rtp/Rtcp媒体打包协议

  • Dtls加密协议

  • ICEP2P 传输协议

  • SDP系统控制协议,控制整个系统的运行行为

 

Rtp/Rtcp Dtls ICE是基本组件相对实现比较容易,这个我们不做过多介绍,我们着重介绍下SDP 这个协议

 

SDP 演进

 

SDP 伴随着WebRTC 的发展,经历了很多变化,我把这个过程归纳为两个阶段:

  • PlanA单流时代

  • PlanB/UnifiedPlan多流时代

     

 

PlanA

 

每个stream 对应一个peer 多个stream 对应多个peer,整体运行图如下:

 

 

 

PlanA

 

下面是PlanA 的SDP 结构:

 

没什么新奇的地方,大家都应该比较熟悉了,我们不做介绍了。

 

PlanB UnifiedPlan:

 

one peer multi stream, 单个peer 可以拥有多个steam ,整体运行图如下:

 

PlanB UnifiedPlan

其中PlanB 是chrome SDP 多流方案,而UnifiedPlan是Firefox 的多流标准同时也是JSEP的标准多流方案,所以UnifiedPlan是我们关注的重点。

 

我们先来看看PlanB 的多流SDP 大致内容:

 

PlanB SDP

 

PlanB 和 PlanA 相比,基本组织形式是相同的。我们看标红的地方,PlanB 组织多流的方式是通过msid来完成,每个msid 对应一条媒体流. 每个msid下面是自己的传输信息,所以在PlanB 方案下,我们可以通过msid来标记用户。

 

我们再来看看UnifiedPlan,下面是一个UnifiedPlan 部分SDP:

 

UnifiedPlan

 

UnifiedPlan通过加多个m 标签,来组织多流,每条流分配一个m 标签,后面跟着自己的attribute 描述,另外group 行业进行了修改,以每个track 进行描述。当然UnifiedPlan 里面也是msid 可以用来标记用户。

 

相比 PlanB,UnifiedPlan SDP更加清晰,自然,当然问题是数据量比计较大,因为有很多冗余字段,当然作为JSEP 的标准,我们必须更加关注UnifiedPlan 方案。另外Firefox 里面mid 长度不能超过16位,在大家的服务器上产生UnifiedPlan 格式的SDP时注意一下。

PlanBUnifiedPlan 方案优势:

 

  • 客户端single peer, 减少开发难度,无论 MCU 模式还是SFU 模式,客户端只需要创建一个peer

  • 减少端口占用,加强系统安全

 

WebRTC 层次架构

 

说完基本组件,我们开始介绍WebRTC 服务端,分3个层面:

 

接口层

 

接口层主要为PeerConnectionInterface接口实现,主要提供诸如一下内容:

控制层

 

控制层也就是我们所说的SDP 模块,控制整个系统的运行表现,包括编解码参数,流控方式,Dtls 加解密参数以及ICE穿透用的地址候选。

 

 

传输层

 

先看图:

 

传输层分为3个层次,媒体打包(RTP/RTCP),数据安全(DtlsTransport),Ice P2P 传输模块(IceTransport)。

 

了,这里我们了解全部系统组件,将系统组件叠加,我们就得到了,下面是一个完整的WebRTC 组件的一个层次结构:

 

 

分为3层:接口层,提供基本的peer 接口功能,控制层,主要是SDP 的解析和生成工作,最后传输层,提供媒体打包,传输,流控,安全,ICE 等功能。

 

4. 通信优化

 

分两个层面去讲:

 

  • 对抗丢包

  • 多人通话

 

对抗丢包

 

  • NACK

使用场景 low RTT 或者延时不敏感场景

 

  • FEC

 

冗余换取实时性和丢包。增强带宽抢占能力,这才是FEC 最主要的用途。

 

两种方式各有优缺点,NACK代价是延时,FEC的代价是带宽,显然在高清会议中不适用FEC 方式。比较可取的方式是FEC+NACK, 低延时环境下,尽量采用重传,高延时生成适度的FEC数据包,对数据进行选择性重传。

 

多人通信

 

多人通信是一个令人的头疼的问题,因为面临以下几个问题:

 

  • 不同的用户网络带宽

  • 不同的运营商

 

不同用户网络带宽

 

先看第一个,我们都知道在通信中,用户的带宽往往是不对等的,怎么样做到按需供给,总体来说我们有一下几种方式:

 

  • 转码

  • SVC 分层编码

  • Simulcast(多流方案)

 

先转码方案:

 

 

服务端对用户发来的数据进行二次编码,服务端根据用户的网络情况,提供给用户不同质量的码流,这种方式服务压力大,延迟大,硬件成本高,比较适合小规模视频会议,或者发言人较少的场景。

 

SVC方案:

 

编码器产生的码流包含一个或多个可以单独解码的子码流,子码流可以具有不同的码率,帧率和空间分辨率。

 

分级的类型:

 

时域可分级(Temporalscalability):可以从码流中提出具有不同帧频的码流。

空间可分级(Spatialscalability):可以从码流中提出具有不同图像尺寸的码流。

质量可分级(Qualityscalability):可以从码流中提出具有不同图像质量的码流。

 

分层结构图

 

SVC可以组合提供不同质量的码流,服务器可以根据用户网络情况选择一路进行转发,

SVC 应该是最好的对抗丢包的方式,可惜WebRTC 不能用,这里我们不做深入研究,H264SVC RTP打包情况可以参考rtc6190

 

Simulcast(多流) 方案:

如图:

 

客户端同时发送多种码率到服务端,然后服务端进行选择性转发,这种方案,发送端上传压力大,而且编码压力也大,但是,这是唯一一种WebRTC 支持的针对多人通话的技术。

下面我们看看如何开启这种技术:

 

  • Chrome 端  包括js 和 native 源码端:

     

 

Chrome并没有提供直接的接口用于开启多流方案,我们在Chrome 系列中只能通过修改的本段的SDP 来开启多流方案,如图:

 

 

 

通过修改SDP 加入SIM 标志开启多流,开启几条,就多加入几条ssrc 信息

 

  • Firefox 端:

     

 

Firefox 提供了直接的接口用于开启多流方案,如下图:

 

Firefox直接通过RtpSender 的 SetParameters 接口开启多流,简单方便,这也是Firefox 相比较Chrome更好的地方,更加遵从WebRTC标准。

 

另外在Rtp的传输上Chrome和Firefox 是不同的:

 

>>>Chrome:

 

通过ssrc 对应多流方案,每个ssrc对应一种多流

a=ssrc-group:SIM2098403539(low) 2098403540(medium) 2098403541(high)

 

>>>Firefox:

 

通过urn:ietf:params:rtp-hdrext:sdes:rtp-stream-idRtp协议头的扩展来完成多流和ssrc 的对应关系,进而完成传输。

 

不同运营商

 

 

中国运营商主要有电信 移动和联通,另外包括很多小运营上和结构运营商,运营商很多,而且由于运营商之间的网络宽口问题,跨网通信延迟大,网络不稳定,针对这种情况,我们基于DNS重定向,分配给用户运行商相同的服务器,这里说一句,运营商分类的判断,需要很久的运维经验和数据作为支撑,这也是我们的PP云的优势所在,我们PP云有十几年的运营数据作为支撑,这些数据不仅帮我们构建更加快速的服务器网络,而且还可以帮我们为用户定位到最优的服务器,进而解决最后一英里的网络传输问题。

 

5 WebRTC 未来展望

 

为AI 赋能

 

AI 的发展,赋予了WebRTC更多的应用空间,比如基于人脸和语音识别的网站和APP 登录系统,前端通过WebRTC 进行视频数据的采集和传输,后台通过AI智能分析比对结果,进而完成登录,简单,方便。

 

安防领域

 

我们知道安防领域比较多的协议包括ONVIF,GB28181 RTSP,这几个协议在网页端无法直接观看,智能借助于插件,插件面临兼容和安全问题,体验很差,有的摄像头支持RTMP观看,但是很遗憾,2020年flash 将退出历史舞台,HLS延时大,而无插件,极速都是WebRTC 的优势所在,我相信不救的将来WebRTC 在安防领域会占据一席之地。

 

6. 结语:

 

WebRTC1.0 已经定稿,这为WebRTC的未来发展提供了方向,并且WebRTC 无论是应用还是社区都处于高速发展状态,并且Google也在不断地提供和完善WebRTC 的相关功能,我相信WebRTC 的未来无可限量,分享结束,谢谢大家。

©️2020 CSDN 皮肤主题: 1024 设计师:上身试试 返回首页