有了WebRTC，直播可以这样玩

如何实现两个人的实时视频通话呢？你可能会首先想到直播手段：采流 -> 推流 -> 拉流。但是，如果把这个过程放在前端去实现，那只能天台见了。然而，WebRTC的出现，扭转了这个现状。

借助WebRTC，前端可以不用去关注“采流 -> 推流 -> 拉流”这种过程，倾轻松就可以实现直播甚至实时音视频通话。

WebRTC是什么？底层原理是什么？怎么用？让烧烤哥给你娓娓道来！

什么是WebRTC？

WebRTC全称Web Real-time Communication，网页即时通讯技术。它是由Google发起的一个的实时通讯解决方案。之所以称为一个方案，而不是协议，是因为它涵盖了音视频采集、通讯的建立、信息传输、音视频显示等整套的实现方案。该方案的发起让加快速地实现一个音视频通讯应用成为可能。

 

如果你是web开发者，通过浏览器提供的WebRTC API可以轻松的实现音视频的采集和播放，实现端对端的通讯通道的建立，并可通过建立的通道实现音视频的数据的共享。

虽然WebRTC看起来是浏览器的玩意，但是由于谷歌的开源精神，它可以通过编译C++的代码实现全平台互通。所以，如果你想通过web远程控制windows电脑，可以让你的C++的小朋友接一波WebRTC，WebRTC还支持实时采集桌面哦！

WebRTC是如何实现端对端的音视频共享的？

传统的资源共享更多的是通过一个中转服务器进行交换的。把对方想要的资源提前上传到固定的公网服务器中，然后再通过地址进行访问。这种形式好的好处是可靠性非常强，因为资源服务器是固定的，不会受传输方和使用方的网络影响，非常灵活可靠！

 但是，实时性很差。需要等到对方把文件上传完成之后才可以下载文件。当然，这个流程也可以达到实时的，可以在服务器搭建一个文件流中转，让到达服务器的文件流立即传输给拉取方。如此麻烦，为什么不省略掉这个服务器呢？

P2P连接

P2P全称peer to perr，学术名称为对等网络，它是一种网络技术和网络拓扑结构。建立起P2P连接的设备可以不经过第三方服务的转发，就可以达到1对1的信息传输交换。

那么如何创建一个P2P的连接呢？这里我们先看看现实的互联网世界是这样进行通讯的！

现实的网络世界

现实世界中的网络是这样的：

 

因为目前互联网大部分部署的网际协议（IP协议）版本是IPV4，然而IPV4使用的是32位2进制的地址，能够产生43亿个IP地址，如果每一个用户终端都以独立的IP地址接入互联网，那么这43亿的地址将不够分。

所以目前的网络结构基本是多设备终端通过一层或多层的NAT代理接入到互联网中，也就是局域网。

NAT是什么？

NAT：网络地址转换，它是一种解决专用网络内设备连接公网的技术。

那么NAT的工作原理是什么呢？

 

• 当设备A想发送一个请求到服务器172.20.98.44:7777 => 8.8.8.8:23456，首先请求会先到达NAT，由NAT修改报文的源地址和源端口以及相应的校验码，然后才会发送给服务器，此时就形成流一个映射关系：

172.20.98.44:7777 => 6.6.6.6:12345 => 8.8.8.8:23456

 

• 当服务器处理完成请求后响应数据返回到NAT时，NAT根据映射关系，修改目的地址和目的端口以及相应的校验码，然后再发送给设备A：

8.8.8.8:23456 => 6.6.6.6:12345 => 172.20.98.44:7777
复制代码

这就是NAT使得内网设备能够正常访问公网服务器到原理特性。

处于内网中的设备可以借助NAT实现公网服务器的访问，但是在P2P连接中可能两个设备都处于不同的内网中，这两个设备如何进行P2P连接呢？

NAT穿透技术

 

要使得处于两个内网中的两个设备能够建立P2P连接的技术方案被统称为NAT穿透技术。一般来说，P2P可以建立UDP连接也可以建立TCP连接，所以这个机制又被称作UDP打洞或TCP打洞。因为webRTC使用的传输层协议是UDP协议，所以我这里主要讲解UDP打洞原理。

• 第一步，添加一个信使服务器。信使服务器的作用是发现、记录内网设备在NAT中映射的端口以及其NAT的公网IP。这种服务器也被称为STUN服务器。根据NAT的特性，当设备A向STUN服务器发送请求时，会形成映射关系：172.20.98.44:7777 => 6.6.6.6:12345 => 3.3.3.3:34567，这时STUN服务器将6.6.6.6:12345响应给设备A。同样的，设备B也进行响应的请求以获取对应的映射关系。

 

• 交换映射关系。设备A和设备B需要将自己在NAT的映射关系交换，为下一步建立连接做准备。这里需要另外协议进行交换。
• 交换完成之后，设备A向设备B的NAT-B地址8.8.8.8:23456发送请求包，因为这个请求不是设备B主动发起的，为了安全考虑，NAT-B接收到这个请求包之后不会转发给设备B，而是抛弃掉，但是NAT-A根据特性记录这个映射关系，后面从地址8.8.8.8:23456发来的包都会转发给设备A。同样的，设备B也向6.6.6.6:12345发起同样的请求，让NAT-B知道后面从6.6.6.6:12345发来的请求都转发给设备B。
• 完成上面的动作之后，设备A和设备B就可以建立P2P连接愉快的发送消息了。当然这个连接需要心跳包维持，防止被close掉。

上面就是一个完整的UDP打动过程，完成打洞之后设备就可以跨过NAT实现P2P连接了。

WebRTC是基于UDP实现的端对端连接

基于前面认知，WebRTC实现端对端的音视频传输也需要处理UDP打洞这个过程。在我们调用WebRTC创建端对端的连接时并不会去实现这个UDP打洞的过程（如果要，那就和提出WebRTC的初衷相背离了，实现方便快捷地建立音视频即时通讯是WebRTC所追求的）。更多的，我们需要按照流程调用API去完成WebRTC的创建。