webrtc 看不到对方画面是什么原因_【博客精读】理解WebRTC

写在前面

这篇博客简单介绍了 WebRTC 是什么和建立WebRTC连接都需要经历哪些步骤。本身并没有涉及太多WebRTC API 或内部实现。本质上如果网络世界都是公开的，大家的IP都像电话号码一样固定，WebRTC连接的建立就会非常直白简单，但现实要复杂很多（主要是因为有NAT的存在）。那么这些到底和WebRTC 有什么关系，应用WebRTC又该怎么解决这个问题呢？来看看这篇博客吧。

原文解读

原文链接：Understanding Web Real-Time Communication (WebRTC)
原文发布时间：2018年8月3日
作者：Anto Christopher
翻译+解读：摆积木的贪吃猴

介绍

WebRTC（网页即时通信） 是一个开源的项目，目前主要用于支持网页浏览器进行实时的，点对点的通信。

有了 WebRTC，开发人员可以更容易在网页应用中去实现实时语音和视频通话，以及数据传输的能力。不过现在WebRTC开发也不限于网页端，也可以用在本地应用开发。API的使用本身并不复杂，但是如果能更透彻地理解这些API后面的概念和原理，就能更好地应用这个技术。

想要建立一个WebRTC连接，需要做以下2步：

1. 找到你想要与之建立连接的对点（peer）；
2. 告诉该对点你想要与之建立WebRTC连接。

第一步：定位对点（locating a peer）

你可以把这个想象成你想和对方打电话，首先你要拨打对方的电话号码来和对方建立连接。对方想和你打电话时也一样。在移动通信中我们用电话号码来标识用户，这个标识在电子通信系统中被用来定位用户。

可惜在网页应用中我们不能直接给对方“拨号打电话”，因为我们不可能给全世界难以计数的浏览器用户都分配一个独有的ID。不过我们倒是可以利用每个用户独有的IP来定位用户。

说起来简单，问题是所有的用户设备都藏在NAT（网络地址翻译）之后。NAT的存在是为了解决网络安全因素和IPv4数量不够的问题（NAT值得单独讲解，简单地说就是多个设备可以在同一个局域网中，共享相同的共有IP）。在NAT的庇护下内网的所有设备的IP都是由NAT系统来分配的，外界是不知道的，我们把这个IP叫做私有IP。处在外界的设备由于无法获取这些网内设备的IP而无法知道如何与之建立联系。

由于NAT本身的工作原理，内网中的设备其实也不知道自己的公有IP，所以它也没办法告诉别人自己的IP来让别人和它建立连接。在NAT内网中就好比一个酒店里各个客房的电话，所有外界的电话都只能打到前台，然后前台再根据情况把电话转接到某个房间，外界是无法直接打到某个房间的。其实像这种转接形式本来是不会应用在点对点连接技术领域中的。

为了解决这个难题，WebRTC 采用了一种叫做互动式连接建立 （ICE - Interactive Connectivity Establishment）的技术。ICE 的任务就是找到连接两个交互方的最佳路径。ICE 可以建立直接连接（也就是没有NAT的情景）或者间接连接（即有NAT的情景）。在该框架中我们可以获取 互动式连接候选者 （ICE Candidates） ，ICE Candidates 本质上就是一个包含了本地（或者对方）公共IP等信息的对象。

在没有NAT的情景中，ICE 的实现很简单，因为双方的公共IP都是现成的。但是在有NAT的情景中 ICE 的实现就要借助于 NAT穿透技术，例如 STUN (Session Traversal Utilities for NAT) 和 TURN (Traversal Using Relays around NAT). (这两个名字的中文翻译都很奇怪，就可以把他们理解成克服在有NAT存在下无法获取公共IP的技术，具体的可以和NAT技术一起学习。)

STUN 服务器其实就是帮助在NAT之中的设备获取自己的公共IP。比如图中Peer A 想知道自己的公共IP，就直接发送请求给相应的STUN服务器即可获取，然后A就可以告诉B自己的IP从而与B建立连接。但是如果Peer A所在的NAT更复杂，STUN服务器也无法提供Peer A相应的IP地址信息。这时就要用到TURN，TURN中的R（Relay）是中继站的意思，顾名思义，TURN其实就是一个中继服务器，它将在A和B之间帮忙转发所有的数据（也就是说A和B是没有直接连接的）。

STUN服务器只是在获取公共IP的过程中被用到，当通信双方建立WebRTC连接之后，所有的通信都是通过WebRTC连接完成的，和STUN就没有任何关系了。但是TURN是在整个通信过程中一直要存在于双方中间转发数据的。

其实如果不是为了解决STUN服务器的局限，TURN服务器本来是不该用在点对点通信的场合的（因为这本身是违背P2P思想的）。事实上在86%的情况下STUN服务器都是可以解决NAT问题的。

ICE之所以复杂，是因为我们生活在一个复杂的世界。

第二步：通知对方你想要与之建立WebRTC连接

上面的Peer A已经成功获取本地ICE Candidates了，下一步就是告诉对方它想建立连接。除了ICE Candidates 之外，我们也需要有告诉对方我们想要建立连接之后要做什么，比如会话信息，时间描述和媒体描述，这些都在会话描述对象（Session Description）中定义。 ICE Candidates 和 SessionDescription 都会通过会话描述协议（SDP）进行传输。

可是目前为止我们只知道本地设备的公共IP，并不知道对方的IP，我们是如何把信息发送过去的呢？而且目前我们并没有和对方建立任何连接，又是通过何种媒介发送信息呢？

这些问题都是通过 Signalling 机制来解决的。在我们建立WebRTC连接之前，我们需要某种媒介把上述的所有信息告知彼此，从而让双方知道如何与对方建立联系。在这之后双方才能建立WebRTC连接。 Signalling 机制，顾名思义，就是负责交换要建立连接的双方的信息，包括 ICE Candidates 和 SessionDescription。

WebRTC本身并没有定义Signalling 机制的实现，开发人员是可以自己选择如何实现Signalling 机制的。Signalling 机制本身就是为了交换信息，让彼此知道对方在哪里。最简单的就是直接把这些信息写在对方的脑子里（可能事先就通过某种方式得知），或者用WebSockets，Socket.io, Server Side Events等等。

总结

假设 peer A想和 peer B建立 WebRTC连接，它将经历如下步骤：

1. Peer A 利用ICE技术获取自己本地的ICE Candidates。一般情况下STUN Server就可以帮助完成这一步，实在不行就会用到TURN技术。
2. Peer A 把获取的 ICE candidate 和 Session Description 信息包装在一个对象中（有时也可以分开），这个对象叫做 Local Description (本地交互方的联系方式和相关信息) ，然后通过Signaling机制把这个对象传送给peer B，这部分就叫做 WebRTC Offer。
3. Peer B 接收到之后 Offer 之后将其存储为 Remote Description (对方的联系方式和相关信息) 待备用。然后自己也通过同样的方式获取自己的 ICE candidate and Session Description，在本地存储为 Local Description ，然后通过Signaling机制发送给 peer A。这个就是所谓的 WebRTC Answer. (注意: ICE candidates 有可能不止一个，也可以分多次发送。)
4. Peer A 接收到之后 Answer 之后将其存储为 Remote Description。

至此，双方都有了对方的连接信息，终于可以开始建立WebRTC连接进行媒体通信了。