我们知道使用WebRTC进行端对端进行实时音视频通讯时，WebRTC 本身是基于点对点（Peer-to-Peer）连接的，最便捷的方式就是通话的双方通过ip直连，摆脱原始的直播服务器中转的方式。

如果连接双方都是公网地址，则可以直接访问到对方，从而建立连接。但是在现实的应用场景中，大部分情况下其中一方或者双方都不是公网地址，而是隐藏在 NAT（Network Address Translation，网络地址转换）之后的内网地址。

比如局域网A中的192.168.2.232和局域网B中的192.168.2.161之间是不能直接连接通讯的。由于需要连接的个人设备绝大多数都隐藏在各自的内网当中，导致无法直接获取客户端IP地址，也无法直接进行P2P的音视频通信。 为了解决这个问题，WebTRTC采用了ICE技术框架来实现NAT穿越。

一、NAT网络地址转换

或许你在之前听闻过IPv4地址枯竭的报道，IPv4地址只有32位长，理论最多42.9亿条。大概在94年时候，提出了NAT（ Network Address Translation 网络地址转换） RFC规范，作为一个临时方案来解决IPv4地址枯竭的问题。

这个方案就是把IP地址重用，在边缘网络引入NAT设备，由它来负责维护本地服务IP和端口的映射到公网IP和端口。NAT内部的本地IP地址空间可以被许多不同的子网络重用，从而解决地址耗尽的问题。

可是，后面临时方案很快成为了最终方案，成为了互联网基础设施的组成部分。它不仅用来解决IP地址枯竭的问题，你能发现路由器、防火墙、代理设备都具备NAT功能。

【相关学习资料推荐，点击下方链接免费报名，先码住不迷路~】

音视频免费学习地址：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发

【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击788280672加群免费领取~

2. NAT类型 关于NAT被人们研究总结过，大体两种：锥型和对称型。而锥型又可分细分为三种。 所以归纳起来，总共四种类型：完全锥型、IP限制锥型、端口限制锥型 和 对称型。

a. 完全锥型

当内网host与外网机器通讯，就会在NAT上打洞，这个过程就是指在NAT建立内外网映射表，这个表上记录内外网IP端口映射关系。外网机器与P地址p端口的通讯，都会在NAT上转发到对应的内网地址与端口，从而实现和内网host机器通讯。

b.IP限制型

IP限制锥型更加严格，在完全锥形基础上，只允许Host访问过的IP通过打洞。（映射表多记录了被访问外网的IP地址）如图，A和C等其它外网主机想通过B机的打洞IP端口，也是无法和Host通讯。

c. 端口限制锥型

端口限制锥型比IP限制锥型更加严格，IP限制锥型不限制端口。IP限制锥型情况下，同一外网主机的其它端口服务，都能和内网Host通讯。但是端口限制性情况下，只允许外网机器指定的端口服务通过打洞。（映射表多记录了被访问的外网的IP地址和端口)

d. 对称型

对称型，是最严格的NAT类型，它一样有IP和端口限制（这点和端口限制锥型一致）。它最大不同在于，每次连接都会在NAT上新开IP地址或者新开IP地址和端口与外网通讯。也就是说每一次NAT的打洞都不相同。基本上对称型NAT是无法穿越的。

3. NAT类型检测

根据上面的介绍，我们可以了解到，在实际的网络场景中，各种设备所处的网络环境是不同的。那么在进行设备间的通信之前，首先需要判断出设备当前所处的网络类型是非常重要的一步。

下图是在STUN（Session Traversal Utilities for NAT），对于NAT类型检测的流程图。当走到红色结束时：表明穿越失败，无法UDP通讯。当走到绿色（公网地址）或黄色时（锥型NAT）才可能进行通讯。

整个流程大体上发起了5次检测 test1

test2

test3

test4

test5

以上关于NAT，及其打洞和穿越原理的介绍。实际穿越比这个包含更多细节且更加复杂，可以参考有相应的RFC规范RFC5389进行了解，但是整个耗时还是相当快的。

