WebRTC 的工做原理解析 | 掘金技术征文

介绍

WebRTC 是一个目前正在开发的开源项目，旨在提供 Web 应用程序之间实时的、点对点通讯。

WebRTC 提供了简单的 JavaScript API，能够帮助开发人员轻松构建具备实时音视频传输功能的 Web 应用程序。 WebRTC 也计划支持手机的原生应用。在 WebRTC 提供的 API 之下，其实隐藏了 WebRTC 底层的实现原理，因此除了使用 API 以外，颇有必要了解一下 WebRTC 的底层实现。

本篇文章很是适合初入门 WebRTC 的人，尤为那些对 WebRTC 的工做原理还不了解的人，为了让你们尽量读懂，所以会尽量使用简单的术语和类比来详细解释 WebRTC 的底层工做原理。

开始

为了在甲和乙之间创建 WebRTC 链接，须要执行如下两个步骤：

1. 找到对方的位置。

2. 通知对方设置 WebRTC 链接。

第1步：找到对方

WebRTC 里找对方的过程，能够想象成拨打电话同样，当你须要经过电话与某人通话时，须要输入对方的电话号码，而后才能与该人联系。当有人想给你打电话时，也须要一样的过程。在打电话时，咱们使用电话号码做为用户的标识，而后在电信系统进一步使用该标识来定位用户。

可是，Web 应用程序没法相互拨打和呼叫。由于世界上有不少个浏览器，并且一个系统里能够同时存在好多个浏览器，浏览器也没有像电话号码同样的惟一 ID，虽然没有惟一的 ID，可是，浏览器所在的系统有一个惟一的 ID，就是 IP 地址，这个 IP 地址能够用来定位。

可是，这个过程并不那么容易。由于，大多数状况下，这些系统都位于网络地址转换（NAT）设备以后。对于可用的公共 IP 地址的安全性和 IPv4 有限制，须要 NAT 设备。 NAT 设备为本地网络中的系统分配专用 IP 地址。此私有 IP 地址仅在本地网络中有效且可见，而且不能用于接受来自外部世界的通讯，由于网络外的系统不知道网络内的设备的公共 IP。

因为 NAT 设备的参与，想要对等体不知道它本身的公共IP地址，由于它被NAT分配的私有IP地址掩盖。所以，它没法与另外一个对等方共享其公共IP地址以接受链接。更易懂的是，若是您但愿有人给您打电话，您须要将您的电话号码提供给其余人。可是，在NAT的存在下，它就像住在一个酒店，其房间的电话号码是隐藏在外面的世界，来到酒店的电话在接待到处理，并根据要求进一步重定向到您的房间。这种间接形式的链接不是用于对等链接技术。

为了克服这个问题，咱们使用称为 ICE（交互式链接创建）的协议。 ICE 的工做是找到链接两个对等体的最佳路径。 ICE 能够执行直接链接，即在没有 NAT 的状况下以及间接链接，即存在 NAT 时。 ICE 框架为咱们提供了 ICE候选者 。 ICE候选者 只不过是包含咱们本身的公共 IP 地址，端口号和其余链接相关信息的对象。

在没有 NAT 的状况下，ICE 很是简单，由于对等体的公共 IP 地址随时可用。可是，在存在 NAT 的状况下，ICE 依赖于称为会话遍历实用程序的实体用于 NAT（STUN）和/或遍历使用NAT周围的中继（TURN）。

STUN 服务器基本上容许对等体找到它本身的公共 IP 地址。须要知道本身的公共 IP地址的对等体向 STUN 服务器发送请求。 STUN 服务器回复该对等体的公共 IP 地址。如今能够与其余同伴共享此公共地址，以便他们能够找到您。可是，若是对等体位于复杂的 NAT 或防火墙以后，即便 STUN 也没法找到并向请求对等体提供其 IP地址。在这种状况下，ICE 依靠 TURN 创建链接。顾名思义，TURN 是一个中继服务器，当两个对等体之间没法直接链接时，它能够做为传输数据，音频，视频的媒介。

STUN 服务器仅在查找公共IP的过程当中涉及。一旦创建了 WebRTC 链接，全部进一步的通讯都经过 WebRTC 进行。可是，在 TURN 的状况下，即便在设置了 WebRTC链接以后，也须要 TURN 服务器。

但因为STUN的限制，咱们必须依赖它。 STUN 服务器的成功率只有 86％。

第2步：通知对等方设置 WebRTC 链接

如今咱们已经得到了 ICE候选人，下一步是将这些候选人发送给咱们但愿链接的同伴。与候选人一块儿，会话描述如会话信息，时间描述，媒体描述被发送。 ICE候选者和会话描述被捆绑在对象内并使用 SDP（会话描述协议）传送。在某些状况下，ICE候选者不会与会话描述捆绑在同一个对象中，而是单独发送，这被称为Trickle ICE。

在创建链接时，咱们须要将信息“发送”给其余同行。可是，当咱们只知道发件人的 IP地址而且不知道接收对等方的 IP 地址时，如何转移候选人和会话描述？因为WebRTC 链接还没有创建，这些信息经过什么媒介传输？

全部这些问题的答案都在于一个称为信号机制的概念。在创建 WebRTC 链接以前，咱们须要一些介质来在对等体之间传输上述信息，并让它们知道如何为 WebRTC 链接定位和链接。这是信号机制出现的地方。顾名思义，信令机制在打算链接的两个对等体之间交换链接信号（ICE候选，会话描述等）。

WebRTC 没有定义任何实现这种信令机制的标准，而是让开发人员建立一个他选的机制。交换信息的信令机制能够经过简单地将信息复制粘贴到各个对等体中或经过使用诸如 WebSockets，Socket.io，Server Side Events 等通讯信道来实现。简而言之，信令机制只是一种模式。在对等体之间交换链接相关信息，以便对等体能够相互识别并使用 WebRTC 进一步开始通讯。

快速回顾

让咱们在回顾一下整个过程，以便更好地理解。

若是假设，对等体 A 想要与对等体 B 创建 WebRTC 链接，则须要执行如下操做：

1. Peer A使用 ICE 生成它的 ICE候选者。在大多数状况下，它须要 NAT（STUN）的会话遍历实用程序或 NAT（TURN）服务器的遍历使用中继。
2. Peer A 将 ICE候选者 和会话描述捆绑到一个对象中。该对象在对等体 A 内存储为本地描述（对等体本身的链接信息），并经过信令机制传送给对等体 B.这部分称为要约。
3. 对等体 B 接收该提议并将其存储为远程描述（另外一端的对等体的链接信息）以供进一步使用。对等体 B 生成它本身的 ICE候选者和会话描述，将它们存储为本地描述，并经过信令机制将其发送给对等体A.这部分称为答案。 （注：如前所述，步骤2和3中的ICE候选人也能够单独发送）
4. 对等体 A 从对等体 B 接收答案并将其存储为远程描述。 这样，两个对等体都具备彼此的链接信息，而且能够经过 WebRTC 成功开始通讯！

Agora SDK 使用体验征文大赛 | 掘金技术征文，征文活动正在进行中