WebRTC 基础知识详解

前言

WebRTC 近几年发展尤其迅速，例如比较火的直播带货，疫情期间的线上直播课，远程视频会议，实时人脸识别等等，都有它的身影。基于此，很多小伙伴想学 WebRTC 知识，但网上资料大多比较零散，讨论的方向也不一样，为了给想学习 WebRTC 的读者一份系统的学习资料，遂有了本文。看完该篇文章你就会对 webrtc 有一个清晰的认识。

WebRTC 简介

WebRTC（Web Real-Time Communication）是 Google 开源的一个互联网浏览器间实时通信的平台，同时，它提供了视频会议的核心技术，包括音视频的采集、编解码、网络实时传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。WebRTC 是目前音视频通话主流开发框架，在不涉及源码修改、功能扩展、模块抽取的情况下，使用 webrtc 仅需要少量代码即可实现常规的 1 对 1 音视频通话功能。

WebRTC 框架介绍

WebRTC框架图

（1） 紫色部分是 Web 应用开发者 API 层

（2） 蓝色实线部分是面向浏览器厂商的 API 层

（3） 蓝色虚线部分浏览器厂商可以自定义实现

注：作为开发者我们重点关注紫色部分 Web API 层，并且需要重点掌握 1）MediaStream 类：该类通过 getUserMedia 接口获取，允许访问输入设备如摄像头来获取媒体流。2）RTCPeerConnection 类：允许用户在两个浏览器间直接通讯。

Your Web App

Web 开发者开发的程序，Web 开发者可以基于集成 WebRTC 的浏览器提供的 web API 开发基于视频、音频的实时通信应用。

Web API

面向第三方开发者的 WebRTC 标准 API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的 web 应用。

WebRTC Native C++ API

本地 C++ API 层，使浏览器厂商容易实现 WebRTC 标准的 Web API，抽象地对数字信号过程进行处理。

Transport / Session

传输/会话层。

VoiceEngine

音频引擎是包含一系列音频多媒体的处理框架。

VideoEngine

VideoEngine 是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

WebRTC 发展前景

WebRTC 虽然介绍里说的是基于浏览器的通信平台，但它其实并不受限于传统互联网应用或浏览器的终端运行环境。无论终端运行环境是浏览器、桌面应用、移动设备（Android 或 iOS）还是 IoT 设备，只要 IP 能连接并且符合 WebRTC 规范就可以互相通信。这让智能终端上 App 的实时通信能力得到了极大的提升，同时也打开了许多对于实时交互性要求较高的应用场景的想象空间，比如前言里提到的远程视频会议，实时人脸识别等等都是其合适的应用领域。

1 对 1 音视频通话基础

在讲解使用 WebRTC 进行音视频通话原理之前，我们需要先来了解几个在介绍音视频通话原理过程中会使用到的专业名词。

媒体协商(SDP：Session Description Protocol)

视频的编解码有多种方式，假设上图中 Peer-A 要与 Peer-B 进行通话，必须要保证两端都能正确的编解码，

那么我们就只能取它们的交集 H264 格式。在 WebRTC 中 SDP 就是用来描述上述这类信息的协议。参与音视频通信的双方必须先交换 SDP 信息，这种交换过程我们把它叫做“媒体协商”。

 网络协商

同样 Peer-A 要与 Peer-B 进行音视频通话的话，除了需要媒体协商，还需要有一条双方都能访问的链路。图中 peer-A 具有公网 ip 以及 192 网段的内网环境，而 peer-B 没有公网环境，只有 192、198 二个内网地址，因此它们可以使用公用的 192 网段来通讯。我们把参与音视频通信过程中交换的网络相关信息的过程叫做“网络协商”。

信令服务器

媒体协商与网络协商都是基于双方建立连接后，那么双方如何建立连接呢？这时候就用到信令服务器（Signal Server）了，一般搭在公网或者两端都可以访问到的局域网中。

图中 2 个浏览器端的上层，可以抽象出一层信令服务器（可以是 1 台或多台），如果 2 端的浏览器都能访问某个公共的网络环境，比如公网，那么就可以让它们都连到这台公用的信令服务器上进行点对点连接。如下图

