WebRTC进阶四 / ICE和NAT

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)（内网主机映射的外网