编者按：有人说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接口，无需安装任何插件，即可实现音视频互通。

WebRTC标准掀起的影响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

(责任编辑：李俊勇)