前言：

WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，简而言之它是一个支持网页浏览器进行实时语音对话或视频对话的技术。

它为我们提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android，iOS。

它在2011年5月开放了工程的源代码，在行业内得到了广泛的支持和应用，成为下一代视频通话的标准。

本文将站在巨人的肩膀上，基于WebRTC去实现不同客户端之间的音视频通话。这个不同的客户端，不局限于移动端和移动端，还包括移动端和Web浏览器之间。

2702646-1e74a6b70c80e577.png

目录：

一.WebRTC的实现原理。

二.iOS下WebRTC环境的搭建。

三.介绍下WebRTC的API，以及实现点对点连接的流程。

四.iOS客户端的详细实现，以及服务端信令通道的搭建。

正文：

一.WebRTC的实现原理。

WebRTC的音视频通信是基于P2P，那么什么是P2P呢？

它是点对点连接的英文缩写。

1.我们从P2P连接模式来讲起：

一般我们传统的连接方式，都是以服务器为中介的模式：

  • 类似http协议：客户端?服务端（当然这里服务端返回的箭头仅仅代表返回请求数据）。

  • 我们在进行即时通讯时，进行文字、图片、录音等传输的时候：客户端A?服务器?客户端B。

而点对点的连接恰恰数据通道一旦形成，中间是不经过服务端的，数据直接从一个客户端流向另一个客户端：

客户端A?客户端B ... 客户端A?客户端C ...（可以无数个客户端之间互联）

这里可以想想音视频通话的应用场景，我们服务端确实是没必要去获取两者通信的数据，而且这样做有一个最大的一个优点就是，大大的减轻了服务端的压力。

而WebRTC就是这样一个基于P2P的音视频通信技术。

2.WebRTC的服务器与信令。

讲到这里，可能大家觉得WebRTC就不需要服务端了么？这是显然是错误的认识，严格来说它仅仅是不需要服务端来进行数据中转而已。

WebRTC提供了浏览器到浏览器（点对点）之间的通信，但并不意味着WebRTC不需要服务器。暂且不说基于服务器的一些扩展业务，WebRTC至少有两件事必须要用到服务器：

  • 浏览器之间交换建立通信的元数据（信令）必须通过服务器。

  • 为了穿越NAT和防火墙。

第1条很好理解，我们在A和B需要建立P2P连接的时候，至少要服务器来协调，来控制连接开始建立。而连接断开的时候，也需要服务器来告知另一端P2P连接已断开。这些我们用来控制连接的状态的数据称之为信令，而这个与服务端连接的通道，对于WebRTC而言就是信令通道。

QQ截图20170306095814.png

图中signalling就是往服务端发送信令，然后底层调用WebRTC，WebRTC通过服务端得到的信令，得知通信对方的基本信息，从而实现虚线部分Media通信连接。

当然信令能做的事还有很多，这里大概列了一下：

  • 用来控制通信开启或者关闭的连接控制消息

  • 发生错误时用来彼此告知的消息

  • 媒体流元数据，比如像×××、×××的配置、带宽、媒体类型等等

  • 用来建立安全连接的关键数据

  • 外界所看到的的网络上的数据，比如IP地址、端口等

在建立连接之前，客户端之间显然没有办法传递数据。所以我们需要通过服务器的中转，在客户端之间传递这些数据，然后建立客户端之间的点对点连接。但是WebRTC API中并没有实现这些，这些就需要我们来实现了。

而第2条中的NAT这个概念，我们之前在iOS即时通讯，从入门到“放弃”？ ，中也提到过，不过那个时候我们是为了应对NAT超时，所造成的TCP连接中断。在这里我们就不展开去讲了，感兴趣的可以看看：NAT百科

这里我简要说明一下，NAT技术的出现，其实就是为了解决IPV4下的IP地址匮乏。举例来说，就是通常我们处在一个路由器之下，而路由器分配给我们的地址通常为192.168.0.1 、192.168.0.2如果有n个设备，可能分配到192.168.0.n，而这个IP地址显然只是一个内网的IP地址，这样一个路由器的公网地址对应了n个内网的地址，通过这种使用少量的公有IP 地址代表较多的私有IP 地址的方式，将有助于减缓可用的IP地址空间的枯竭。

但是这也带来了一系列的问题，例如这里点对点连接下，会导致这样一个问题：

如果客户端A想给客户端B发送数据，则数据来到客户端B所在的路由器下，会被NAT阻拦，这样B就无法收到A的数据了。

但是A的NAT此时已经知道了B这个地址，所以当B给A发送数据的时候，NAT不会阻拦，这样A就可以收到B的数据了。这就是我们进行NAT穿越的核心思路。

于是我们就有了以下思路：

我们借助一个公网IP服务器,a,b都往公网IP/PORT发包,公网服务器就可以获知a,b的IP/PORT，又由于a,b主动给公网IP服务器发包，所以公网服务器可以穿透NAT A,NAT B送包给a,b。

所以只要公网IP将b的IP/PORT发给a,a的IP/PORT发给b。这样下次a和b互相消息，就不会被NAT阻拦了。

而WebRTC的NAT/防火墙穿越技术，就是基于上述的一个思路来实现的：

建立点对点信道的一个常见问题，就是NAT穿越技术。在处于使用了NAT设备的私有TCP/IP网络中的主机之间需要建立连接时需要使用NAT穿越技术。以往在VoIP领域经常会遇到这个问题。目前已经有很多NAT穿越技术，但没有一项是完美的，因为NAT的行为是非标准化的。这些技术中大多使用了一个公共服务器，这个服务使用了一个从全球任何地方都能访问得到的IP地址。在RTCPeeConnection中，使用ICE框架来保证RTCPeerConnection能实现NAT穿越

QQ截图20170306095915.png

这里提到了ICE协议框架，它大约是由以下几个技术和协议组成的：STUN、NAT、TURN、SDP，这些协议技术，帮助ICE共同实现了NAT/防火墙穿越。

小伙伴们可能又一脸懵逼了，一下子又出来这么多名词，没关系，这里我们暂且不去管它们，等我们后面实现的时候，还会提到他们，这里提前感兴趣的可以看看这篇文章：WebRTC protocols


http://www.cocoachina.com/ios/20170306/18837.html