NAT穿透技术简介和实现方案分析

矫情吗；* 2023-07-23 03:47 24阅读 0赞

## 1. NAT和NAT穿透 ##

NAT的出现是为了解决IPV4地址稀缺的问题，同时起到了防火墙的作用保护了内网的信息安全，但是对于P2P下载来说无疑是很大的阻碍。本文先简单介绍了NAT和NAT穿透的分类，然后就常用的STUN/TURN/ICE进行介绍，最后分析现有的一些ICE开源项目。

#### 1.1 NAT类型介绍 ####

根据RFC3235规定，NAT类型主要有Full Cone NAT（全锥型）， Restricted NAT（限制型锥型）, Port Restricted NAT(端口限制型锥型), Symmetric NAT（对称型）四种。四种类型的主要区别在于对外界访问内部IP的控制力度。为方便解释，我们使用如下的用语来说明四种NAT类型的不同之处。

*  内部Tuple：内部主机发送报文的源地址、端口所构成的二元组
 *  外部Tuple：指内部Tuple经过NAT的源地址/端口转换之后，所获得的外部地址、端口所构成的二元组
 *  目标Tuple：指外部主机的地址、端口所构成的二元组

具体类型的特性如下：

（1）Full Cone NAT：所有来自同一个内部Tuple X的请求均被NAT转换至同一个外部Tuple Y。当X-Y的转换关系建立之后，任意外部主机均可随时将Y中的地址和端口作为目标地址和目标端口，向内部主机发送UDP报文。

（2）Restricted Cone NAT：所有来自同一个内部Tuple X的请求均被NAT转换至同一个外部Tuple Y，由内部发出给某个目标Tuple Z后，Z.ip发出的报文均可被接收，端口不限。如果没有向某个Tuple T发送数据包，则T无法主动发送给X。

（3）Port Restricted Cone NAT：在（2）的基础上，加上对端口的限制。即只有Tuple Z的报文可以发送给X，假设Z.ip + 另一个端口，也会失败。

（4）Symmetric NAT：Tuple X不再和（1）-（3）一样建立稳定的转换关系至某个外部Tuple Y，而是随着目的地址和端口的不同动态分配IP/Port，使得关系较为复杂。

#### 1.2 NAT穿透介绍 ####

NAT穿透的常见实现方式主要包括两种：

（1） 通过路由器支持端口映射从而实现P2P通信，该类包括upnp和nat-pmp，优点在于易于实现、延迟小、对服务器无负担，缺点在于需要路由器支持并打开相应功能。

（2） STUN/TURN/ICE协议簇，通过服务器的协调作用实现P2P通信。优点在于稳定可靠，缺点在于需要多次通信，在最坏情况需要依靠中继完成通信，对于游戏服务器来说会有一定的负担。

本文重点在于分析ICE架构的实现方式、当前的ICE开源项目以及可能的实现方式。

## 2. STUN介绍 ##

STUN最早在RFC3489中定义为NAT穿透工具：STUN - Simple Traversal of UDP Through NATs，之后在RFC5389中更名为Session Traversal Utilities for NAT (STUN)。

由其名字的变化可以看到，STUN设计初衷是作为NAT穿透的工具，但是随着后续TURN和ICE的出现，其功能被细化，明确规定为实现NAT穿透功能中的一部分工具。其主要功能在于根据NAT不同类型的特点，对客户端进行检测和类型判断，并将其判断结果传给客户端以及NAT穿透工具实现穿透。下图为RFC文档中描述的整个检测流程图。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70]  
  假设客户端为A，STUN服务器为S，这里要求S至少提供两个IP和端口。

（1）STEP1判断客户端是否在NAT后

A向S的IP1:pot1端口发送一个UDP 包。S收到这个包后，会把它收到包的源IP和port写到UDP包中，然后把此包通过IP1和port1发还给A。这个IP和port也就是NAT的外网 IP和port。当A收到此UDP后，把此UDP中的IP和自己的IP做比较，如果是一样的，就说明自己是在公网，再检测是否有防火墙。如果不一样，说明有NAT的存在，系统进行STEP2的操作。

（2）STEP2是否是Full Cone NAT

A向S的IP1发送一个UDP包，请求S通过另外一个IP2和PORT向A返回一个UDP数据包。如果A收到了这个数据包，说明NAT不对数据包进行任何过滤，即full cone NAT。如果没收到，那么系统进行STEP3的操作。

（3）STEP3是否是Symmetric NAT

A向S的IP2:port2发送一个数据包，S收到数据包后，把它收到包的源IP和port写到UDP包中，然后通过自己的IP2和port2把此包发还给A。如果这个port和step1中的port一样，那么可以肯定这个NAT是个CONE NAT，继续执行STEP4，否则是Symmetric NAT。

（4）STEP4判断是Restrict Cone NAT还是Port Restrict NAT

A向S的IP2的一个端口发送一个数据请求包，要求S用IP2和不同的端口返回一个数据包给A。如果A收到了，那也就意味着只要IP相同，即使port不同，NAT也允许UDP包通过。显然这是Restrict Cone NAT。如果没收到，则是Port Restrict NAT.

## 3. TURN介绍 ##

TURN，在RFC5766中定义为使用中继的NAT穿透方案：STUN的中继扩展 Traversal Using Relays around NAT（TURN）：Relay Extensions to Session Traversal Utilities for NAT（STUN）。简单的说，TURN与STUN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。  
  下图所示为客户端发出建立和A的通道请求，通过之后和A互相通信的过程。注意在这时候通道仅对A生效，B是无法发送给客户端的。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 1]

