内容来源：2018 年 1 月 13 日，声网Agora.io音乐工匠高泽华在“架构师修炼之道——极光开发者沙龙JIGUANG MEETUP”中，进行的《WebRTC架构优化及实践》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
阅读字数：2500 | 5分钟阅读
摘要
目前几乎所有主流浏览器都支持了 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的优势在于变速不变调。
视频
相对音频模块，视频部分可以挖掘的空间还很多，容易做出差异化。
视频对网络的要求会更高，直播和通信是常见的场景。直播的时候关注的是清晰度，而通信方面更注重流畅度。侧重点的不同，带来了更多的参数调整。比如结合编解码器考虑抗丢包、结合降噪考虑编解码等，以及硬件的适配。