WebRTC 架构优化及实践

内容来源：2018 年 1 月 13 日，声网Agora.io音乐工匠高泽华在“架构师修炼之道——极光开发者沙龙JIGUANG MEETUP”中，进行的《WebRTC架构优化及实践》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：2500 | 5分钟阅读

获取嘉宾演讲视频及PPT： suo.im/597g90

摘要

目前几乎全部主流浏览器都支持了 WebRTC，包括 Firefox、Chrome、Opera、Edge。WebRTC 1.0 的标准化进程也处于很是高级的阶段。愈来愈多的公司正在使用 WebRTC 而且将其加到本身的应用程序中。那么，企业在构建 WebRTC 应用时，应当注意什么？本次演讲将为你解读：标准的 WebRTC 系统的典型架构是怎样的， WebRTC 的坑与优化实践、浏览器适配及平台兼容性实战等。

WebRTC是什么？

WebRTC首先是一种标准，目前WebRTC 1.0的w3c标准现已推出，2.0版本也在推动过程当中（演讲时间为止）。其次是一种协议，开发者能够经过follow这个协议来实现和WebRTC的互通。另外它仍是一款引擎，由于它前身就是处理音视频的GIPS引擎。另外在这套引擎下还有大量的音视频算法，因此WebRTC也能够说是算法。

WebRTC的前世此生

上文提到WebRTC的前身是GIPS，而GIPS的发展其实分为两个阶段，第一阶段为Global IP Sound，第二个阶段为Global IP Solution。它在Global IP Sound 阶段是做为音频通讯引擎用于各类嵌入式系统设备中，主要负责回声消除、降噪、编解码等基础功能。

以后继音频服务又加入了video服务，也就是Global IP Solution阶段，后来在和客户的沟通中他们不断的加入IP通讯的协议、RTP协议等，以实现和网络链接的能力。可是因为商业上的不合理和销售策略的失败，最终仍是被google以6千多万美圆的价格给收购。

而从技术的演进来说，GIPS到WebRTC，实际上是对Engine层作了封装，顺便还添加了原先GIPS缺失的网络模块。通常要提供音视频服务必需要有服务器，为了不这种模式，WebRTC采用了P2P的通讯模式。

如何使用WebRTC

我的以为如今99%以上和实时通讯相关的app愈来愈离不开WebRTC，即便应用的代码框架不相同，但WebRTC仍是有不少经典算法值得借鉴。

一般咱们能够将WebRTC做为学习和移植算法的入门代码，或者抽象出它的音视频引擎，还能够用做PaaS或者SaaS服务。

虽然WebRTC有各类不一样应用，可是因为目标不一样，因此在结合WebRTC自己能力上会有不一样的侧重点，须要针对性的查看相应的代码，找出其中有缺陷的部分并作出突破。好比要作SaaS和PaaS服务就要准备服务器相关的工做。

使用WebRTC 提供SaaS

WebRTC确实能够用来作SaaS服务，可是须要先考虑要作的是什么类型的SaaS服务。好比对于不是基于Web的音视频通讯服务，就还要考虑额客户端进行互通。

而不一样的行业对此的要求也不同，像呼叫中心和教育类的一般会直接使用web进行服务。不过WebRTC在多浏览器上的兼容性并很差，视频编解码的支持也有所不一样。

使用的时候咱们要根据服务质量要求和用户特色灵活使用p2p，好比在大部分用户都处于WiFi环境的状况下p2p多是更好的选择，而对于4g网络p2p效果会差一些。

若用户对服务质量要求比较高，我的建议应先着手创建服务器，并部署运维监控负载均衡等能力，让后端服务器出现的问题对用户无感知。

应用这些措施应对纯web端的SaaS服务其实还有所不足，有不少细节问题仍需处理。好比用户外接了音频设备，或者某款浏览器的音频通讯产品在本机上没有适配好，从而产生回声等各类问题。

又由于底层不是本身作的，所以只能提醒用户在使用服务的时候先测试一遍，或者给出一些其余建议。

使用WebRTC提供PaaS

所谓PaaS就是提供一个平台给厂商使用，不一样于SaaS它在上层应用上并无作的过于精细，其主要目标仍是为了提供更稳定更高效的通讯服务。

