近年来，直播竞答、网络游戏直播等新的实时音视频通讯场景不断推陈出新，并成为引领互联网娱乐风向的弄潮儿。实时音视频应用的爆发，也使得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 很符合选择。