二、STUN/TURN 协议 前文提到，客户主机不可避免的在防火墙或NAT之后。在UDP传输时，一般只会带上 NAT 的 host。如果没有目标机器的entry是不会转发到目标机器。在client-server情形下没有问题。如果是 peer-to-peer 情形下则无法传输。因此我们需要借助STUN/TURN方式进行NAT穿透。 WebRTC采用了ICE（Interactive Connectivity Establishment）建立端到端的数据通道。说道ICE，就不得不提到它的两个工具协议：STUN(Session Traversal Utilities for NAT)和TURN（Travelsal Using Relays around NAT）协议。

1. STUN

a. 标准规范定义 STUN，首先在RFC3489中定义，作为一个完整的NAT穿透解决方案，英文全称是Simple Traversal of UDP Through NATs，即简单的用UDP穿透NAT。

在RFC5389修订中把STUN协议定位于为穿透NAT提供工具，而不是一个完整的解决方案，英文全称是Session Traversal Utilities for NAT，即NAT会话穿透效用。

b. STUN用途

c. STUN服务的简易过程 内网主机需要借助STUN 服务器，遵循STUN协议机制，便能得到本机 NAT 映射后的外网的 IP 和端口，以下是简易过程。

2. TURN a. 标准规范定义 TURN，在RFC5766中定义，英文全称Traversal Using Relays around NAT（TURN）：Relay Extensions to Session Traversal Utilities for NAT（STUN），即使用中继穿透NAT：STUN的中继扩展。简单的说，TURN是通过两方通讯的“中间人”方式实现穿透。 注意：这里Relay 或 TURN 是同一个概念都是值中继型传输。

b. 用途

当STUN服务检测，发现直接以peer-to-peer的形式连接时，就走TURN方式，使用中间网点提供的中继连接服务。TURN协议就是用来允许主机控制中继的操作并且使用中继与对端交换数据。TURN与其它中继控制协议不同的是它能够允许一个客户端使用一个中继地址与多个对端连接。

三、ICE连接机制 1. 收集ICE Candidate（候选项） WebRTC两端要进行连接时，每一端都会提供多个候选者，比如一端有两块网卡，那么每块网卡的不同端口都对应一个候选者。 ICE Candidate 主要分为以下三种类型：

2. ICE 连接流程 a. 连通性检测 当收集完 ICE Candidate后，双方通过信令通道交换，并拿到彼此的ICE candidate之后，WebRTC 就开始按优先级顺序进行连通性检测了。 一般情况下：host 类型的候选者优先级是最高的, srflx类型次之, 最后是relay类型。 这个阶段对于对等项发来的通过身份验证的任何STUN连接request，ICE代理都会生成STUN response。候选项依照之前的排序按次序进行检查，当收到对方的响应时，检查视为成功，而如果检查超时后仍没有收到响应时，则该候选对失败。

连通性检测的原则简单归纳:

在WebRTC中　P2PTransportChannel会维护连接状态表，并排序表中记录（SortConnectionsAndUpdateState）。 　排序指的是计算每条记录的连接“成本”，把成本最低的排在第一位。如何计算成本？则涉及到很多因素，比如发出Stun请求到收到应答耗时，用时越少的“成本”自然会低些。 　 　当一端有视频RTP数据要发送时，会检查状态表的第一条记录，如果判断出它的状态是发送就绪，就会用此Connection进行发送。否则直接放弃这个发送任务。 　

为了确保NAT映射和过滤规则不在音视频通话过程中超时，ICE会不断对使用中的候选项对（通道）进行连接检查，每15s发送一次，这样是为了保证在音视频流暂停等情况下没有发送数据流时，仍然有数据包持续发送。

当ICE代理检测到正在使用的传输地址发生更改或连接时，会触发重新启动ICE事件，也就是会重新回到收集ICE candidate及其之后的流程。

四、小结

其实WebRTC的ICE 就是包括 STUN、TURN 协议的一套框架，用于找到一条可用且最优传输数据通道连接。了解NAT穿越和ICE框架的基础知识，你会更容易理解WebRTC传如何建连步骤并传输数据。当然实际的 ICE 过程要复杂很多，本文知识简要介绍主要答题步骤，感兴趣的读者可以自行阅读参考 RFC5245。

原文链接：https://juejin.cn/post/6998409477124800526