什么是打洞，为什么要打洞
由于Internet的快速发展 IPV4(网际协议版本4)地址不够用，不能每个主机分到一个公网IP 所以使用NAT地址转换
一般来说都是由私网内主机主动发起连接，数据包经过NAT地址转换后送给公网上的服务器，连接建立以后可双向传送数据，NAT设备允许私网内主机主动向公网内主机发送数据,但却禁止反方向的主动传递，但在一些特殊的场合需要不同私网内的主机进行互联（例如P2P软件、网络会议、视频传输等），TCP穿越NAT的问题必须解决。
nat的几种类型
现在基本使用这种，又分为对称和锥型NAT。
锥型NAT，有完全锥型、受限制锥型、端口受限制锥型三种：
- a)Full Cone NAT（完全圆锥型）：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000 ，192.168.0.8可以收到任意外部主机发到1.2.3.4:62000的数据报。
- b)Address Restricted Cone NAT （地址限制圆锥型）：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000，只有当内部主机192.168.0.8先给服务器C 6.7.8.9发送一个数据报后，192.168.0.8才能收到6.7.8.9发送到1.2.3.4:62000的数据报。
- c)Port Restricted Cone NAT（端口限制圆锥型）：从同一私网地址端口192.168.0.8:4000发至公网的所有请求都映射成同一个公网地址端口1.2.3.4:62000，只有当内部主机192.168.0.8先向外部主机地址端口6.7.8.9：8000发送一个数据报后，192.168.0.8才能收到6.7.8.9：8000发送到1.2.3.4:62000的数据报。
对称NAT：
对于这种NAT。连接不同的外部Server，NAT打开的端口会变化。也就是内部机器A连接外网机器B时，NAT会打开一个端口，连接外网机器C时又会打开另外一个端口。
对于双方都是Port Restricted Cone NAT的时候，则需要利用UDP打洞原理进行“先打洞，然后才能直接通信”。
NAT进行打洞的流程与原理
如果A和B想要进行UDP通信，则必须穿透双方的NAT路由。假设为NAT-A和NAT-B。
A发送数据包到公网S,B发送数据包到公网S,则S分别得到了A和B的公网IP，
S也和A B 分别建立了会话，由S发到NAT-A的数据包会被NAT-A直接转发给A，
由S发到NAT-B的数据包会被NAT-B直接转发给B，除了S发出的数据包之外的则会被丢弃。
所以：现在A B 都能分别和S进行全双工通讯了，但是A B之间还不能直接通讯。
解决办法是：A向B的公网IP发送一个数据包，则NAT-A能接收来自NAT-B的数据包
并转发给A了（即B现在能访问A了）；再由S命令B向A的公网IP发送一个数据包，则
NAT-B能接收来自NAT-A的数据包并转发给B了（即A现在能访问B了）。
以上就是“打洞”的原理。
UDP打洞的过程
1、双方都通过UDP与服务器通讯后，网关默认就是做了一个外网IP和端口号 与你内网IP与端口号的映射，这个无需设置的，服务器也不需要知道客户的真正内网IP
2、用户A先通过服务器知道用户B的外网地址与端口
3、用户A向用户B的外网地址与端口发送消息，
4、在这一次发送中，用户B的网关会拒收这条消息，因为它的映射中并没有这条规则。
5、但是用户A的网关就会增加了一条允许规则，允许接收从B发送过来的消息
6、服务器要求用户B发送一个消息到用户A的外网IP与端口号
7、用户B发送一条消息，这时用户A就可以接收到B的消息，而且网关B也增加了允许规则
8、之后，由于网关A与网关B都增加了允许规则，所以A与B都可以向对方的外网IP和端口号发送消息。
TCP打洞技术
tcp打洞也需要NAT设备支持才行。
tcp的打洞流程和udp的基本一样，但tcp的api决定了tcp打洞的实现过程和udp不一样。
tcp按cs方式工作，一个端口只能用来connect或listen，所以需要使用端口重用，才能利用本地nat的端口映射关系。（设置SO_REUSEADDR，在支持SO_REUSEPORT的系统上，要设置这两个参数。）
连接过程：（以udp打洞的第2种情况为例（典型情况））
nat后的两个peer，A和B，A和B都bind自己listen的端口，向对方发起连接（connect），即使用相同的端口同时连接和等待连接。因为A和B发出连接的顺序有时间差，假设A的syn包到达B的nat时，B的syn包还没有发出，那么B的nat映射还没有建立，会导致A的连接请求失败（连接失败或无法连接，如果nat返回RST或者icmp差错，api上可能表现为被RST；有些nat不返回信息直接丢弃syn包（反而更好）），（应用程序发现失败时，不能关闭socket，closesocket（）可能会导致NAT删除端口映射；隔一段时间（1-2s）后未连接还要继续尝试）；但后发B的syn包在到达A的nat时，由于A的nat已经建立的映射关系，B的syn包会通过A的nat，被nat转给A的listen端口，从而进去三次握手，完成tcp连接。
从应用程序角度看，连接成功的过程可能有两种不同表现：（以上述假设过程为例）
1、连接建立成功表现为A的connect返回成功。即A端以TCP的同时打开流程完成连接。
2、A端通过listen的端口完成和B的握手，而connect尝试持续失败，应用程序通过accept获取到连接，最终放弃connect（这时可closesocket(conn_fd)）。
多数Linux和Windows的协议栈表现为第2种。
但有一个问题是，建立连接的client端，其connect绑定的端口号就是主机listen的端口号，或许这个peer后续还会有更多的这种socket。虽然理论上说，socket是一个五元组，端口号是一个逻辑数字，传输层能够因为五元组的不同而区分开这些socket，但是是否存在实际上的异常，还有待更多观察。
锥形nat打洞
对于Cone NAT.要采用UDP打洞.需要一个公网机器server C来充当”介绍人”.处于NAT之后的内网的A,B先分别和C通信,打开各自的NAT端口.C这个时候知道A,B的公网IP: Port. 现在A和B想直接连接.比如A给B直接发包，除非B是Full Cone，否则不能通信.反之亦然.
为什么啊？因为对于处于NAT之后的A,B。如果想A要与外界的D通信，则首先必须要A发包到D，然后A经过NAT设备NA，NA把A的内网地址和端口转换为NA的外网地址和端口。和D通信之后，D才能经过NA和A通信。也就是说，只能A和外界主动通信，外界不能主动和处于NA之后的A通信。这种包会被NA直接丢弃的。这也就是上面所说的Port Restricted Cone 的情形啊！ A(192.168.8.100:5000) -> NA(202.100.100.100:8000) -> D(292.88.88.88:2000)但是我们可以这样.
A --- NA --- Server C --- NB --- B
- A,B 为主机；
- NA, NB 为NAT设备；
- Server C为外网的机器；
- 如果A想与B通信；
- A首先连接 C, C得到A的外网NA的地址和端口；
- B也要连接C，C得到B的外网NB的地址和端口；
- A告诉C说我要和B通讯；
- C通过NB发信息给B，告诉B A的外网NA的地址和端口；
- B向NA发数据包（肯定会被NA丢弃，因为NA上并没有 A->NB 的合法session），但是NB上就建立了有B->NA的合法session了；
- B发数据包给C，让 C 通知 A，我已经把洞打好了；
- A接受到通知后向 B 的外网发NB数据包，这样就不会被丢弃掉了。因为对于NB来说，它看到的是A的外网NA的地址，而通过第6步，B已经让NA成为NB的合法通信对象了。所以当NA发数据包给NB时，NB就会接收并转发给B；
注意： 路由器和防火墙的UDP打洞的端口有个时间限制的，在一定时间内如果没有数据通讯会自动关闭
STUN
对称型nat打洞
- 为什么可以发送消息，但不过去呢？
IP协议中TTL
把ttl的值设置小一点，比如4，使其路由转发的时候减到0，而把数据包丢弃
在IPv4中, TTL是IP协议的一个8个二进制位的值【0-255】. 这个值可以被认为是数据包在internet系统中可以跳跃的次数上限. TTL是由数据包的发送者设置的, 在前往目的地的过程中, 每经过一台主机或设备, 这个值就要减少一. 如果在数据包到达目的地前, TTL值被减到了0，那么这个包将作为一个ICMP错误的数据包被丢弃。 Linux默认64
很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。
STUN和TURN技术浅析
STUN
STUN（Simple Traversal of User Datagram Protocol Through Network Address Translators），即简单的用UDP穿透NAT，是个轻量级的协议，是基于UDP的完整的穿透NAT的解决方案。它允许应用程序发现它们与公共互联网之间存在的NAT和防火墙及其他类型。它也可以让应用程序确定NAT分配给它们的公网IP地址和端口号。STUN是一种Client/Server的协议，也是一种Request/Response的协议，默认端口号是3478。
流程
应用程序（即STUN CLIENT）向NAT外的STUN SERVER通过UDP发送请求STUN 消息询问自身的转换后地址，STUN SERVER收到请求消息，产生响应消息，响应消息中携带请求消息的源端口，即STUN CLIENT在NAT上对应的外部端口。然后响应消息通过NAT发送给STUN CLIENT，STUN CLIENT通过响应消息体中的内容得知其在NAT上对应的外部地址，并且将其填入以后呼叫协议的UDP负载中，告知对端，同时还可以在终端注册时直接注册这个转换后的公有IP地址，这样就解决了H.323/MGCP/SIP穿越NAT的通信建立问题以及作为被叫时的问题。本端的接收地址和端口号为NAT外的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。
另外STUN server并非指一个专用的服务器，而是指一种功能、一个协议，我们可以在softswitch或者任何一个需要此功能的服务器上内置此协议, 后面代码也包含一个简单的Server实现。
但是在NAT采用对称模式(symmetric NAT)工作时，STUN的方案就会出现问题。假如我们在softswitch上提供STUN server功能，终端A通过STUN可以获得NAT为终端A与softswitch之间通信分配的地址A'，并将这个地址注册在softswitch上，当一个公网上的终端B呼叫终端A时，A'和B通过softswitch完成呼叫建立过程。当B试图向A'发送媒体流时，问题就出现了。因为对称NAT只允许从softswitch发送数据给地址A'，从B发送的媒体流将被丢弃。所以STUN无法应用于工作在对称模式的NAT.
STUN协议最大的优点是无需现有NAT/FW设备做任何改动,同时STUN方式可在多个NAT串联的网络环境中使用. STUN的局限性在于STUN并不适合支持TCP连接的穿越,同时STUN方式不支持对对称NAT（Symmetric NAT）.
TURN
在RFC5766中定义，英文全称Traversal Using Relays around NAT（TURN）：Relay Extensions to Session Traversal Utilities for NAT（STUN），即使用中继穿透NAT：STUN的中继扩展。简单的说，TURN与STUN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。
如果一个主机位于NAT的后面，在某些情况下它不能够与其他主机点对点直接连接。在这些情况下，它需要使用中间网点提供的中继连接服务。TURN协议就是用来允许主机控制中继的操作并且使用中继与对端交换数据。TURN与其他中继控制协议不同的是它能够允许一个客户端使用一个中继地址与多个对端连接。
TURN协议被设计为ICE的一部分，用于NAT穿越，虽然如此，它也可以在没有ICE的地方单独使用。
来源：oschina
链接：https://my.oschina.net/u/4303276/blog/4489879