进击的WebRTC：我们为什么需要它？
作者｜毛玉杰编辑｜覃云编者按：有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年。去年，WebRTC 1.0 标准草案出炉，并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了。
根据腾讯全球合作伙伴大会上发布的《2017 年微信数据报告》显示，截止到 2017 年 9 月，微信日成功通话次数 2.05 次，月人均通话时长 139 分钟，月人均通话次数 19 次。通过这些数据我们可以看到，微信视频通话的出现，已潜移默化地改变了人与人通信的方式。
而回望三大运营商的数据，语音通话量在 2015 年首次出现了负增长，可以看到互联网 OTT 应用对传统语音通话业务的冲击有多强烈。正是由于这些日益完善的基础设施，更快的智能手机，更快的网络，更丰富的使用场景，实时通信的需求越来越强烈。
从 2015 开始不断涌现出的互动直播、狼人杀、抓娃娃、直播答题、线上 KTV 等创新，将常见的线下场景转至线上，也足以作为实时音视频通信风头正劲的有力佐证。
越来越多的创业者都在思考如何将线下互动的场景搬到线上，从而打造下一个风靡全民爆款的应用。
说到实时通信，不得不提到 WebRTC，WebRTC 全名为 Web Real Time Communication，从 Web 这个词就可以看出，最初这项技术是为浏览器量身打造用以实时音视频能力而准备的。
但其实 WebRTC 在不同场景下包含不同的含义，它既可以代表 Google 开源的 WebRTC 项目，又可以代表 W3C 工作组制定的 WebRTC 标准，也可以代表浏览器中的 WebRTC 接口，我们将他们统称为 WebRTC 技术。当前具有实时音视频能力的应用或者服务，或多或少都使用了 WebRTC 技术，当然所有的这些背后都离不开 Google 开源的 WebRTC 项目，下面我们扒一扒 WebRTC 背后的故事。
回溯历史：为什么需要 WebRTC说到 WebRTC，我们不得不提到 Gobal IP Solutions，简称 GIPS。这是一家 1990 年成立于瑞典斯德哥尔摩的 VoIP 软件开发商，提供了可以说是世界上最好的语音引擎。
Skype、腾讯 QQ、WebEx、Vidyo 等都使用了它的音频处理引擎，包含了受专利保护的回声消除算法，适应网络抖动和丢包的低延迟算法，以及先进的音频编解码器。
Google 在 Gtalk 中也使用了 GIPS 的授权。Google 在 2011 年收购了 GIPS，并将其源代码开源，加上在 2010 年收购的 On2 获取到的 VPx 系列视频编解码器，WebRTC 开源项目应运而生，即 GIPS 音视频引擎 + 替换掉 H.264 的 VPx 视频编解码器。
在此之后，Google 又将在 Gtalk 中用于 P2P 打洞的开源项目 libjingle 融合进了 WebRTC。所以目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在内的所有平台的 API，保证了 API 在所有平台的一致性。使用 WebRTC 的好处主要有以下几个方面：
免费的使用 GIPS 先进的音视频引擎，在此之前都需要付费授权。
由于音视频传输是基于点对点传输的，所以实现简单的 1 对 1 通话场景，需要较少的服务器资源，借助免费的 STUN/TURN 服务器可以大大节约成本开销。
开发 Web 版本的应用非常方便，使用简单的 JS 接口，无需安装任何插件，即可实现音视频互通。
2017 年 11 月 2 日，在经历了 6 年的时间之后，W3C WebRTC 1.0 草案正式定稿。同样也是在 2017 年，Microsoft Edge 与 Apple Safari 也纷纷宣称了在其最新的版本里支持 WebRTC 1.0 标准 API。
虽然不同浏览器厂商在某些实现细节方面有所差别，比如 Safari 只支持 H.264，不同的 SDP 描述格式等等，但除了 IE 之外，所有主流浏览器 Google Chrome、Mozilla Firefox、Apple Safari、Microsoft Edge 都已经支持 WebRTC 1.0，所有浏览器之间无插件化的音视频互通已经成为一种可能。
越来越多的终端设备上，无需借助任何插件或者 native 应用，通过打开网页链接，即可进行高质量的音视频通话，应用开发者也无需关注音视频引擎实现细节，大大节约了开发成本。
广泛的适用场景WebRTC 适用的场景可以说是非常广泛，很多行业结合实时通信都可以创造出非常有意思的场景，传统的实时通信应用场景主要是在视频会议、视频面试、VoIP 通话、呼叫中心，产品如 WebEx、Skype 等。
当下比较火的场景主要集中在社交、游戏、体育、电视、相亲类的直播，以及互动连麦、在线教育、在线医疗、金融证券在线开户、智能硬件（如无人机）、智能家居设备如摄像头监控以及智能语音设备。
当然 WebRTC 除了提供音视频传输功能，还有一个容易被忽略的功能就是数据传输。利用点对点的传输机制，一些开发者创造出了诸如 Webtorrent 以及 PeerCDN 这样的不经过服务器的数据传输网络服务。所以 WebRTC 非常适合用来打造实时通信的应用。
而直播作为当下的热点应用，肯定少不了对于 WebRTC 的使用，而这又要提到 rtmp。
从 RTMP 到 WebRTC从应用角度来讲，受到用户使用习惯的改变，越来越多的直播产品都开始加入视频互通的功能。同时，像视频会议、视频核保一类的应用方式也在不断增加。这影响着技术选型的变迁。
RTMP(Real Time Messaging Protocol) 实时消息传送协议是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。随着直播兴起，很多人都将它用在直播上。
在协议方面，rtmp 完全可以满足直播产品的需求，但由于其相对延时较高，不能满足视频互通的产品需求。于是大家很自然地将目光投向 UDP、QUIC（基于 UDP）一类延时更低的网络协议。
在技术框架方面，由于自研一套符合视频互通要求的通信系统相对复杂，不仅涉及网络传输、前端开发、移动端开发，还要解决音视频编解码中复杂的算法优化，对开发者的技术栈要求很高，所以越来越多的人选择 WebRTC。
目前来看，WebRTC 已经获得了越来越多浏览器厂商及相关技术厂商的支持，应用的前景将会更加广阔。
但是受限于 WebRTC 自身的一些缺憾，一般开发者都不是直接完全使用 WebRTC，而是根据实际场景基于 WebRTC 进行二次开发。WebRTC 本身并不是万能钥匙，不可能一套代码以及接口可以解决所有问题。
如何做二次改造？WebRTC 是一个非常优秀的项目，但如果直接拿来使用也存在以下问题。
第一，WebRTC 使用的是对点对传输，虽然节约了服务器资源的开销，但实际使用时也带来了传输质量的问题，比如跨国以及跨运营商网络之间的传输质量往往很难保证，虽然 webRTC 有优秀的端对端质量控制算法，但在错综复杂的网络条件下，表现也很难让人满意。
第二，WebRTC 在移动端的表现也很难让人满意。早期由于缺少对于 H.264 编解码器的支持，使得移动端很长一段时间只能使用 VP8 软件编解码，导致在中低端手机上的表现较差，加上安卓自身碎片化的属性，如果不针对不同机型做适配，很难有统一的用户体验。
第三，WebRTC 是为 1 对 1 通信场景设计的，如果要实现多人的场景，还是需要借助服务端方案。即使当前有很多开源的 webRTC 服务器实现，一个流媒体中转服务器或者混流服务器的部署以及维护也是非常复杂的。
第四，在 Web 端需要面临不同浏览器之间的兼容性问题。虽然使用 AdapterJS 可以解决不同浏览器之间的接口适配问题，但除此之外依然要面临不同浏览器行为不一致的问题。可以说如果 WebRTC 如果直接拿过来商用的话，几乎是不太可能的，当下普遍的解决方案是自研，根据自身的业务场景进行二次定制开发，或者更简单一点使用第三方 SDK。
WebRTC 的前景未来在实时通信领域，WebRTC 依然是非常重要的一块拼图。
无论是 Web 还是 Native，都非常依赖 WebRTC 提供的音视频引擎，尤其是在 Web 端，几乎所有浏览器厂商的实现都是基于 Google WebRTC 项目。随着 WebRTC 1.0 标准的定稿，各大浏览器的 WebRTC 接口已经基本得到统一。
一直以来，WebRTC 都缺少测试工具。在去年年底，Google 推出了 KITE 开源项目，用于帮助开发者检测 WebRTC 应用在不同浏览器的互通性。对于标准化社区来讲，下一步工作主要会围绕提供一组更完备的测试套件，不仅可以帮助开发者测试 WebRTC 应用在 Web 端、Native 端的互通性与体验，还有助于保证各厂商浏览器 WebRTC 接口功能的一致性，并逐步完善 WebRTC 缺失的功能。
在相关技术方面，QUIC 也进入更多人的视野。对于 WebRTC 来讲，QUIC 可以加速数据通道的连接（至少原理上可行），还可以完全替代 SCTP。但问题是，目前支持 QUIC 的浏览器只有 Chrome 和 Opera。
另一方面，各浏览器也在持续不断地修复问题，对不同硬件设备以及系统平台进行适配，保证 WebRTC 能稳定运行于除主流机型、系统版本以外，更多的设备上。
作者简介毛玉杰，声网 WebRTC 专家，WebRTC Committer