前言

近几年实时音视频通信利用呈现出了大暴发的趋势。在这些实时通信技术的背地，有一项不得不提的技术——WebRTC。

往年 1 月，WebRTC 被 W3C 和 IETF 公布为正式规范。据调研机构 GrandViewReseach 的报告显示，预计 2025 年寰球 WebRTC 市场规模将达到 210.23 亿美元，相较 2019 年 23 亿美元的市场规模，5 年的复合年增长率为 43.6%。

本系列内容将和大家一起来探讨，为什么 WebRTC 受到开发者及企业的青眼？将来 WebRTC 又将如何倒退？以及声网 Agora 是怎么基于 WebRTC 进行二次开发，又将如何反对 WebRTC NV 版本的？

WebRTC 能够被看作是一个不须要装置任何插件或者下载任何额定程序就能运行的浏览器原生实时通信伎俩。不同的客户端通过（雷同或不同）浏览器跳转到同一个 URL 就能实现实时互通、看见彼此。但这只是“上帝视角”的说法，其中蕴含的技术框架和实现细节远没那么简略。

基本概念

在咱们开始探讨 WebRTC 是如何工作之前，先来理清几个要害的技术概念。

P2P

能够实现实时点对点音视频（即多媒体）通信是 WebRTC 最为显著的一个特色。为了通过 Web 浏览器进行通信，要求每个人的 Web 浏览器都须要批准“开始接通”，晓得对方的网络定位，并且还须要绕过网络安全和防火墙爱护并实时传输所有多媒体通信才可能得以实现。

在基于浏览器的对等通信中，如何定位和建设与另一台计算机的 Web 浏览器的网络连接并进行高效数据传输是其最大的挑战之一。

当你想要拜访一个网站时，个别都是间接输出网址或者点击连贯跳转来进行页面查看。在这个过程中，其实是你向通过提供网页（HTML，CSS 和 JavaScript）进行响应的服务器收回了一个申请。而收回这个拜访申请的要害是你向已知且易于定位的服务器（通过 DNS）收回 HTTP 申请，并取得响应（即网页）。

乍看之下，如同这个问题也没那么难，但咱们举个例子来看看：当初假如我想和共事进行视频沟通。那咱们怎么能力发出请求并理论间接接管到对方的音频和视频数据呢？

上述场景中呈现的问题就能够通过 P2P（点对点传输）技术来解决，而 WebRTC 自身就是基于点对点（Peer-to-Peer）连贯的，其中的 RTCPeerConnection 就是负责建设 P2P 连贯以及传输多媒体数据的 API。

防火墙和 NAT 穿透

日常生活中，咱们大都是通过工作或家庭网络进行互联网拜访，这时候咱们的设施通常是在防火墙和网络拜访转换设施（NAT）的前面，因而并没有调配动态的公共 IP 地址。更进一步来看，NAT 设施会将防火墙外部的公有 IP 地址转换为面向公众的 IP 地址，以确保对可用公共 IP 地址的安全性和 IPv4 限度。

让咱们带入上一个例子来看看，思考到 NAT 设施的参加，我怎么能力晓得共事的 IP 地址，将音频和视频数据发送到这个地址，同样，他怎么晓得我的 IP 地址能够将音频和视频数据发送回去? 这就是 STUN（Session Traversal Utilities for NAT，NAT 会话穿梭应用程序）和 TURN（Traversal Using Relays around NAT，中继穿透 NAT）服务器要解决的问题.

为了使 WebRTC 技术失常工作，首先会向 STUN 服务器申请一个面向公众的 IP 地址。如果这个申请失去了回应，并且咱们收到了面向公众的 IP 地址和端口，就能够通知其他人如何间接和咱们建设连贯。而他人也能够应用 STUN 或 TURN 服务器执行雷同的操作。

信令 & 会话

因为存在 NAT，WebRTC 不能间接与对端建设连贯，因而设施之间须要通过信令服务进行发现和协商以进行实时的音视频替换。上述的网络信息发现过程是更大层面上的信令主题之一，在 WebRTC 的状况下，它是基于 JavaScript 会话建设协定（JSEP）规范的。信令波及网络发现和 NAT 穿透，会话创立和治理，通信安全和协调以及错误处理等。

WebRTC 并没有规定信令必须应用何种实现，这是为了让开发者所用技术和协定能够更加灵便。

