1、引言

---

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

• 开源的WebRTC 服务器介绍

• WebRTC服务端整体分析

• 通信优化

• WebRTC的未来展望

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

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

2、开源的WebRTC 服务器介绍

---

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

• 大而全的Kurento

• 务实主义的Licode

• 小而美的Mediasoup

2.1大而全的Kurento

---

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

Kurento功能图

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

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

优势：

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

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

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

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

劣势:

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

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

2.2小而美的Mediasoup

---

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

Mediasoup 架构

Mediasoup

优势：

• 性能优秀

• 支持很多的WebRTC 新特性（PlanB UnifiedPlan simulcast）

• 同时支持ORTC和WebRTC 的互通

劣势：

• 功能比较少

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

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

2.3务实主义的Licode

---

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

Licode 架构图

架构很清晰:

用户端:

• 房间信令模块

• WebRTC媒体模块

服务端：

开发者方面：

业务接入的API模块

服务器内部：

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

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

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

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

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

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

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

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

缺点：

• 内部模块说明比较少

• 性能一般

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

2.4总结

---

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

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

3、WebRTC 服务端分析

---

到底WebRTC 是个什么东西，又包含哪些模块呢，我们从下面几个方面逐一分析：

• 基本组件

• 层次架构

3.1基本组件

---

基本模块

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

• Rtp/Rtcp媒体打包协议

• Dtls加密协议

• ICEP2P 传输协议

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

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

3.2SDP 演进

---

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

• PlanA单流时代

• PlanB/UnifiedPlan多流时代

3.3PlanA

---

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

PlanA

下面是PlanA 的SDP 结构：

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

3.4PlanB 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

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

3.5WebRTC 层次架构

---

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

3.5.1接口层

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

3.5.2控制层

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

3.5.3传输层

先看图：

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

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

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

4、通信优化

---

分两个层面去讲：

• 对抗丢包

• 多人通话

4.1对抗丢包

---

• NACK

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

• FEC

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

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

4.2多人通信

---

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

• 不同的用户网络带宽

• 不同的运营商

4.3不同用户网络带宽

---

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

• 转码

• 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 的对应关系，进而完成传输。

4.4不同运营商

---

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

5、WebRTC 未来展望

---

5.1为AI 赋能

---

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

5.2安防领域

---

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

6、结语：

---

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

原文https://www.toutiao.com/article/7049339761479189006/?channel=&source=search_tab

★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。

见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