Web 实时通信技术WebRTC
Web 实时通信 (WebRTC) 是目前正在开发的开源项目，主要目的是提供 Web 应用程序之间的实时、对等通信。
WebRTC 是一个开源项目，允许向应用程序添加点对点实时通信功能。
WebRTC 首次发布时，针对的是在 Chrome 上运行的 Web 应用程序。但是现在在几乎所有流行的浏览器、Android、iOS 和桌面平台上都可以运行 WebRTC 应用程序。
WebRTC 提供简单的 JavaScript API，开发人员轻松构建具有实时音频、视频和数据传输功能的 Web 应用程序。WebRTC 的最新发展也使其能够整合到本机应用程序中。由于 API 背后发生了很多事情，因此了解 WebRTC 的概念和工作原理以充分利用该技术非常重要。
WebRTC有什么优势？
如果需要创建实时通信的应用程序或平台，则需要考虑很多因素，例如：
- 通信质量（延迟、媒体质量、稳定性等）
- 访问设备硬件（相机、麦克风等）
- 网络使用情况（带宽使用情况、网络限制等）
- 视频和音频编码/解码
- 安全
- UX 改进功能（降噪、回声消除等）
- 支持多种平台（Windows、Mac、Linux、Android、iOS等）
如果使用 WebRTC 则就不需要考虑上面这些因素。
WebRTC 使应用程序开发人员能够使用简单的 API 启动实时通信能力。
如何建立连接
为了建立 WebRTC 连接，需要执行以下两个步骤：
- 查找对等点的位置。
- 通知对等方设置 WebRTC 连接。
第 1 步：找到对等点
把这想象成打电话，当需要通过电话与某人交谈时，拨打对方的电话号码并与该人建立联系。当有人想给你打电话时，也会发生同样的事情。在移动通信的情况下，使用手机/电话号码作为用户的标识。电信系统进一步使用该标识来定位用户。
但是，Web 应用程序不能相互“拨号和呼叫”。世界上数以百万计的浏览器中的每一个都没有分配唯一 ID（如电话号码）。但是，这些应用程序所在的系统一般都分配了一个唯一的 IP 地址，这个IP地址可用于“定位”对等点。
然而，这个过程并不像听起来那么容易。因为，这些系统中的大多数都位于网络地址转换 (NAT)设备后面。需要 NAT 设备来实现对可用公共 IP 地址的安全性和 IPv4 限制。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 服务器。
TURN 服务器不是有意的，但由于 STUN 的限制，必须依赖它。STUN 服务器只有大约 86% 的成功率。
第 2 步：通知对等方设置 WebRTC 连接
现在已经获得了 ICE 候选者，下一步是将这些候选者发送到希望连接的对等点。与候选人一起发送会话信息、时间描述、媒体描述等会话描述。ICE 候选者和会话描述被捆绑在一个对象内，并使用会话描述协议 (SDP)进行传送。在某些情况下，候选 ICE 不会与 Session Description 捆绑在同一个对象中，而是单独发送，这称为 Trickle ICE（这是一个全新的概念）。
需要将信息“发送”给其他对等方。但是，当只知道发送方的 IP 地址而不知道接收方的 IP 地址时，候选和会话描述是如何传输的？而且由于WebRTC连接还没有建立，这些信息是通过什么媒介传输的？
所有这些问题的答案都在一个称为信号机制的概念中。在建立 WebRTC 连接之前，需要一些媒介在对等点之间传递上述信息，并让它们知道如何定位和相互连接以进行 WebRTC 连接。这就是信号机制发挥作用的地方。信令机制在打算连接的两个对等方之间交换连接信号（ICE 候选、会话描述等）。
WebRTC 没有为实现这种信号机制定义任何标准，而是让开发人员创建选择的机制。交换信息的信令机制可以通过简单地将信息复制粘贴到各个对等方或使用 WebSockets、Socket.io、服务器端事件等通信通道来实现。简而言之，信令机制 只是一种模式在对等点之间交换连接相关信息，以便对等点可以相互识别并开始使用 WebRTC 进一步通信。
假设对等点A想与对等点B建立 WebRTC 连接，需要执行以下操作：
- 对等点A使用交互式连接建立 (ICE)生成它的 ICE 候选者。在大多数情况下，它需要 NAT 会话遍历实用程序 (STUN)或使用 NAT 周围中继的遍历 (TURN)服务器。
- 对等点A将 ICE 候选和会话描述捆绑到一个对象中。该对象在对等点A中存储为本地描述（对等点自己的连接信息），并通过信令机制传输到对等点B。这部分称为要约。
Peer B收到 offer 并将其存储为Remote Description（另一端 peer 的连接信息）以供进一步使用。对等体B生成它自己的 ICE 候选和会话描述，将它们存储为本地描述，并通过信令机制将其发送给对等体A。这部分称为答案。（注：如前所述，第2步和第3步的ICE候选也可以分开发送）
对等点A从对等点B接收答案并将其存储为远程描述。
这样，双方就可以知道对方的连接信息，可以通过WebRTC成功开始通信了！