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 很符合选择。
相关视频推荐：
C/C++程序员进入互联网公司的捷径-WebRTC开发_哔哩哔哩_bilibili
手把手实现WebRTC音视频通话|WebRTC音视频通话逻辑剖析、如何通过代码实现音视频通话_哔哩哔哩_bilibili
学习地址：【免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发-学习视频教程-腾讯课堂
需要更多ffmpeg/webrtc..音视频流媒体开发学习资料加群812855908领取
3 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 的未来无可限量。
本文出自快速备案，转载时请注明出处及相应链接。