TURN作为中继传输消息的方式和已有的游戏服务器功能上其实是一致的，用其作为下载中继对服务端负荷过高，因此单独使用TURN没有价值。

## 4. ICE介绍 ##

ICE在RFC5245中的定义为 Interactive Connectivity Establishment (ICE) : A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols，由IETF的MMUSIC工作组开发。ICE跟STUN和TURN不一样，ICE不是一种协议，而是一个框架（Framework），它整合了STUN和TURN使各种NAT穿透技术可以实现统一。

当客户端和ICE服务器通信时，首先会执行STUN的过程检测该客户端的类型，然后根据客户端的类型判断如何进行通信。如下所示为两个客户端A和B通过ICE服务器建立连接的过程。这里为了方便说明假设B在公网或者已经成功打洞，目标是和A建立连接。首先是STUN检测A的NAT类型。

如果A处于公网或者Full Cone Nat下，STUN不做其他的了，因为客户端B可以直接和A进行通信。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 2]  
  如果A处于Restrict Cone或者Port Restrict NAT下，STUN协调TURN进行NAT打洞。STUN首先回复A其NAT类型以及外部IP:Port，然后调用TURN作为中继协调A/B告知对方的IP:Port，然后AB在互发一次消息打洞之后既可以成功的建立双向连接。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 3]  
  如果A处于对称NAT下，那么点对点连接下，ICE判断NAT无法进行打洞。所以为了通信，只能采取最后的手段转成C/S架构，以TURN为中继进行A和B的通信。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 4]

## 5. ICE开源项目介绍 ##

通过搜索发现，目前评价较好的开源ICE实现主要有pjsip和libnice。下表是在官网实际下载、编译过程的总结

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th></th> 
   <th></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td></td> 
   <td>pjsip</td> 
   <td>libnice</td> 
  </tr> 
  <tr> 
   <td>源码包大小</td> 
   <td>45.8M</td> 
   <td>4.7M</td> 
  </tr> 
  <tr> 
   <td>依赖库</td> 
   <td>DirectX SDK（必备）SDL（必备）ffmpeg（可选）OpenH264（可选）MSYS2（可选）</td> 
   <td>glib（必备）zlib（必备）gettext（必备）</td> 
  </tr> 
  <tr> 
   <td>官方参考手册</td> 
   <td>编译和API指引都很详细</td> 
   <td>编译无指引，API详细</td> 
  </tr> 
  <tr> 
   <td>编译体验</td> 
   <td>（1） 有编译指引、依赖包、头文件说明，有sln可以直接使用。支持vs2008和vs2012（2） 依赖库众多，依赖库版本升降也会产生影响，各个依赖库编译也很有难度。</td> 
   <td>（1） 未提供编译指引，仅说明需要的依赖库。最新版未提供sln，旧版有。查阅网上资料发现使用vs2008及之前版本有人成功过，之后版本没有发现成功只有一堆失败的提问。官方倾向于只管理Linux/Mac，未解决Windows下的问题。（2） 依赖库较容易配置</td> 
  </tr> 
  <tr> 
   <td>提供的功能</td> 
   <td>支持SIP, SDP, RTP, STUN, TURN, and ICE，功能强大，主要实现了多媒体通信框架以及NAT穿透两部分功能。</td> 
   <td>1. ICE Library，提供了NiceAgent作为主对象，NiceAddress用于管理IP地址，NiceCandidate管理候选路径。2. STUN Library，供ICE库调用，也可以单独使用 3. Pseudo TCP Socket，基于UDP的可靠UDP实现。</td> 
  </tr> 
 </tbody> 
</table>

综上，总结如下：

*  pjsip优点在于支持全平台、功能齐全、指引详细，缺点在于本身体量较大有冗余功能、依赖库众多而且实际操作复杂。
 *  ibnice优点在于精简、功能满足需求，缺点在于缺乏指引，对windows支持不佳。

## 6. 总结 ##

ICE框架可以实现除了对称性NAT以外客户端的NAT穿透，在一定程度上提高了P2P下载中的客户端群，对于采取DHT方式获取节点进行BT下载有较好的提高，可以作为对不支持upnp/nat-pmp的用户采取的穿透方案。  
  对于对称型NAT，如果为了节约服务器成本，我们可以拒绝连接不加入BT下载中的节点中。该部分其实还可以采取端口猜测的方式使得NAT穿透成功率达到100%，可以纳入后续优化之中继续深入研究和提高。

--------------------

欢迎关注本人公众号，公众号会更新一些不一样的内容，相信一定会有所收获。  
![在这里插入图片描述][20201219120057415.jpg_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70]: /images/20230528/590d48da1baa42f096d7eb74357ccb73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 1]: /images/20230528/662ea771d57d4b168953cc6ecba96ad1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 2]: /images/20230528/3477e2006edc4bf591a5cad5092b8563.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 3]: /images/20230528/c2c577af40d948ef8c39b0583fa7285c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMzNTQ0ODY_size_16_color_FFFFFF_t_70 4]: /images/20230528/81d65df9a8b9463a9e0b679d6bde3665.png
[20201219120057415.jpg_pic_center]: /images/20230528/134454a8576a494eb6aab1ca15421738.png