阅读量:0
近年来，直播竞答、网络游戏直播等新的实时音视频通讯场景不断推陈出新，并成为引领互联网娱乐风向的弄潮儿。实时音视频应用的爆发，也使得WebRTC（Web Real-Time Communication，网页实时通信技术，）技术成为了人们关注的焦点。如何打造自己的WebRTC 服务器呢？下面我先来介绍一下WebRTC 服务器的一些基本内容：
开源的WebRTC 服务器介绍
WebRTC服务端整体分析
通信优化
WebRTC的未来展望
首先，我们会先来了解下一些开源的服务器是怎么做的，我们做事情，在没有头绪的基础上，参考和模仿可能是一种必然流程，毕竟站在巨人的肩膀上，我们的视野才更加开阔。
其次，通过形形色色的开源服务器介绍和理解，我们初步的去分析一个WebRTC 服务器究竟包含哪些模块，又是一个什么样的组织架构和层次关系。后面在服务器搭建后面临的丢包和多人通话问题又有什么解决方式。最后就是展望一下整个WebRTC未来发展。
2. 开源的WebRTC 服务器介绍
我们进入第一部分：WebRTC开源服务器介绍,这个模块我选择了我认为很有代表意义的3种类型的WebRTC 开源服务器
大而全的Kurento
务实主义的Licode
小而美的Mediasoup
大而全的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架构图：
架构很清晰:
用户端:
房间信令模块
WebRTC媒体模块
服务端：
开发者方面：
业务接入的API模块
服务器内部：
面向开发的API 服务模块，提供基本的房间和用户操作
房间服务器模块,提供基本的房间信令支持
媒体模块，完成服务端的WebRTC 媒体功能
整个服务架构内部各个服务模块通过MQ 消息总线进行数据通信，做了一个服务器要做的基本功能，同时微服务化，很符合现在服务器开发的方向。
Licode 作为WebRTC 服务器有很多优势：
功能齐全扩展方便，鉴权，存储，融合通信一应俱全
代码扩展简单，预留了足够的扩展接口
部署简单，一键脚本安装，很方便
缺点：
内部模块说明比较少
性能一般
服务端只提供的node.js 版本
总结
这么多服务器怎么选择呢？看自己的业务需求，团队能力，项目周期。
有能力的团队可以尝试选Kurento，讲求平衡快速选择Licode，追求极致Mediasoup 很符合选择。