目前业界应用较多的是 WebSocket + JSON/SDP 的计划。其中 WebSocket 用来提供信令传输通道，JSON/SDP 用来封装信令的具体内容：

WebSocket 建设在 TCP 之上，提供了长连贯的能力，解决了 HTTP 仅反对半双工，Header 信息冗余等低效问题。WebSocket 容许服务器和客户端在任何工夫推送音讯，而与先前的申请没有任何关系。应用 WebSockets 的一个显着劣势是，简直每个浏览器都反对 WebSockets。

JSON 是一种 Web 畛域常见的序列化格局，用来封装一些用户自定义的信令内容。（实质是序列化工具，所以相似 Protobuf/Thrift 这样的计划也齐全可行）。

SDP（Session Description Protocol）是一个会话描述性协定，用来封装流媒体能力协商的信令内容，两个 WebRTC 代理会将建设连贯所需的所有状态通过此协定来分享。

如果概念性的内容不太好了解，那咱们能够把它设想成一个日常交换过程：

当咱们筹备和一个陌生人进行交换或者一个陌生人心愿退出你的聊天，那当你或者对方收回了这个信息，不论你是承受还是回绝都须要与对方替换这个信息。你们只有交换后才有可能能获更多信息来判断是否你们能够一起欢快地聊天。而帮你疾速汇总这些信息的就是 SDP（会话形容协定），它蕴含了例如应用的是什么代理，它反对什么硬件，它想替换什么类型的媒体等信息。

那当两个人想要开始聊天时总须要有一个人先闭口👇👇👇

Me：我讲中文，17 岁，高中，喜爱打篮球，当初想学英文，所以想跟你聊聊天看看能不能帮忙我进步英文（即 Offer SDP）。

Peer：我讲中文，23 岁，工作，喜爱打篮球，英文个别，不肯定能帮到你但咱们能够一起打球（即 Answer SDP）。

这个替换信息、相互了解的过程目标是为了确认咱们是否能够进行下一步交换，或者咱们齐全没方法进行交换。谁先收回信息并不重要，重要的是不论谁收回了信息即使是出于礼貌咱们也须要给予对方一个回应，这样这个对话才可能无效。

相干协定

协定是个规范 / 约定，而协定栈是协定的实现，能够了解为代码、函数库、供下层利用调用。WebRTC 中的协定栈是曾经写好了底层的代码，合乎协定规范，提供给开发者一个功能模块进行调用的。开发者需只须要关怀应用逻辑，数据从哪里到哪里，怎么存储，解决零碎里设施之间的通信程序等即可。

WebRTC 利用多种规范和协定，包含数据流，STUN / TURN 服务器，信令，JSEP，ICE，SIP，SDP 等。

                WebRTC 协定栈

信令

• 应用层：WebSocket/HTTP
• 传输层：TCP
  媒体流
• 应用层：RTP/RTCP/SRTP
• 传输层：SCTP/QUIC/UDP
  平安
• DTLS：用于协商媒体流的密钥
• TLS：用于协商信令的密钥
  ICE（交互式连贯建设）
• STUN
• TURN
  其中 ICE（Interactive Connectivity Establishment，互动式连贯建设），STUN 和 TURN 是建设和保护端到端连贯所必须的。DTLS 用于爱护对端的数据传输。SCTP 与 SRTP 则被用于为多路复用、提供拥塞和流控制，以及局部在 UDP 之上提供局部牢靠的传递和其余附加服务。

根本架构

通过以上介绍，置信大家对于 WebRTC 中的一些要害概念都有了了解。那接下来，让咱们一起来看看 WebRTC 的最要害的根底组件架构，这对于咱们后续了解 WebRTC 的工作原理同样非常重要。

根本组件架构

WebRTC 的组件架构分为两层：应用层和核心层。上图中的绿色局部显示的是 WebRTC 提供的外围性能，而深紫色局部是浏览器提供的 JS 的 API（即浏览器对 WebRTC 核心层 C++ API 做了一层封装，封装成了 JS 接口）。

图片最下面的浅紫色指入箭头是下层利用，能够在浏览器中间接拜访浏览器提供的 API，最终调用到核心层。

而对于外围性能层，次要是有 4 局部：

• C++ API 层

API 数量较少，次要是 PeerConnection。而 PeerConnection 的 API 又蕴含传输品质、传输品质报告、各种统计数据、各种流等。（设计技巧：对于下层来说，提供的 API 简略，不便应用层开发；外部比较复杂。）