在SaaS服务中，咱们能够分析用户行为，针对用户的使用场景进行优化。可是Paas服务中，用户千差万别，可能会涉及IoT、教育、游戏等个各类不一样领域，原有的WebRTC引擎确定不够用。

所以在包含SaaS的各类基础服务以外，还须要抽象出一套API，而后再针对各个移动设备作适配，还要根据应用场景提供多种增值功能，提供针对场景的特殊优化和包裁剪等。

如何借鉴WebRTC开发AV engine

因为WebRTC本质上更接近于音视频引擎，因此若是当AV SDK用，会更便捷。

固然前提是使用者有至关的经验，可以根据具体的场景定制化参数。

音频部分在WebRTC中一共封装了4个模块，ANM（网络模块）、APM、ACM（编解码模块）、ADM，对应的video也有一样的4个模块，因此总共是8个模块。我的认为WebRTC的重点就在于这8个模块自己和它们之间的参数配置。

可是这也带来了相应的缺点，咱们要作面向移动端的功能实例优化、性能实例优化以及一些特殊优化，这也使得调试的次数愈来愈多。

如何学习WebRTC算法

只有在学习了WebRTC的算法以后，才能从不一样的层面给客户解释清楚为何要采用当前方案以及为何不用其余方案。WebRTC的精髓在于底层的引擎部分，不过要想对这部分有深刻的理解，首先就要对其中的算法有必定的研究。

前面提到过WebRTC中有8个模块和2大引擎，其中音频模块包括APM、ACM和ADM，视频模块包括VNM、VPM、VCM。

APM

APM中涵盖AGC、ANS、DE和回声消除的算法NLP。接下咱们逐步看下这里面到底都是些什么。

一般的回声消除有两种算法，一种是自适应滤波，一种是NLP。在WebRTC以前其实自适应滤波已经作的足够好了，目前这方面的研究基本上已经停滞，可能在多通道和立体声的回声消除上还有必定的研究价值。NLP则不同，它还有不少细节值得探讨，这是由于每一个声腔的声音设计不一样，形成了非线性部分的差别。

WebRTC中有两个回声消除模块分别是AEC和ANS，AEC的NLP算法考虑到了很是多的细节，若是想要研究它的算法，能够好好的看下它的专利说明。

DE是延时估计模块，如今几乎全部的延时估计模块的都用的这一套算法。AGC主要任务是将非噪声部分调高，噪声部分调低，这里的重点就在于如何区分噪声，等于一个降噪的问题。

WebRTC中的AGC是和VAD放在一块儿的，VAD采用的是GMM模型，经过统计学的方式来判断当前是不是Voice，而后在结合到AGC上，全部虽然AGC中的参数仍然要调整，可是算法仍是不错的，能够直接拿来用。

ACM

WebRTC的编解码器有ILBC、ISAC 、Opus，ILBC是窄带编码器、ISAC是宽带编码器、Opus是全带的音频和语音统一的编码器。在CPU性能较强且可以接受高带宽的状况下Opus能够作的很是好。

ANM

ANM作的是带宽估计和拥塞控制，因为如今带宽较大，因此音频方面的带宽估计已经不多有人在作了，视频方面仍是比较常见。比较有意思的是音频的带宽估计被写入到了ISAC的代码中。

咱们知道丢包通常分为两种，随机丢包和bond丢包，拥塞就属于bond丢包的范畴，好比连续丢失多个包或没法发包都算做拥塞。

ANM中的PLC是一种拉伸快进和慢放的算法，好比要在100毫秒的包中存放200毫秒的数据的时候，PLC就会将包给慢放以实现200毫秒的效果，经过这种方式来应对网络丢包。PLC的优点在于变速不变调。

视频

相对音频模块，视频部分能够挖掘的空间还不少，容易作出差别化。

视频对网络的要求会更高，直播和通讯是常见的场景。直播的时候关注的是清晰度，而通讯方面更注重流畅度。侧重点的不一样，带来了更多的参数调整。好比结合编解码器考虑抗丢包、结合降噪考虑编解码等，以及硬件的适配。