1、前言
上一篇中我们讲解了一下媒体协商的过程，以及为什么要进行媒体协商，如果协商完成，接下来就是要进行媒体数据的传输，但是在我们的互联网中，网络情况是非常复杂的，要怎么解决私网地址的连接，以及如何保证连通率，如果内网能连通是不是就不用走公网。情况还是非常的复杂的，那么我们如何解决这些问题。
在开始之前我们先思考两个场景
场景一：双方处于同一个内网中
A和B要进行通信，假如他们在同一个内网中，这种情况下一般来说有几种连接方式
-
直接通过内网进行连接
-
通过公网后进行连接
-
通过中继服务器进行连接
在大家看来，第一种直接通过内网进行连接的是最好的，但是这个问题其实没这么简单，你怎么能确定在A和B在用内用的同一个网段能进行连接呢。
场景二：双方处于不同的两个地方
A和B要进行通信，他们在不同的两个地方，A和B之间一定会经过公网，那么一般来说连接情况就有以下几种
-
直接通过P2P进行连接
-
通过中继服务器进行连接
这个场景来看直接通过P2P连接是最好的，通过中继服务器连接会增加延时和成本，但是直接通过P2P也还是有很多困难的，如果P2P的方式不通，就要使用中继的方式进行连接了。 这个时候我们怎么判断该用哪种方式呢?
2、什么是 Candidate
Candidate的英文翻译是候选，顾名思义就是ICE候选的意思，表示WebRTC和远端进行通信的时候使用的协议、ip地址和端口等。
2.1 candidate的字段解析
-
foundation:用于标志和区分来自同一个stun的不同的候选者,ID标识
-
icegroupid:ICE的组ID
-
type:协议类型
-
priority:优先级
-
ip:ip地址
-
port:端口
-
typ:标识后面字段的属性类型是候选类型
-
host:本地接口获取到的candidate（本机候选）
-
srflx:NAT网关在公网侧的IP地址，通过STUN或者TURN收集(server reflexive candidate)（内网主机映射的外网地址端口，对称性NAT）
-
prflx:可以在ICE的后续阶段中获取到(peer reflexive candidate)（TUN server为客户端分配的中继地址）
-
relay:TURN服务器的公网转发地址，通过TURN收集（中继服务器的地址）
-
-
generation:代号，表明当前是第几代的候选
-
ufrag: ICE分配的用户名标识
-
network-cost : 网卡标识
在众多候选类型中，host的候选优先级是最高的，在WebRTC中，首先会对host的类型候选进行连通性检测，如果可以连通，那么就直接连接，无法连通的话会采用srflx进行尝试P2P连接，如果还不行就依次进行检查。
了解了什么是Candidate后，我们来看看是如何进行连接的吧，由于本地连接Host是最简单的，都是本机的IP地址，这里就不再进行讲解了。
3、STUN 协议
STUN的全称是Session Traversal Utilities for NAT，即NAT会话穿越应用程序，是一种可以让位于NAT后的设备可以查找自己的公网IP的技术。
首先大家知道我们的网络为了解决IPv4地址不足的问题是有用私有网络地址的，但是私网的地址是无法在公网上使用的，于是就要通过NAT转换成公网地址后才能进行公网访问，接下来NAT就会将对应的请求发送给目标服务器，服务器处理好后返回给NAT后的公网IP地址的用户，NAT在返回给内网的主机。
上面其实大概就是STUN，客户端向STUN服务发起一个连接，这个时候STUN server会通知STUN client它的公网IP以及公网端口。这个时候就可以获取了srflx的类型候选，那relay的候选是怎么获取的呢？
【学习地址】：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】：免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击1079654574加群领取哦~
4、TURN 协议
relay的候选的优先级是最低的，在其他的候选都无法连接的时候，relay就可以帮助用户进行连接，其实，relay 型候选者的获取也是通过 STUN 协议完成的，只不过它使用的 STUN 消息类型与获取 srflx 型候选者的 STUN 消息的类型不一样而已。
当两个客户端由于对称型NAT原因不能建立连接可以使用一个TURN作为中继，两个客户端分别和TURN server建立连接，TURN server返回它自己的IP和端口给两个客户端，TURN server作为中继，使用UDP协议给两个客户端直接转发报文。
TURN全称Traversal Using Relays around NAT，即使用中继穿透NAT
讲到这里我们就可以介绍了一下的webRTC的架构了
5、ICE
ICE全称Interactive Connectivity Establishment，交互式连接建立，他是结合上面的几种候选类型，在本机收集所有的 host 类型的 Candidate，通过 STUN 协议收集 srflx 类型的 Candidate，使用 TURN 协议收集 relay 类型的 Candidate。
具体可以查看RFC8445
6、NAT
上面其实已经介绍了为什么要使用NAT，但是NAT也是有很多种类型的，NAT可以分为源NAT、目的NAT和双向NAT，下面我们分别介绍这三种NAT类型。
6.1 源NAT
源NAT在NAT转换时，仅对报文中的源地址进行转换，主要应用于私网用户访问公网的场景。当私网用户主机访问Internet时，私网用户主机发送的报文到达NAT设备后，设备通过源NAT技术将报文中的私网IPv4地址转换成公网IPv4地址，从而使私网用户可以正常访问Internet。
根据转换时是否同时转换源端口号，源NAT可以细分为如下几种类型，详见下图。
6.2 目的NAT
目的NAT在NAT转换时，仅对报文中的目的地址和目的端口号进行转换，主要应用于公网用户访问私网服务的场景。当公网用户主机发送的报文到达NAT设备后，设备通过目的NAT技术将报文中的公网IPv4地址转换成私网IPv4地址，从而使公网用户可以使用公网地址访问私网服务。
根据转换前后的地址是否存在一种固定的映射关系，目的NAT可以细分为如下几种类型，详见下图。
6.3 STUN中定义的NAT类型
-
Full Cone NAT（完全锥型NAT）
所有从同一个私网IP地址和端口（IP1:Port1）发送过来的请求都会被映射成同一个公网IP地址和端口（IP:Port）。并且，任何外部主机通过向映射的公网IP地址和端口发送报文，都可以实现和内部主机进行通信。
这是一种比较宽松的策略，只要建立了私网IP地址和端口与公网IP地址和端口的映射关系，所有的Internet上的主机都可以访问该NAT之后的主机。
-
Restricted Cone NAT（限制锥型NAT）
所有从同一个私网IP地址和端口（IP1:Port1）发送过来的请求都会被映射成同一个公网IP和端口号（IP:Port）。与完全锥型NAT不同的是，当且仅当内部主机之前已经向公网主机发送过报文，此时公网主机才能向私网主机发送报文。
-
Port Restricted Cone NAT（端口限制锥型NAT）
与限制锥型NAT很相似，只不过它包括端口号。也就是说，一台公网主机（IP2:Port2）想给私网主机发送报文，必须是这台私网主机先前已经给这个IP地址和端口发送过报文。
-
Symmetric NAT（对称NAT）
所有从同一个私网IP地址和端口发送到一个特定的目的IP地址和端口的请求，都会被映射到同一个IP地址和端口。如果同一台主机使用相同的源地址和端口号发送报文，但是发往不同的目的地，NAT将会使用不同的映射。此外，只有收到数据的公网主机才可以反过来向私网主机发送报文。
这和端口限制锥型NAT不同，端口限制锥型NAT是所有请求映射到相同的公网IP地址和端口，而对称NAT是不同的请求有不同的映射。