• Session 层（上下文管理层）

如利用创立了音频、视频、非音视频的数据传输，都能够在 Session 层做解决，做治理相干的逻辑。

• 引擎层 / 传输层（最重要、外围局部）

  这部分分为 3 个不同的模块：Voice Engine（音频引擎）、Video Engine（视频引擎）以及 Transport（传输模块），可用作音视频传输解耦。

  Voice Engine（音频引擎） 蕴含了如音频采集、音频编解码、音频优化（包含降噪、回声打消等）等一系列的音频性能。

  • ISAC/ILBC 编解码；
  • NetEQ（Buffer）网络适配、防止网络抖动；
  • 回音打消（echo canceler）：音视频重点，决定产品质量，WebRTC 里提供了相干十分成熟的算法，开发时只须要调节参数即可；降噪（Noise Reduction）、自动增益。

  *Video Engine（视频引擎）* 蕴含了如视频采集、视频编解码、依据网络抖动动静批改视频传输品质、图像处理等。

  • VP8、openH264 编解码；

  • Video jitter buffer：避免视频抖动；

    • Image enhancements：图像增强。

    Transport（传输模块） 在 WebRTC 中，对所有的音频视频进行接管与发送，传输层包含了透露的检测、网络链路品质检测，依据状况估算网络带宽，依据网络带宽进行音视频、文件等非音视频的传输。

    • 底层用的 UDP，下层用的 SRTP（即平安的、加密后的 RTP）；
    • Multiplexing：多个流复用同一个通道；
    • P2P 层（包含 STUN+TURN+ICE）。

• 硬件层

  • 视频采集、渲染；
  • 音频采集；
  • 网络 IO 等。

WebRTC 的核心层中是没有视频的渲染的，所有的渲染都须要浏览器层本人做。

工作原理

WebRTC 中其实波及了许多简单的技术议题，比方音频采集、视频采集、编解码处理器等。因为咱们本章内容是心愿能够为大家出现一个简略易懂的 WebRTC 工作流程是，因而对于更多 WebRTC 技术的实现细节在本章咱们先不一一探讨，如果感兴趣的小伙伴可点击进入 #WebRTC# 专栏自行查看。

咱们在第一局部的内容 Why WebRTC|前世今生中有提到“WebRTC 对于开发者而言是一套反对网页浏览器进行实时音视频对话的 W3C Javascript API”，这些 JavaScript API 理论产生并传输用于实时通信的多媒体数据。

WebRTC 次要的 API 包含 Navigator.getUserMedia（关上录音和摄像头），RTCPeerConnection（创立并协商对等连贯）和 RTCDataChannel（代表对等之间的双向数据通道）。

对于 WebRTC 的工作流程，咱们从“如何实现一个 1 对 1 通话”场景来看可能会更直观一些：

1. 单方先调用 getUserMedia 关上本地摄像头；
2. 向信令服务器发送退出房间申请；
3. Peer B 接管到 Peer A 发送的 offer SDP 对象，并通过 PeerConnection 的 SetLocalDescription 办法保留 Answer SDP 对象并将它通过信令服务器发送给 Peer A。
4. 在 SDP 信息的 offer/answer 流程中，Peer A 和 Peer B 曾经依据 SDP 信息创立好相应的音频 Channel 和视频 Channel，并开启 Candidate 数据的收集，Candidate 数据（本地 IP 地址、公网 IP 地址、Relay 服务端调配的地址）。
5. 当 Peer A 收集到 Candidate 信息后通过信令服务器发送给 Peer B。同样的过程 Peer B 对 Peer A 也会再发送一次。

这样 Peer A 和 PeerB 就相互交换了媒体信息及网络信息，如果能达到统一 (找到交加)，就能够开始通信了。

为了帮忙大家更好地理解 WebRTC 技术，咱们最新一期的「Agora talk」，邀请到了来自声网 Agora WebRTC 团队的工程师。

他们将会围绕“基于 Web 引擎扩大技术的 RTC 混合开发框架实际”以及“下一代 WebRTC — 实时通信的瞻望”2 个主题和大家分享探讨更多有用又乏味技术细节。

下一章节咱们将会为大家带来对于 WebRTC 以后开发难点、罕用开发工具以及在 Agora Web SDK 中咱们做了哪些优化等内容。

敬请期待～