注：本文转自
https://blog.csdn.net/ai2000ai/article/details/80705410

  • 引言
  • 开源的WebRTC 服务器介绍
  • WebRTC 服务端分析
  • 通信优化
  • 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数据包，对数据进行选择性重传。

多人通信

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

1、不同的用户网络带宽

2、 不同的运营商

不同用户网络带宽

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

转码

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 的未来无可限量,分享结束，谢谢大家。

开源WebRTC 服务器介绍相关推荐

  1. 常用开源Jabber服务器介绍

    常用开源Jabber服务器介绍 1. Openfire (Wildfire) 3.x 授权:GPL or 商用 操作系统平台:所有(使用Java开发) XMPP Jabber 协议实现情况:98% T ...

  2. webrtc服务器janus的一点看法

    接触webrtc也有一年多时间了,刚开始由于对webrtc也不熟悉,为了快速开发以及出产品,最终选择了开源webrtc服务器janus,然后做了一些自己的定制开发,下面先对janus做一个简单的介绍. ...

  3. 如何打造自己的WebRTC 服务器

    1.引言 近年来,直播竞答.网络游戏直播等新的实时音视频通讯场景不断推陈出新,并成为引领互联网娱乐风向的弄潮儿.实时音视频应用的爆发,也使得WebRTC(Web Real-Time Communica ...

  4. webrtc服务器压测工具使用

      主要介绍3个开源的webrtc压力测试框架–kite,pion及srs_bench,以janus服务器为例. 1.KITE    KITE整合了Selenium和Aullure.Selenium ...

  5. 开源流媒体服务器SRS学习笔记(1) - 安装、推流、拉流

    SRS(Simple RTMP Server) 是国人写的一款非常优秀的开源流媒体服务器软件,可用于直播/录播/视频客服等多种场景,其定位是运营级的互联网直播服务器集群. 1.安装 官网提供了3种安装 ...

  6. webrtc服务器架构Mesh/MCU/SFU

    互动直播之WebRTC服务开源技术选型 https://www.jianshu.com/p/73f2615dc3ef WebRTC 开发实践:为什么你需要 SFU 服务器 https://cloud. ...

  7. 最热开源无服务器函数：五大Fission架构参考

    "无服务器"现在是极具诱惑的技术趋势,没有什么比管理服务器更让人痛苦.亚马逊.微软和谷歌都在云中提供无服务器专有接口.相较于这些云供应商的商业化产品,开源无服务器架构可免于被云厂商 ...

  8. 转帖 开源游戏服务器调研

    汇总贴 2013年优秀的开源引擎与开源游戏项目 http://mobile.51cto.com/aengine-431122.htm http://www.oschina.net/search?sco ...

  9. p2p webrtc服务器搭建系列1： 房间,信令,coturn打洞服务器

    中继(relay) 在RTCPeeConnection中,使用ICE框架来保证RTCPeerConnection能实现NAT穿越 ICE,全名叫交互式连接建立(Interactive Connecti ...

  10. Java学习笔记：Javaweb的服务器介绍

    Java Web,是用Java技术来解决相关web互联网领域的技术总和.web包括:web服务器和web客户端两部分.Java在客户端的应用有java applet,不过使用得很少,Java在服务器端 ...

最新文章

  1. 工业互联网 — TSN — 技术架构
  2. android图片加载库Glide
  3. linux shell之xargs 、tr、sha1sum、head、tail一般使用
  4. oracle虑重语句,db基本语句（oracle）
  5. easyUI学习笔记二
  6. 机器学习和人工智能的初学指南
  7. 武汉大学计算机学院 招聘院长,黄传河任武汉大学计算机学院执行副院长 主持工作...
  8. 华为成立德国实验室属实 但并非为5G牌照
  9. C# 从DataTable中取值
  10. 元数据是什么意思_抖音飞瓜数据什么意思，飞瓜数据有什么用
  11. 在Visual Studio中一次运行两个项目
  12. 论一种迫不得已用全中文数据库的情景
  13. 论文笔记_S2D.40_2017_CVPR_半监督深度学习的单目深度图预测
  14. PHP汉字转换拼音的函数代码
  15. 《尚书》全文、注释及译文(1)
  16. 计算机读不出光盘,光驱读不出光盘,小编教你电脑光盘不能被识别怎么解决
  17. 魔众刮刮卡抽奖系统 v2.0.0 支付抽奖，更好用的刮刮卡系统
  18. 小米8透明探索版无限重启，且有BootLoader锁的情况下卡刷机成功
  19. vue uniapp通用省市下拉选择器组件 布局样式可灵活根据ui变更 (区域 可根据数组嵌套的格式继续往下模仿即可)
  20. 三国志10在win7下的安装

热门文章

  1. 世界城市与北京时差表
  2. transformer中的多头注意力机制
  3. 谈一谈今年的移动互联网寒冬
  4. 学习云存储需要了解的一些技术知识
  5. 【6】三剑客：grep、sed、awk 匹配多个条件
  6. 苹果app充值限制解除_2020还在充值退款？正规苹果app手游充值折扣来了！
  7. 笔记本Win10系统关于启动禁用触控板设置
  8. nx531j android版本,努比亚Z11(NX531J)官方固件rom全量系统升级更新包：V2.92
  9. C站一名 普通技术博主 的终端与【开端】，因为热爱，所以习惯，2021~2022
  10. robotstudio工作站建立