如果没有公共的网络环境，那么就需要 2 端各搭一组服务器 signal serverA 和 signal serverB，然后这两组服务器借助信令服务器实现互通，就可以实现上面提到的 SDP 信息及网络信息的交换了。如下图

网络地址转换(NAT：Network Address Translation)

我们在上图中的实际情况(无法访问公网)下进行网络通信时，需要通过 NAT 进行网络穿透，来实现两台局域网设备连接到公网的信令服务器上。转换原理如下图

在 NAT 进行转换时，需要使用到 STUN 和 TURN。

STUN(Simple Traversal of UDP Through NATs)

简单的用 UDP 穿透 NAT，是个轻量级的协议，是基于 UDP 的完整的穿透 NAT 的解决方案。它的作用是使位于 NAT 后的客户端找出自己的公网 IP 地址与端口号，这些信息被用来在两个同时处于 NAT 路由器之后的主机之间创建 UDP 通信。

总结来说 STUN 的作用就是给无法在公网环境下的视频通话设备分配公网 IP，这样两台设备就可以在公网 IP 中进行通话了。STUN 工作原理如下图

STUN 并不是每次都能成功的为需要 NAT 通话的设备分配 IP 地址，而 TURN 可以解决这个问题。

TURN(Traversal Using Relays around NAT)

使用中继穿透 NAT，是 STUN 的一个扩展。如果 STUN 不能成功的为需要 NAT 通话的设备分配 IP 地址，就需要公网的服务器作为一个中继，对客户端的数据进行转发，这个转发的协议就是 TURN。TURN 工作原理如下图

使用这种方式在进行音视频通话时，带宽由服务器来承担，本地带宽压力较小。

ICE(Interactive Connectivity Establishment)

翻译为互动式连接建立，ICE 不是一种协议，它是一个框架，整合了 STUN 和 TURN，使各种 NAT 穿透技术可以实现统一。当穿越网络时，ICE 会先尝试 STUN，查出自己位于哪种类型的 NAT 之后以及 NAT 为某一个本地端口所绑定的 Internet 端端口从而建立 UDP 连接，如果失败了 ICE 就会再尝试 TCP(先尝试 HTTP，再尝试 HTTPS)，如果仍然失败就使用中继的 TURN 服务器。因此，ICE 可以实现在未知网络拓扑结构中实现的设备互连。另外，由于该技术不需要为 VoIP 流量手动打开防火墙，所以也不会产生潜在的安全隐患。

1 对 1 音视频通话实现原理

在看完 1 对 1 音视频通话基础后再来看通话实现原理就比较简单了。具体步骤如下：

1、双方先调用 getUserMedia 打开本机摄像头。

2、向信令服务器发送加入房间请求。

3、信令服务器通知本人加入成功，同时向其它人广播加入消息。

4、二端开始创建 peerConnection 连接。

5、peerA 端创建 offer，同时将 SDP 保存到本机(setLocalDescription)，并通过信令服务器传递到 peerB。

6、peerB 在 setLocalDescription 后，会异步触发“候选网络链路”收集，大致是通过 Stun 确定自己所有的 NAT 映射出口，如果 Stun 返回 NAT 是“对称型”的，基本上就没法穿透了，会再通过 Turn 拿到中继 reply 地址，并通过信令服务器，将网络候选链路信息发到 peerA，即开始网络协商。

7、peerA 收到的 peerB 的 SDP 后，开始回应(createAnswer)，仍然通过信令服务器，将 SDP 发送到 peerB

8、同时 peerA 也会开始网络候选链路的收集，并将自己的网络信息，通过信令服务器，发到 peerB。

这样 peerA，peerB 就相互交换了媒体信息及网络信息，如果能达到一致(找到交集)，就可以开始通讯了。

 结语

笔者尽量对 WebRTC 基础技术要点做了比较详细的介绍，一些相关的技术细节需要读者自己做进一步的学习。另外由于本文旨在讲解 webrtc 基础，并没有开发代码与技术细节。有些技术观点也不一定非常准确，希望读者谅解。如果有问题欢迎留言交流。

参考：

https://baike.baidu.com/item/WebRTC

https://www.cnblogs.com/yjmyzz/p/webrtc-basic.html

https://www.jianshu.com/p/258e7d8be2ba

https://www.cnblogs.com/mlgjb/p/8243690.html