1、前言
有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年，这并非没有根据。就在去年（2017年），WebRTC 1.0 标准草案出炉（实际上WebRTC标准草案的早期版本早在2011年就已经发布，WebRTC并非一夜之间就出现的技术），并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了，或许门槛如此之高的实时音视频技术终有白菜化的那一天。
补充：WebRTC标准草案的版本演进历史，请点击进入。
学习交流：
- 即时通讯开发交流3群：185926912[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-1631-1-1.html）
2、相关文章
《开源实时音视频技术WebRTC的现状》
《简述开源实时音视频技术WebRTC的优缺点》
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《WebRTC实时音视频技术的整体架构介绍》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《WebRTC实时音视频技术基础：基本架构和协议栈》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《实时通信RTC技术栈之：视频编解码》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
3、实时通信技术的广阔前景
根据腾讯全球合作伙伴大会上发布的《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 背后的故事。
4、WebRTC是什么来头？
说到 WebRTC，我们不得不提到 Gobal IP Solutions，简称 GIPS。这是一家 1990 年成立于瑞典斯德哥尔摩的 VoIP 软件开发商，提供了可以说是世界上最好的语音引擎。相关介绍详见《访谈WebRTC标准之父：WebRTC的过去、现在和未来》。
Skype、腾讯 QQ、WebEx、Vidyo 等都使用了它的音频处理引擎，包含了受专利保护的回声消除算法，适应网络抖动和丢包的低延迟算法，以及先进的音频编解码器。
Google 在 Gtalk 中也使用了 GIPS 的授权。Google 在 2011 年收购了 GIPS，并将其源代码开源，加上在 2010 年收购的 On2 获取到的 VPx 系列视频编解码器（详见《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》），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 接口，无需安装任何插件，即可实现音视频互通。
5、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，所有浏览器之间无插件化的音视频互通已经成为一种可能。
即时通讯网注：为什么苹果等商业公司坚持H.264标准？这其实是以苹果为代表的商业公司或联盟和谷歌之间的音视频编码标准之争，详见《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》，但业界普遍认为至少目前看来H.264标准（下一代被称为H.265）各方面要优于VP8（下一代是VP9），具体请见《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》。
越来越多的终端设备上，无需借助任何插件或者 native 应用，通过打开网页链接，即可进行高质量的音视频通话，应用开发者也无需关注音视频引擎实现细节，大大节约了开发成本。
6、WebRTC广泛的适用场景
WebRTC 适用的场景可以说是非常广泛，很多行业结合实时通信都可以创造出非常有意思的场景，传统的实时通信应用场景主要是在视频会议、视频面试、VoIP 通话、呼叫中心，产品如 WebEx、Skype 等。
当下比较火的场景主要集中在社交、游戏、体育、电视、相亲类的直播，以及互动连麦、在线教育、在线医疗、金融证券在线开户、智能硬件（如无人机）、智能家居设备如摄像头监控以及智能语音设备。
当然 WebRTC 除了提供音视频传输功能，还有一个容易被忽略的功能就是数据传输。利用点对点的传输机制，一些开发者创造出了诸如 Webtorrent 以及 PeerCDN 这样的不经过服务器的数据传输网络服务。所以 WebRTC 非常适合用来打造实时通信的应用。
而直播作为当下的热点应用，肯定少不了对于 WebRTC 的使用，而这又要提到 rtmp。
7、从 RTMP 到 WebRTC
从应用角度来讲，受到用户使用习惯的改变，越来越多的直播产品都开始加入视频互通的功能。同时，像视频会议、视频核保一类的应用方式也在不断增加。这影响着技术选型的变迁。
RTMP(Real Time Messaging Protocol) 实时消息传送协议是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。随着直播兴起，很多人都将它用在直播上。
在协议方面，rtmp 完全可以满足直播产品的需求，但由于其相对延时较高，不能满足视频互通的产品需求。于是大家很自然地将目光投向 UDP、QUIC（基于 UDP）一类延时更低的网络协议。
在技术框架方面，由于自研一套符合视频互通要求的通信系统相对复杂，不仅涉及网络传输、前端开发、移动端开发，还要解决音视频编解码中复杂的算法优化，对开发者的技术栈要求很高，所以越来越多的人选择 WebRTC。
目前来看，WebRTC 已经获得了越来越多浏览器厂商及相关技术厂商的支持，应用的前景将会更加广阔。
但是受限于 WebRTC 自身的一些缺憾，一般开发者都不是直接完全使用 WebRTC，而是根据实际场景基于 WebRTC 进行二次开发。WebRTC 本身并不是万能钥匙，不可能一套代码以及接口可以解决所有问题。
更多关于RTMP的知识，请见《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》、《基于RTMP协议的流媒体技术的原理与应用（技术论文）[附件下载]》。
8、WebRTC很优秀，但当前并非完美
WebRTC 是一个非常优秀的项目，直接拿来使用也存在以下问题，我们简单总结一下：
第一：WebRTC 使用的是对点对传输，虽然节约了服务器资源的开销，但实际使用时也带来了传输质量的问题，比如跨国以及跨运营商网络之间的传输质量往往很难保证，虽然 webRTC 有优秀的端对端质量控制算法，但在错综复杂的网络条件下，表现也很难让人满意；
第二：WebRTC 在移动端的表现也很难让人满意。早期由于缺少对于 H.264 编解码器的支持，使得移动端很长一段时间只能使用 VP8 软件编解码，导致在中低端手机上的表现较差，加上安卓自身碎片化的属性，如果不针对不同机型做适配，很难有统一的用户体验；
第三：WebRTC 是为 1 对 1 通信场景设计的，如果要实现多人的场景，还是需要借助服务端方案。即使当前有很多开源的 webRTC 服务器实现，一个流媒体中转服务器或者混流服务器的部署以及维护也是非常复杂的；
第四：在 Web 端需要面临不同浏览器之间的兼容性问题。虽然使用 AdapterJS 可以解决不同浏览器之间的接口适配问题，但除此之外依然要面临不同浏览器行为不一致的问题。可以说如果 WebRTC 如果直接拿过来商用的话，几乎是不太可能的，当下普遍的解决方案是自研，根据自身的业务场景进行二次定制开发，或者更简单一点使用第三方 SDK。
不可否认，WebRTC确实很优秀，但目前来说也并非完美，更多这方面的分析和总结请参见《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》、《简述开源实时音视频技术WebRTC的优缺点》。
9、展望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。（有关QUIC协议的基本介绍和应用案例，请见《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》、《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》）
另一方面，各浏览器也在持续不断地修复问题，对不同硬件设备以及系统平台进行适配，保证 WebRTC 能稳定运行于除主流机型、系统版本以外，更多的设备上。
附录：更多实时音视频技术资料
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》
《实时语音聊天中的音频处理与编码压缩技术简述》
《网易视频云技术分享：音频处理与压缩技术快速入门》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《声网架构师谈实时音视频云的实现难点(视频采访)》
《浅谈开发实时视频直播平台的技术要点》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡》
《如何用最简单的方法测试你的实时音视频方案》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《移动端实时音视频直播技术详解（一）：开篇》
《移动端实时音视频直播技术详解（二）：采集》
《移动端实时音视频直播技术详解（三）：处理》
《移动端实时音视频直播技术详解（四）：编码和封装》
《移动端实时音视频直播技术详解（五）：推流和传输》
《移动端实时音视频直播技术详解（六）：延迟优化》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《IM实时音视频聊天时的回声消除技术详解》
《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》
《如何优化传输机制来实现实时音视频的超低延迟？》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《Android直播入门实践：动手搭建一套简单的直播系统》
《网易云信实时视频直播在TCP数据传输层的一些优化思路》
《实时音视频聊天技术分享：面向不可靠网络的抗丢包编解码器》
《P2P技术如何将实时视频直播带宽降低75%？》
《专访微信视频技术负责人：微信实时视频聊天技术的演进》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《近期大热的实时直播答题系统的实现思路与技术难点分享》
《福利贴：最全实时音视频开发要用到的开源工程汇总》
《七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！》
《实时音视频聊天中超低延迟架构的思考与技术实践》
《理解实时音视频聊天中的延时问题一篇就够》
《实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序》
《写给小白的实时音视频技术入门提纲》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1631-1-1.html）