近几年实时音视频通信应用呈现出了大爆发的趋势。在这些实时通信技术的背后，有一项不得不提的技术 ——WebRTC。
前言背景
2021年1月26日，W3C（万维网联盟） 和 IETF （互联网工程任务组） 同时宣布 WebRTC（Web Real-Time Communications，Web 实时通信） 现发布为正式标准，将音视频通信带到Web上任何地方。 这代表着我们未来不会在依赖某些软件或者介质去访问和处理音视频了，映衬着5G的时代，这将会是如虎添翼。
WebRTC 成为 W3C 为应用程序开发定义开放 Web 平台的众多标准之一，具有前所未有的潜力。
其让开发人员能够构建丰富的交互体验，由巨大的数据存储提供动力，可用于任何设备以及环境。
数据汇报
据调研机构GrandViewReseach 的报告显示，预计2025年全球 WebRTC 市场规模将达到 210.23 亿美元，相较 2019 年 23 亿美元的市场规模，5 年的复合年增长率为 43.6％。
本文目标
本系列内容将和大家一起来探讨和介绍的目的是：
WebRTC的概念是什么？WebRTC的发展历程和涉足领域有哪些？
WebRTC的目标和愿景？
为什么WebRTC受到开发者及企业的青睐 ？
未来 WebRTC 又将如何发展？
以及声网 Agora是怎样基于 WebRTC 进行二次开发，又将如何支持 WebRTC NV 版本的？
WebRTC发展历程
2010年，实时通信只能使用专有软件、插件或Adobe Flash 进行实时通信；
2013 年，Chrome和Firefox之间进行了首次跨浏览器视频通话；
2014 年，第一次跨浏览器数据传输得以实现，通过客户端进行实时通信打开了一个新兴的趋势。
2021年，WebRTC的诞生，我们每天都在 Chrome，Mozilla Firefox，Opera，Safari，Edge，iOS 和 Android 的实时互动场景中使用它。
WebRTC涉足领域
在线会议、在线教育、在线面试、在线社交、在线医疗、金融证券在线开户、智能家居等等已经成为了现代人们生活中非常熟悉的一部分，将常见的线下场景转至线上，人们足不出户便能体验上述场景。这些实时互动场景在很大程度上已经改变了我们原本的生活方式。
WebRTC概念定义
WebRTC是一个由 Google、Mozilla、Opera 等发起的开源项目，名称源自「网页即时通信」（Web Real-Time Communication）的缩写。
此外，“WebRTC 在不同场景下包含不同的含义，它既可以代表 Google 开源的 WebRTC 项目，又可以代表 W3C（World Wide Web Consortium-万维网联盟） 工作组制定的 WebRTC 标准，也可以代表浏览器中的 WebRTC 接口，我们将他们统称为 WebRTC技术。”
WebRTC实现
WebRTC由Web实时通信的JavaScript API 和 一组通信协议 构成，支持网络上的任何已连接设备成为Web上潜在的通信端点。成为线上通信及协作服务的基石。
不难看出这项技术最开始的目标是希望为实现自由地在浏览器上进行实时音视频传输做准备的。
多数时候，对于开发者而言WebRTC是一套支持网页浏览器进行实时音视频对话的 W3C Javascript API，它包括了音视频的采集、编解码、网络传输、显示等功能。
几乎所有主流浏览器都支持 WebRTC 标准 API ，因此也让浏览器之间无插件化的音视频互通成为可能， 大大降低了音视频开发的门槛，开发者只需要调用 WebRTC API 即可快速构建出音视频应用。
至此，WebRTC的使用已经超越了最初的核心设计，即在浏览器和其他生态（例如本地应用）中支持视频会议和协作系统。现在需要更多的特性和优化。
WebRTC解决的问题
在没有WebRTC前，对于开发者而言RTC通信的难点主要来自于互联网网络复杂、延时敏感、实时音视频流畅度及清晰度较低以及运营成本较高等。
WebRTC的使命是使丰富、高质量的RTC应用程序能够为浏览器、移动平台和 IoT设备开发，并允许所有人通过一组通用协议进行通信。
-
但这些问题在 WebRTC 出现后都得到了较好的解决：
-
屏蔽了网络模型的差异性
- 不同的NAT、防火墙对媒体 P2P 的建立带来了很大的挑战。而WebRTC 的出现为浏览器提供了端到端的直接通信，使开发者可以轻松地实现这种连接。同时，WebRTC 里面有 P2P 打洞的开源项目 libjingle ,支持 STUN，TURN 等协议。
-
提高传输效率以及降低损耗
- 在早期的RTC技术中，TCP（Transmission Control Protocol-传输控制协议）由于自身机制的缺陷，只能使用 UDP 传输，但这需要开发人员解决重传、乱序等问题。而WebRTC则提供了 NACK，FEC 技术，不再需要通过服务器进行路由，减少了延迟和带宽消耗。直接通信可提高数据传输和文件共享的速度。
-
提高流畅性（优化算法）
- 互联网网络不稳定，特别一些小运营商，在流量使用高峰期往往无法保证足够的带宽。需要一套自适应的算法来应对网络拥塞、平滑发送等问题。WebRTC 中提供了 TCC + SVC + PACER + JitterBuffer 技术支持。
-
语音清晰度优化
- 由于终端设备和环境复杂，会有噪声、回声的干扰，这时候 WebRTC 提供了 3A 算法 + NetEQ，让实时环境中的声音处理及互动体验得到了大幅的提升。
-
提高移植性（以及标准化）
- 对于开发人员或企业而言，使用WebRTC的过程中只需要下载兼容 WebRTC的浏览器并使用，不需要额外的软件、插件或持续的服务器的参与就可以将音视频应用轻松嵌入到任何网站中，并通过 Internet 进行连接，大大节省了开发时间和成本。
- 目前主流的浏览器如 Microsoft Edge、Google Chrome、Mozilla Firefox、Safari、Safari、Opera、Vivaldi 等都已支持 WebRTC。
-
安全性加密机制
- WebRTC作为一项开源技术，可在任何Web浏览器上免费使用，并且不受插件限制。在安全方面，WebRTC 同样做了优化设计：所有 WebRTC 媒体数据都必须经过加密。
-
由于WebRTC并非是一个插件，也不用安装别的插件，因此所有应用都可以在浏览器的沙箱中运行，并不用再额外创建新进程。
也正因为如此， WebRTC 有效地阻止了恶意软件进入用户系统。
在任何实时通信应用程序中，数据传输的过程都有可能会增加安全风险，因此加密是WebRTC的强制性功能，并在所有媒体数据上强制执行。
-
WebRTC使用两种标准化的加密协议：
-
数据报传输层安全性（DTLS）
- 浏览器内置标准化协议。基于传输层协议（TLP）的数据流加密；
- 由于DTLS使用用户数据协议（UDP），因此保留了传输的语义；
- 它是安全套接字层（SSL）的扩展，任何 SSL 协议均可用于保护 WebRTC 数据，从而允许端到端加密。
-
安全实时传输协议（SRTP）
- 用于媒体流加密；
- 它是对实时传输协议（RTP）的扩展，该协议没有任何内置的安全性机制；
- 实时传输协议（RTP）提供加密、完整性保证和消息身份验证。
- SRTP 协议也有它的一些缺点，比如虽然它为 RTP 数据包提供加密，但不对标头进行加密。
- 用于媒体流加密；
-
WebRTC实践案例
由于WebRTC的传输是基于公共互联网，而公共互联网并不是为了实时通信而设计的，因此在网络协议、跨区域带宽、跨运营商、用户设备、网络架构、文档支持等方面都会对WebRTC的开发有牵制，从而会导致实时音视频等传输质量没办法得到有效的保证。
因此，可以说如果 WebRTC 直接拿过来商用的话，几乎是不太可能的，当下普遍的解决方案是自研，根据自身的业务场景进行二次定制开发，或者更简单一点使用第三方 SDK。
W3C WebRTC工作组已经开始研究 WebRTC Next Version Use Cases，规划 WebRTC 的未来，特别是：
在服务器介导的视频会议中的端到端加密
即时处理音视频材料，包括通过机器学习
物联网（例如 IoT 传感器维持长期连接并寻求最小功耗）
WebRTC工作组正对现有及新的用例进行迭代，重点理解全部需求及其优先级。
未来计划
W3C近期开始的 WebTransport 和 Web Codecs 工作预计将低延迟流媒体的优势引入更广大的媒体和娱乐生态系统。
IETF WebTransport (WEBTRANS)和WebRTC Ingest Signaling over HTTPS (WISH) 工作组已经在开展工作，在 IETF 其他工作组的基础上进一步协调、拓展相关工作。
QUIC（定义支持 WebTransport API 开发的新协议）和 HTTPBIS（指定简单、可扩展的、基于 HTTPS 的信令协议），以在广播工具和实时媒体广播网之间建立基于WebRTC 的单向视听会话。
