内容概述：在p2p通信领域中，由NAT(Network Address Translation，网络地址转换)引起的问题已经众所周知了,它会导致在NAT内部的p2p客户端在无论以何种有效的公网ip都无法访问的问题。虽然目前已经发展出多种穿越NAT的技术,但相关的技术文档却很少，用来证明这些技术的稳定性和优点的实际数据更少。本文的目的在于描述和分析在实际中运用得最广泛、最可靠同时也是最简单的一种NAT穿越技术，该技术通常被称为“打洞”技术。目前，“打洞”技术已经在UDP通信领域中得到了广泛的理解和应用，在此，也将讨论如何利用它实现可靠的p2p的TCP流通信。在收集了大量的“打洞”技术可以穿越的NAT设备和网络的数据以后，我们发现82%的已测 NAT设备支持UDP形式的“打洞”穿越，64%的已测NAT设备支持TCP流形式的“打洞”穿越。由于重量级p2p应用程序(如，VOIP、BT、在线游戏等)的用户需求量持续上升，并且该事实也已经引起了NAT设备生产厂商的广泛关注，因此，我们认为未来会有越来越多的NAT设备提供对“打洞”穿越技术的支持。
1、介绍
用户量高速增长以及大量安全问题的巨大压力迫使Internet技术不断向前发展，但是这些新兴的技术很大程度地增加了应用程序开发的成本和复杂性。Internet最初的地址体系是每个节点有一个唯一不变的全局地址，可以通过该地址直接与任何其它的节点进行通信，而现如今，该地址体系已经被新的实际上广泛使用的地址体系所替换，新的地址体系是由全局地址域和通过NAT接入全局地址域的大量私有地址域组成。在新的地址体系中（如图1所示），只有在 “main”全局地址域中的节点可以在网络中很容易地与任何其它的拥有全局地址的节点通信，因为该节点拥有全局的、唯一的、可路由的地址。在私有网络中的节点可以与在同一个私有网络中的其它节点进行通信，并且在通常情况下可以向全局地址中的某个“著名”的节点发起TCP连接或发送UDP数据包。NAT设备在此扮演的角色就是为从内网向公网发起的连接的节点分配临时的转发session，将来自内网的数据包的地址和端口转换为公网的地址和端口，将来自公网的数据包的地址和端口转换为内网的端口和地址，同时NAT将屏蔽所有未经授权的来自公网的数据包。
新的Internet地址体系非常适合于“客户端/服务器”这样的通信模式，一个典型的C/S通信模式是：客户端在内网（私有地址域），服务器在公网（全局地址域），通过NAT将内网和公网连接起来。这种地址体系使得在不同内网（私有地址域）中的两个节点很难直接通信，而这恰恰是p2p应用 (如，电话会议或在线游戏)中最基本的要求。很显然，我们需要一种方法即使在NAT设备存在的前提下，仍然能够无障碍地实现p2p通信。
在不同内网的两个节点之间建立p2p连接的最有效的方法就是“打洞”。该技术在基于UDP的应用程序中得到了广泛的应用，同样的，该技术也可以用于基于TCP的应用程序。有趣的是，与“打洞”字面上的意思刚好相反，该技术不会影响到内网的安全。事实上，“打洞”技术使得p2p软件的绝大部分功能都在NAT设备默认的安全策略的控制之下，这些都由NAT设备建立的session来管理。本文阐述了适用于UDP和TCP的“打洞”技术，并详细描述了重要“打洞”过程中，应用程序和NAT设备之间的行为。
不幸的是，由于NAT设备的响应和行为不是标准的，所以没有任何技术可以穿越现有的所有NAT设备。本文提供了一些在现有NAT设备上进行“打洞”的实验结果。我们收集的数据来自于互联网上使用了“NAT Check”工具并在大量不同生产厂商的NAT设备上进行“打洞”实验的用户。由于数据是来自于一个叫做“self-selecting”的用户社区，或许不会完全代表在Internet上真正部署和使用的NAT设备，但是结果无论如何还是很令人兴奋的。
在做基本的“打洞”操作评估的时候，我们应该指出在现有的NAT设备“打洞”的复杂度上，不同的复杂度会有不同的结果。但目前我们把讨论的重点集中于开发最简单的，可以应用于任何网络拓扑结构的、稳定的、有正确NAT响应的NAT设备上的“打洞”技术。我们有意避免使用一些“聪明的小把戏”通过欺骗某些NAT设备来达到短期内穿越较多的NAT设备，但从长期来看会引起网络未知错误的技术。
尽管引入IPv6会极大地增加互联网的地址空间，从而减少对于NAT设备的需求量，但短期内IPv6确实增加了对NAT设备的需求量，因为 NAT设备本身提供了一种方便的方法进行IPv4与IPv6地址域转换。另外私有网络上建立匿名和加密访问节点也有利于组织机构的安全性以及不受外界干扰，这些都意味着NAT还将存在相当长的一段时间。同样，防火墙技术也不会由于有了足够的ip地址而消失，IPv6的防火墙仍然会默认丢掉所有未经授权的数据包，仍然可以让在IPv6环境下工作的应用程序“打洞”。
本文接下来的部分按照如下的方式组织：第二章介绍基本的NAT穿越概念和术语；第三章介绍UDP“打洞”过程；第四章介绍TCP“打洞”过程；第五章介绍支持“打洞”的NAT设备必须具有那些特性；第六章介绍我们在目前流行的NAT设备上的“打洞”实验结果；第七章讨论相关的网络问题；第八章全文总结以及结束语。
2、基本概念本节介绍了本文使用到的基本的NAT术语，着重描述了适用于UDP和TCP两种协议的通用的NAT穿越技术。
2.1、NAT术语
本文绝大部分术语和分类来自于RFC 2663定义，另外一些来自于较新的RFC 3489中的定义。
理解session是很重要的。一个TCP或UDP的session endpoint是由一个IP地址，端口号组成，每个session是由两个session endpoint构成。从内网节点的角度来看，一个session由4部分组成分别为：本地IP，本地端口，远端IP，远端端口。session的方向通常代表了数据包的初始流动的方向；对于TCP来说就是SYN包的流向，对于UDP来说就是第一个用户数据包的流向。
NAT有很多种，但最普遍的一种类型叫做“传统”NAT，或者“向外”NAT。他们在内网和公网之间提供了一个“不对称”桥的映射。“向外”NAT在默认情况下只允许向外的session穿越NAT：
从外向内的的数据包都会被丢弃掉，除非NAT设备事先已经定义了这些从外向内的数据包是已存在的内网session的一部分。
“外向”NAT会造成p2p协议的混乱，因为当p2p的双方决定向在不同NAT后面的对方开始通信的时候，无论哪一方试图初始化一个session，另一方的NAT都会拒绝这个请求。NAT穿越的核心思想就是让p2p的双方的NAT看上去都是“向外”的NAT。
“向外”NAT有两种类型：（1）“基础”NAT，该NAT只转换IP地址，不转换端口号。（2）NAPT(Network Address/Port Translation)NAPT转换整个session endpoints。由于NAPT允许内网的多个节点通过共享的方式使用同一个的公共的IP地址，因此，支持NAPT的NAT设备才会越来越多。尽管本文通篇讨论的内容都是基于支持NAPT的NAT设备的，但这些规律和技术同样适用于“基础”NAT。
2.2 转发方式
最可靠但同时也是效率最低的p2p穿越NAT进行通信的方法是采用类似C/S方式的转发。假定两个节点A和B每个节点都有向外的TCP或UDP 连接，联入公共的已知服务器S，S的公网IP地址是18.181.0.31，端口号是1234（如图2所示）,每个客户端位于不同的私有内网中，并且它们的NAT设备妨碍了客户端之间直接的p2p连接。做为对直连方案的替代方案，两个客户端可以利用公共的服务器S进行消息的转发。例如，A为了将消息送给 B，A只需将消息发给S，然后由S转发给B，这一过程将使用A与B事先与S建立好的连接。
转发方式通常只能在双方客户端都连接到服务器的时候有效。这种方式的缺点在于，它假定服务器的处理能力和网络带宽以及通信延迟都是理想的情况下，不会受到客户端个数的影响。但是，由于没有其它的方法能够像转发方式那样，可以穿越现存的所有NAT设备，因此在构建高可靠性的p2p系统的时候，通过服务器转发的方式依旧是一个非常有用的保证系统可靠性的方法。TURN协议定义了如何实现安全的转发方式。
2.3 反向连接方式
一些p2p的应用程序采用了直接但是有所限制的技术来实现NAT穿越，该技术叫做“反向连接”，这是用于当两个节点联入服务器S的时候，只有一个一个节点在NAT设备的后面（如图3所示）。如果A希望建立与B的连接，那么A可以直接联入B，因为B是在公网中存在的，没有经过NAT转换，而且A的 NAT设备也允许A直接由内网发起向外网的连接。如果B希望建立与A的连接，很不幸，A的NAT设备会阻止该操作，此时，B可以借助于转发服务器S，向A 发送“反向连接”请求，由A“主动”连接B，从而达到A与B的p2p通信的目的。
尽管该技术的局限性非常明显，但是使用已知的服务器做为中介辅助p2p客户端双方进行p2p连接的思想已经成为了更加通用的“打洞”技术的基本思想。
3 UDP打洞方式
即使两个p2p客户端都位于NAT设备后面，UDP打洞方式也能够通过已知的服务器实现p2p客户端直连。该技术在RFC 3027的第5.1节中曾有所提及，在网络上可以找到对其较模糊的描述，在最近的IP协议实验中得到应用，在多种在线游戏协议中得到了应用。
3.1 集中服务器
打洞技术假定客户端A和B可以与公网内的已知的集中服务器建立UDP连接（可以互发UDP数据包）。当一个客户端在S上登陆的时候，服务器记录下该客户端的两个endpoints（IP地址，UDP端口），一个是该客户端确信自己是通过该ip和端口与服务器S进行通信的，另一个是服务器S记录下的由服务器“观察”到的该客户端实际与自己通信所使用的ip和端口。我们可以把前一个endpoint看作是客户端的内网ip和端口，把后一个 endpoint看作是客户端的内网ip和端口经过NAT转换后的公网ip和端口。服务器可以从客户端的登陆消息的消息体中得到该客户端的内网 endpoint相关信息，可以通过对登陆消息的IP或UDP头得到该客户端的公网endpoint。如果该客户端不是位于NAT设备后面，那么采用上述方法得到的两个endpoint的值应该完全相同。
也有一些“弱智”的NAT设备会扫描UDP数据包的包体，寻找4字节的位域，看上去很像IP地址的位域，并且把它们改为与IP头一样的地址。为了避免这种行为的NAT设备对UDP数据包包体的修改，应用程序可以采用直接对IP地址的值进行加密的方式骗过NAT设备的检查。
3.2 建立p2p的session
假定A要发起对B的直接连接，“打洞”过程如下所示：(endpoint指ip地址和端口的配对)（1）A最初不知道如何向B发起连接，于是A向服务器S发送消息，请求S帮助建立与B的UDP连接。
（2）S将含有B的公网和内网的endpoint发给A，同时，S将含有A的公网和内网的endpoint的用于请求连接的消息也发给B。一旦这些消息顺利到达，A与B就都知道了对方的公网和内网的endpoint。
（3）当A收到由S发来的包含B的公网和内网endpoint的消息，A开始向这些B的endpoint发送UDP数据包，并且A会自动锁定第一个给出响应的B的endpoint。同理，当B收到由S发来的A的公网和内网endpoint以后，也会开始向A的公网和内网的endpoint发送 UDP数据包，并且自动锁定第一个得到A的回应的endpoint。由于A与B的互相向对方发送UDP数据包的操作是异步的，所以A和B发送数据包的时间先后并没有严格的时序要求。
下面我们就来看一下这三个角色之间是如何进行UDP“打洞”的。在这里我们分为三种具体情景来讨论：第一种也是最“简单”的一种情景，两个客户端都位于同一个NAT设备后面，位于同一个内网中；第二种也是最普遍的一种情景，两个客户端分别位于不同的NAT设备后面，分属不同的内网；第三种是客户端位于两层NAT设备之后，通常最上层的NAT是由ISP网络提供商，第二层的NAT是家用的NAT路由器之类的设备。
通常情况下由应用程序自身确定的网络物理层连接方式是很困难的，有时甚至是不可能的，即使是上述的若干种情景下可以穿越NAT，也只是代表在一定时期内有效，而不是永久有效的。诸如STUN之类的网络协议或许可以提供必要的NAT信息，但在遇到多层NAT设备的时候，通常这些信息也不是完全完整和有效的。尽管如此，只要NAT设备的响应是“合理”的，在通常情况下“打洞”技术还是能够在应用程序对网络状况一无所知的前提下自动适用于多数场合。（“合理”的NAT响应将在第五章中详细讨论）
3.3 p2p客户端位于同一个NAT设备后面
首先假设两个客户端位于同一个NAT设备后面，并且位于相同的内网（相同的私有IP地址域）如图4所示。A与S建立了UDP连接，经过NAT转换后，A的公网端口被映射为62000。B同样与S建立了UDP连接，公网端口映射为62005。
(图4)
假设A想通过服务器S做为介绍人，发起对B的连接。A向S发出消息请求与B进行连接。S将B的公网endpoint（即公网ip和port）以及内网endpoint（即内网ip和port）发给A，同时把A的公网、内网的endpoints发给B。由A和B发往对方公网endpoint的 UDP数据包能否被对方收到，这取决于当前的NAT是否支持“发夹”转换（hairpin转换，也就是同一台设备，不同端口之间的UDP数据包能否到达，详见3.5节）。但是A与B往对方内网endpoint发送的UDP数据包是一定可以到达的，无论如何，内网数据包不需要路由，并且速度更快。A与B有很大的可能性采用内网的endpoint进行常规的p2p通信。
假定NAT设备支持“发夹”转换，应用程序也忽略由内网endpoint的连接，那么A、B会采用公网endpoint做为p2p通信的连接，这势必会造成数据包无谓地经过NAT设备，这是一种对资源的浪费。我们会在第六节讨论这种情况，毕竟支持“发夹”转换的NAT设备还远没有对“打洞”技术支持的NAT设备多。就目前的网络情况而言，应用程序在“打洞”的时候，最好还是把公网endpoint和内网endpoint都实验一下。
3.4 p2p客户端位于不同的NAT设备后面
假定A与B在不同的NAT设备后面，分属不同的内网，如图5所示。A与B都经由各自的NAT设备与服务器S建立了UDP连接，A与B的本地端口号均为4321，服务器S的公网端口号为1234。在“向外”session中，A的公网IP被映射为155.99.25.11，公网端口为62000， B的公网IP被映射为138.76.29.7，公网端口为31000。
如下所示：客户端A-->本地IP：10.0.0.1，本地端口:4321，公网IP：155.99.25.11，公网端口：62000客户端B-->本地IP：10.1.1.3，本地端口:4321，公网IP：138.76.29.7，公网端口：31000
(图 5)
在A向服务器S发送的登陆消息体中，会包含A的内网endpoint信息，即10.0.0.1:4321；服务器S会记录下A的内网 endpoint，同时会把自己观察到的A的公网endpoint记录下来，即155.99.25.11:62000。同理，服务器S会记录下B的内网 endpoint，10.1.1.3:4321和由S观察到的B的公网endpoint，138.76.29.7:31000。无论A与B二者任何一方向 S发送p2p连接请求，服务器都会将其记录下来的上述的公网、内网endpoint发送给A、B。
由于A、B分属不同的内网，它们彼此的内网endpoint无法在公网中路由，所以发往各自内网endpoint的UDP数据包会发送到错误的主机或者根本不存在的主机。因此应用程序对于收到的消息必须经过授权和过滤，只有通过授权的的消息才能是从对方的endpoint发出来的，例如，可以在消息中加入对方的程序名称、加密算法，或者至少是一个双方都从服务器S上的预先得到的随机数字。
现在假定A的第一个消息将发往B的公网endpoint，如图5所示。该消息途经A的NAT设备，并在该设备上生成了一个“向外”的 session。新的session源endpoint是10.0.0.1:4321该endpoint和A与服务器S的建立连接的时候NAT生成的源 endpoint一样，但它的目的endpoint不同。如果A的NAT设备给出的响应是“友好”的，那么A的NAT设备将保留A的内网 endpoint，并且所有来自A的源endpoint（10.0.0.1:4321）的数据包都沿用A与S事先建立起来的session，公网 endpoint均为（155.99.25.11:62000）。A向B的公网endpoint发送消息的过程就是“打洞”的过程，从A的内网的角度来看应为从（10.0.0.1:4321）发往（138.76.29.7:31000）,从A的在其NAT设备上建立的session来看，是从（155.99.25.11:62000）发到（138.76.29.7：31000）。
如果A发给B的公网endpoint的消息包在B向A发送消息包之前到达B的NAT设备，B的NAT会认为A发过来的消息是未经授权的公网消息，会丢弃掉该数据包。B发往A的消息包根上述的过程一样，会在B的NAT上建立一个（10.1.1.3：4321，155.99.25.11: 62000）的session（通常也会沿用B与S连接时建立的session，只是该session现在不光可以接受由S发给B的消息，还可以接受从A 的NAT设备-155.99.25.11:6200发来的消息）
一旦A与B都向对方的NAT在公网上的endpoint发送了数据包，就打开了A与B之间的“洞”，A与B向对方的公网endpoint发送数据，等效为向对方的客户端直接发送UDP数据包了。一旦应用程序确认已经可以通过往对方的公网endpoint发送数据包的方式让数据包到达NAT后面的目的应用程序，程序会自动停止继续发送用于“打洞”的数据包，转而开始真正的p2p数据传输。
3.5 p2p客户端位于多层NAT设备后面
有的网络拓扑结构包含了多个NAT设备，如果没有掌握该拓扑结构的详细信息，两个客户端之间是无法建立“最优化”的p2p路由的。现在我们来讨论最后一种情况，如图6所示。假定NAT C是由ISP(Internet Service Provider)提供的工业级的NAT设备，NAT C提供将多个下属的用户NAT或用户节点映射到有限的几个公网IP的服务，NAT A和NAT B做为NAT C的内网节点将把用户的家庭网络或内部网络接入NAT C的内网，然后用户的内部网络就可以经由NAT C访问公网了。从这种拓扑结构上来看，只有服务器S与NAT C是真正拥有公网可路由IP地址的设备，而NAT A和NAT B所使用的“公网”IP地址，实际上是由ISP服务提供商设定的（相对于NAT C而言）内网地址（本位的后续部分我把这个由ISP提供的内网地址相对于NAT A和NAT B称之为“伪”公网地址），同理隶属于NAT A与NAT B的客户端，相对与NAT A，NAT B而言，它们处于NAT A，NAT B的内网，以此类推，客户端可以放到到多层NAT设备后面。客户端A和客户端B发起对服务器S的连接的时候，就会依次在NAT A和NAT B上建立向外的session，而NAT A、NAT B要联入公网的时候，会在NAT C上再建立向外的session。
（图 6）
现在假定客户端A和B希望通过UDP“打洞”完成两个客户端的p2p直连。最优化的路由策略是客户端A向客户端B的“伪公网”IP上发送数据包，即ISP服务提供商指定的内网IP，NAT B的“伪”公网endpoint，10.0.1.2:55000。由于从服务器S的角度只能观察到真正的公网地址，也就是NAT A，NAT B在NAT C建立的session的真正的公网地址155.99.25.11:62000以及155.99.25.11:62005，所以非常不幸，客户端A与客户端B是无法通过服务器S知道这些“伪”公网的地址的。而且即使客户端A和B通过某种手段可以得到NAT A和NAT B的“伪”公网地址，我们仍然不建议采用上述的“最优化”的打洞方式，这是因为这些地址是由ISP服务提供商提供的或许会存在与客户端本身所在的内网地址重复的可能性。（例如：NAT A的内网的IP地址域恰好与NAT A在NAT C的“伪”公网IP地址域重复，这样就会导致打洞数据包无法发出的问题）
因此客户端别无选择，只能使用由公网服务器S观察到的A，B的公网endpoint进行“打洞”操作，用于“打洞”的数据包将由NAT C进行转发，这里NAT C是否支持“发夹”转换或“环路”转换非常重要，否则数据包将无法由NAT C转发给NAT A和NAT B，进而无法到达客户端A和B。当客户端A向客户端B的公网endpoint（155.99.25.11:62005）发送UDP数据包的时候，NAT A首先把数据包的源endpoint由A的内网endpoint（10.0.0.1:4321）转换为“伪”公网endpoint（10.0.1.1: 45000），现在数据包到了NAT C，NAT C应该可以识别出来该数据包是要发往自身转换过的公网endpoint，如果NAT C可以给出“合理”响应的话，NAT C将把该数据包的源endpoint改为155.99.25.11:62000，目的endpoint改为10.0.1.2:55000，即NAT B的“伪”公网endpoint，NAT B最后会将收到的数据包发往客户端B。同样，由B发往A的数据包也会经过类似的过程。也有很多NAT设备不支持类似这样的“发夹”转换，但是已经有越来越多的NAT设备生产厂商开始加入对该转换的支持。
3.6 UDP在空闲状态下的超时问题
由于UDP转换协议提供的“洞”不是绝对可靠的，多数NAT设备内部都有一个UDP转换的空闲状态计时器，如果在一段时间内没有UDP数据通信，NAT设备会关掉由“打洞”操作打出来的“洞”，做为应用程序来讲如果想要做到与设备无关，就最好在穿越NAT的以后设定一个穿越的有效期。很遗憾目前没有标准有效期，这个有效期与NAT设备内部的配置有关，最短的只有20秒左右。在这个有效期内，即使没有p2p数据包需要传输，应用程序为了维持该 “洞”可以正常工作，也必须向对方发送“打洞”维持包。这个维持包是需要双方应用都发送的，只有一方发送不会维持另一方的session正常工作。除了频繁发送“打洞”维持包以外，还有一个方法就是在当前的“洞”有效期过期之前，p2p客户端双方重新“打洞”，丢弃原有的“洞”，这也不失为一个有效的方法。
4 关于TCP打洞技术建立穿越NAT设备的p2p的TCP连接只比UDP复杂一点点，TCP协议的“打洞”从协议层来看是与UDP的“打洞”过程非常相似的。尽管如此，基于TCP协议的打洞至今为止还没有被很好的理解，这也造成了对其提供支持的NAT设备不是很多。在NAT设备支持的前提下，基于TCP的 “打洞”技术实际上与基于UDP的“打洞”技术一样快捷、可靠。实际上，只要NAT设备支持的话，基于TCP的p2p技术的健壮性将比基于UDP的技术的更强一些，因为TCP协议的状态机给出了一种标准的方法来精确的获取某个TCP session的生命期，而UDP协议则无法做到这一点。
4.1 套接字和TCP端口的重用实现基于TCP协议的p2p“打洞”过程中，最主要的问题不是来自于TCP协议，而是来自于来自于应用程序的API接口。这是由于标准的伯克利(Berkeley)套接字的API是围绕着构建客户端/服务器程序而设计的，API允许TCP流套接字通过调用connect()函数来建立向外的连接，或者通过listen()和accept函数接受来自外部的连接，但是，API不提供类似UDP那样的，同一个端口既可以向外连接，又能够接受来自外部的连接。而且更糟的是，TCP的套接字通常仅允许建立1对1的响应，即应用程序在将一个套接字绑定到本地的一个端口以后，任何试图将第二个套接字绑定到该端口的操作都会失败。为了让TCP“打洞”能够顺利工作，我们需要使用一个本地的TCP端口来监听来自外部的TCP连接，同时建立多个向外的TCP连接。幸运的是，所有的主流操作系统都能够支持特殊的TCP套接字参数，通常叫做“SO_REUSEADDR”，该参数允许应用程序将多个套接字绑定到本地的一个endpoint（只要所有要绑定的套接字都设置了SO_REUSEADDR参数即可）。BSD系统引入了SO_REUSEPORT参数,该参数用于区分端口重用还是地址重用，在这样的系统里面，上述所有的参数必须都设置才行。
4.2 打开p2p的TCP流假定客户端A希望建立与B的TCP连接。我们像通常一样假定A和B已经与公网上的已知服务器S建立了TCP连接。服务器记录下来每个联入的客户端的公网和内网的endpoints，如同为UDP服务的时候一样。从协议层来看，TCP“打洞”与UDP“打洞”是几乎完全相同的过程。1、客户端A使用其与服务器S的连接向服务器发送请求，要求服务器S协助其连接客户端B。2、S将B的公网和内网的TCP endpoint返回给A，同时，S将A的公网和内网的endpoint发送给B。3、客户端A和B使用连接S的端口异步地发起向对方的公网、内网 endpoint的TCP连接，同时监听各自的本地TCP端口是否有外部的连接联入。4、A和B开始等待向外的连接是否成功，检查是否有新连接联入。如果向外的连接由于某种网络错误而失败，如：“连接被重置”或者“节点无法访问”，客户端只需要延迟一小段时间（例如延迟一秒钟），然后重新发起连接即可，延迟的时间和重复连接的次数可以由应用程序编写者来确定。5、TCP连接建立起来以后，客户端之间应该开始鉴权操作，确保目前联入的连接就是所希望的连接。如果鉴权失败，客户端将关闭连接，并且继续等待新的连接联入。客户端通常采用“先入为主”的策略，只接受第一个通过鉴权操作的客户端，然后将进入p2p通信过程不再继续等待是否有新的连接联入。
（图 7）
与UDP 不同的是，使用UDP协议的每个客户端只需要一个套接字即可完成与服务器S通信，并同时与多个p2p客户端通信的任务，而TCP客户端必须处理多个套接字绑定到同一个本地TCP端口的问题，如图7所示。现在来看更加实际的一种情景，A与B分别位于不同的NAT设备后面，如图5所示，并且假定图中的端口号是 TCP协议的端口号，而不是UDP的端口号。图中向外的连接代表A和B向对方的内网endpoint发起的连接，这些连接或许会失败或者无法连接到对方。如同使用UDP协议进行“打洞”操作遇到的问题一样，TCP的“打洞”操作也会遇到内网的IP与“伪”公网IP重复造成连接失败或者错误连接之类的问题。客户端向彼此公网endpoint发起连接的操作，会使得各自的NAT设备打开新的“洞”允许A与B的TCP数据通过。如果NAT设备支持TCP“打洞” 操作的话，一个在客户端之间的基于TCP协议的流通道就会自动建立起来。如果A向B发送的第一个SYN包发到了B的NAT设备，而B在此前没有向A发送 SYN包，B的NAT设备会丢弃这个包，这会引起A的“连接失败”或“无法连接”问题。而此时，由于A已经向B发送过SYN包，B发往A的SYN包将被看作是由A发往B的包的回应的一部分，所以B发往A的SYN包会顺利地通过A的NAT设备，到达A，从而建立起A与B的p2p连接。
4.3 从应用程序的角度来看TCP“打洞”从应用程序的角度来看，在进行TCP“打洞”的时候都发生了什么呢？假定A首先向B发出SYN包，该包发往B的公网 endpoint，并且被B的NAT设备丢弃，但是B发往A的公网endpoint的SYN包则通过A的NAT到达了A，然后，会发生以下的两种结果中的一种，具体是哪一种取决于操作系统对TCP协议的实现：（1）A的TCP实现会发现收到的SYN包就是其发起连接并希望联入的B的SYN包，通俗一点来说就是“说曹操，曹操到”的意思，本来A要去找B，结果B自己找上门来了。A的TCP协议栈因此会把B做为A向B发起连接connect的一部分，并认为连接已经成功。程序A调用的异步connect()函数将成功返回，A的listen()等待从外部联入的函数将没有任何反映。此时，B联入A的操作在A程序的内部被理解为A联入B连接成功，并且A开始使用这个连接与B开始p2p通信。由于收到的SYN包中不包含A需要的ACK数据，因此，A的TCP将用 SYN-ACK包回应B的公网endpoint，并且将使用先前A发向B的SYN包一样的序列号。一旦B的TCP收到由A发来的SYN-ACK包，则把自己的ACK包发给A，然后两端建立起TCP连接。简单的说，第一种，就是即使A发往B的SYN包被B的NAT丢弃了，但是由于B发往A的包到达了A。结果是，A认为自己连接成功了，B也认为自己连接成功了，不管是谁成功了，总之连接是已经建立起来了。（2）另外一种结果是，A的TCP实现没有像（1）中所讲的那么“智能”，它没有发现现在联入的B就是自己希望联入的。就好比在机场接人，明明遇到了自己想要接的人却不认识，误认为是其它的人，安排别人给接走了，后来才知道是自己错过了机会，但是无论如何，人已经接到了任务已经完成了。然后，A通过常规的listen()函数和accept()函数得到与B的连接，而由A发起的向B的公网endpoint的连接会以失败告终。尽管A向B的连接失败，A仍然得到了B发起的向A的连接，等效于A与B之间已经联通，不管中间过程如何，A与B已经连接起来了，结果是A和B的基于TCP协议的p2p连接已经建立起来了。第一种结果适用于基于BSD的操作系统对于TCP的实现，而第二种结果更加普遍一些，多数linux和windows系统都会按照第二种结果来处理。