介绍
WebRTC 是一个目前正在开发的开源项目，旨在提供 Web 应用程序之间实时的、点对点通信。
WebRTC 提供了简单的 JavaScript API，可以帮助开发人员轻松构建具有实时音视频传输功能的 Web 应用程序。 WebRTC 也计划支持手机的原生应用。在 WebRTC 提供的 API 之下，其实隐藏了 WebRTC 底层的实现原理，所以除了使用 API 之外，很有必要了解一下 WebRTC 的底层实现。
本篇文章非常适合初入门 WebRTC 的人，尤其那些对 WebRTC 的工作原理还不了解的人，为了让大家尽可能读懂，因此会尽可能使用简单的术语和类比来详细解释 WebRTC 的底层工作原理。
开始
为了在甲和乙之间建立 WebRTC 连接，需要执行以下两个步骤：
-
找到对方的位置。
-
通知对方设置 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 连接，则需要执行以下操作：
- Peer A使用 ICE 生成它的 ICE候选者。在大多数情况下，它需要 NAT（STUN）的会话遍历实用程序或 NAT（TURN）服务器的遍历使用中继。
- Peer A 将 ICE候选者 和会话描述捆绑到一个对象中。该对象在对等体 A 内存储为本地描述（对等体自己的连接信息），并通过信令机制传送给对等体 B.这部分称为要约。
- 对等体 B 接收该提议并将其存储为远程描述（另一端的对等体的连接信息）以供进一步使用。对等体 B 生成它自己的 ICE候选者和会话描述，将它们存储为本地描述，并通过信令机制将其发送给对等体A.这部分称为答案。 （注：如前所述，步骤2和3中的ICE候选人也可以单独发送）
- 对等体 A 从对等体 B 接收答案并将其存储为远程描述。 这样，两个对等体都具有彼此的连接信息，并且可以通过 WebRTC 成功开始通信！
Agora SDK 使用体验征文大赛 | 掘金技术征文，征文活动正在进行中