P2P技术 一
P2P技术翻译，主要UDP hole punching技术
P2P技术翻译，主要UDP hole punching技术，经过测试证明有可行性，但也受其制约条件影响
2. 对于使用NAT的P2P通讯的技术
这一部分从细节上描述当前所知的技术对于实现在NAT存在的情况下的P2P通讯，来自应用程序或协议设计者的观点。
2.1. 中继站
大多数可靠的，至少是有效的在NAT存在的情况下实现P2P通讯的方法就是使P2P通讯依赖于网络就像客/服(C/S)通讯。例如，支持两个客户端的主机 A 和 B ，已经各自发起TCP或UDP连接到一个众所周知的有固定IP地址的服务器 S。客户端 A 和 B 两个都居于网络地址解析器后面的私有地址网络中，但是他们两个都没有控制一个公共的IP地址或者固定不变的TCP或UDP端口以使引入到他们的连接能够被直接建立。
Server S
|
|
+----------------------+----------------------+
| |
NAT A NAT B
| |
| |
Client A Client B
不是试图在客户端 A 和 B 之间建立一种直接的TCP或UDP连接，而是两个客户端能够简单的使用服务器 S 来中转他们之间的消息。例如，发送一个消息到客户端 B，那么客户端 A 简单的发送消息到服务器 S 沿着他们已经建立的C/S连接，然后服务器 S 发送消息到客户端 B 上也使用它和B已经存在C/S连接。这种方式具有的优势就是只要两个客户端到服务器都具有连通性那么它将永远可以工作。很明显的缺点就是消耗服务器的处理能力和不必要的网络带宽，并且在两个客户端之间的信息等待时间可能被增加了即使服务器有很好的连接（能力）。
2.2. 反向连接（或逆向连接）
第二种方法工作在仅仅客户端中的一个在NAT的后面。例如，假如客户端 A 在NAT的后面但是客户端 B 不在，如下图所示：
Server S
18.181.0.31:1235
|
|
+----------------------+----------------------+
| |
NAT A |
155.99.25.11:62000 |
| |
| |
Client A Client B
10.0.0.1:1234 138.76.29.7:1234
客户端 A 有私有IP地址 10.0.0.1，并且应用程序使用TCP 端口1234。客户端 A 已经和 公共IP 地址为18.181.0.31 端口 1235 的服务器 S 建立一个连接。NAT A 已经分配端口号62000，他的公共IP地址为 155.99.25.11，为了 A 与 S 的会话提供临时的公共端点地址：因此服务器 S 认为客户端A 的IP地址为155.99.25.11，端口为62000。然而客户端 B 有他自己的固定IP地址，138.76.29.7并且P2P的应用程序对于 B 接受TCP连接在端口1234。
现在假设客户端 B 想要发起一个P2P的通讯会话与客户端 A。B 可能首先接通客户端 A 的地址，或者在客户端 A 认为是自己已有的10.0.0.1:1234，或者在被服务器 S 认为的 A 的地址155.99.25.11:62000。但是以这两种情况，连接将会失败。以第一种情况，直接通信到IP地址10.0.0.1将会完全被网络终止，因为10.0.0.1不是一个公共的路由IP地址。以第二种情况，TCP SYN请求从 B 将会直接的到达 NAT A 端口62000，但是 NAT A 通常将会拒绝连接请求通过一个RST包，因为仅仅向外发出的连接是被允许的。
在试图建立一个直接的到 A 的连接的失败后，客户端 B 能够使用服务器 S 来中转一个请求到客户端 A，使 A 发出一个"反向的"连接请求到达客户端 B。客户端在收到这个通过 S 中转的要求后，开始一个TCP连接到 B 在 B 的公共IP地址和端口号上。NAT A 允许连接发生因为它是在防火墙内部发起的，而 B 能够接受连接是因为它没有在NAT的后面。
大部分当前的P2P系统执行这种方法。当然，它的主要局限性就是这种工作方式仅仅在通讯点中的一方在NAT的后面：如果通讯点都在NAT后面，那么这种方法就作废了。因为反向连接不是一种通用的解决问题方法，他也不被推荐作为首选的策略。应用程序可以选择试图反向连接，但是这种方式应该可以自动后退到另一种机制同时被搁置，例如在中继站既不是一种"正向"也不是一种"反向"连接能够被建立的情况下。
2.3 UDP Hole Punching
第三种方法，也就是这篇文章最感兴趣的一种，有时被叫做"UDP Hole Punching" 。
UDP Hole Punching依赖于已经建立好的NAT协定来允许被恰当设计的P2P应用程序"punch holes"（穿孔）通过NAT和防火墙并且相互之间建立直接的连接，即使当两个正在通讯的主机可能位于同一个NAT的后面。这种方法在RFC 3027 [NAT-PROT]中的5.1部分被简单的提到而且在Internet[KEGEL]被非正式的描述。很不幸，根据名字的意思，这种方法工作的可靠性仅仅对于使用UDP而言。
我们将要考虑两种特殊的情景，以及应用程序如何能够被设计成合适的处理这两种情形。第一种情况，描绘一种普遍情况，希望点对点通讯的两个客户端居于不同的NAT的后面。第二种情况，两个客户端实际上居于同一个NAT的后面，但是（客户端）未必知道他们的这种情况。
2.3.1. 客户端位于不同的NAT的后面
假设客户端 A 和 B 两个都有私有IP地址并且位于不同的网络地址解析器后面。P2P应用程序运行于客户端 A 和 B 以及服务器 S ，各自使用UDP端口1234。A 和 B 已经各自发出UDP通讯会话同服务器 S ，从而分别导致NAT A 分配他的公共UDP端口62000 对于 A 同 S 的会话，NAT B分配他的公共UDP端口31000 对于 B 同 S 的会话。
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
现在假设客户端 A 想要与客户端 B 直接建立一个UDP通讯会话。假如 A 简单的发送UDP请求到 B 的公共地址 138.76.29.7:31000 ，那么NAT B将通常丢弃这个到来的消息，因为源地址和端口号与和他所发起的外部会话建立连接的服务器 S 不匹配。类似的，如果 B 简单的发送UDP请求到 A 的公共地址，那么NAT A也将丢弃这个消息。
假设 A 发送UDP请求到 B 的公共地址，但是同时的转播一个消息通过服务器 S 到达 B，要求 B 发送UDP请求到 A 的公共地址。A 的往外去的消息直接的到达 B 的公共地址(138.76.29.7:31000)将会使得NAT A开始一个新的通讯会话在 A 的私有地址和 B 的公共地址之间，同时，B 的消息（A通过S要求B发送的）到达 A 的公共地址(155.99.25.11:62000)将会使得NAT B开始一个新的通讯会话在 B 的私有地址和 A 公共地址之间。一旦新的UDP会话在每一方向上开始，那么客户端 A 和 B 就能够相互之间直接的通信而不需要借助服务器 S 了。
UDP hole punching 方法有几个很有用的特性。一旦一个直接的点对点的UDP连接在两个NAT后面的客户端之间建立，那么连接中的任一部分都能够轮流充当"介绍人"的角色来帮助另一部分建立同其他的点建立P2P连接，这个最小的连接负载（也就是最小的连接数量）是在服务器 S 初始化时产生的。应用程序不需要试图明确的检测它究竟在哪一个NAT的后面，即使需要[STUN]，因为以上的程序将要建立P2P通讯通道同样假设客户端中的一端或两端不在同一个NAT的后面。UDP hole punching方法甚至可以自动工作在"双重NAT"，也就是一个或两个客户端要经过两层或更多的地址解析。
2.3.2 客户端在相同的NAT后面
现在考虑两个客户端（可能不知道）居于相同的NAT后面的情况，也就是存在于相同的私有地址空间中。客户端 A 已经建立一个UDP会话同服务器 S ，到达 S 的公共NAT已经分配公共端口62000。
客户端 B 也已经建立一个UDP会话同服务器 S ，到达 S 的公共NAT已经分配公共端口620001。
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
假设 A 和 B 使用UDP hole punching方法作为方案，使用服务器 S 作为引导来建立一个通讯通道。那么 A 和 B就可以互相知道对方的公共IP地址和端口号也就是被服务器 S 观察的（IP和端口），并且相互发送消息在公共地址上。这两个客户端将能够以这种方式相互通话，只有在NAT允许内部网络的主机开通解释和内部的其他主机的UDP会话而不是外部主机的情况下。例如，当 A 发送一个UDP包到 B 的公共地址，最初的包有一个源IP地址和端口号10.0.0.1:1234以及一个目的IP地址和端口号155.99.25.11:62001。NAT接收这个包，解释他的源地址和端口号55.99.25.11:62000（A的公共地址）以及目的地址和端口号10.1.1.3:1234，然后转寄这个包到 B。即使被NAT支持，这种解释和转寄的步骤在这种环境下很明显也是不必要的，可能增加了反应时间对于 A 和 B 之间的对话，同时增加NAT的负担。
然而这个问题的解决方法是很简单的。当 A 和 B 最初通过服务器 S 交换地址信息时，他们应该包含被他们自己所观察到的IP地址和端口号以及被S观察到的地址(就是公网和私网地址)。两个客户端同时的发送包到对方，以他们知道的两个地址（译者注：我理解是 A 和 B 同时发送两个包，分别发往对方的公网和私网地址，依据下面解释），然后使用第一个连接成功的地址。如果两个客户端在同一个NAT的后面，那么直接到达他们的私有地址的包可能会第一个到达，从而直接的通讯通道没有包含NAT。如果两个客户端在不同的NAT的后面，那么直接发往对方私有地址的包将根本不可能到达，但是两个客户端将很有可能使用他们各自的公共地址建立连接。然而这些包通过一些方法被验证是很重要的，既然在不同的NAT的情况下，A 的消息到达 B 中私有地址的其他的主机节点（反之亦然）是完全有可能的。
2.3.3 固定端口映射
the hole punching技术有一个很重要的告诫：他起作用仅仅假设每一个NAT维持着一个单独的、固定的映射从一个给定的部分（私有IP地址和UDP端口号）到一个解析的部分（公共IP地址和UDP端口号），对于在使用中的UDP端口。对于一个在私网给定的UDP端口，NAT必须保证内部端口总是映射到在全部可定址的Internet上的相同的UDP端口，即使通讯产生在内部UDP端口和在Internet多重不同的外部目的地之间。尤其是，NAT没有必要正确无误的分配和指派一个新的UDP端口为防火墙内部的每一个发起的会话，这个会话是被两个正在通话的终端的地址和端口号定义的。分配一个新的公共端口为每一个新的会话，使得对于一个UDP应用程序来重新使用一个已经建立的（公共IP地址和公共UDP端口）映射（为不同的外部目的主机通讯建立的）是不可能。
然而RFC 3022[NAT-TRAD]建议并且明确的允许NAT维持一个单独的映射从一个部分（私有IP地址和端口）到另一部分（公共IP地址和端口），很不幸，却没有书面要求这种行为。因此，当大部分的NAT实现这种值得做的方法并且因此允许使用the hole punching技术直接的基于UDP的P2P通讯的时候，另一部分当前的NAT却不支持这种技术。因为这是所知的对于建立直接的P2P通讯在两个客户端都在NAT后面并且运行在多种多样的以存在的NAT的情况下最有效的方法，使用这种方法也是被推荐的如果需要有效的P2P通讯，但是也要做好倒退到简单的中继方式，当直接的通讯不能够被建立的时候。
2.4 UDP 端口号预测
很多的UDP hole punching 技术讨论是在允许点对点的UDP会话被创建当一些NAT存在的情况下，这些NAT没有维持一个固定的映射在私有和公共的UDP端口间。这种方法（2.4的方法），有时被叫做"N+1"技术[BIDIR]，工作在假设被NAT选择的公共端口号没有容纳固定的以及起源于一个给定的私有IP地址和端口号的所有会话，但是仍然是可预测的（这句话请看原文！！没翻译好）。再一次考虑这两个客户端的情况，A 和 B，每一个都在单独的NAT后面，已经建立了UDP连接同一个定址的服务器S。
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
NAT A已经分配了他的UDP端口62000对于A 和 S 之间的通讯，并且 NAT B已经分配了他的端口31000对于 B 和 S之间的通讯。通过经过服务器 S 的通讯，A 和 B 互相知道了他们彼此被 S 观察到的公共IP地址和端口号。客户端 A 现在开始发送一个UDP消息到端口31001地址为138.76.29.7（注意端口号的增加），同样的，客户端 B 现在开始发送消息到端口62001地址为155.99.25.11。假如NAT A 和NAT B 继续的分配端口号对于新的会话，并且没有过去太多时间自从 A-S 和 B-S 的会话被发起的时候，然后一个 A 和 B 之间工作的双向通讯通道就应该有结果。A 的消息到 B 导致 NAT A 开辟一个新会话，也就是NAT A 将要分配公共端口号62001给这个会话，因为62001是端口号62000 的下一个连续的端口号，62000是先前那个分配给 A 和 S之间会话的。同样的，B 的消息到 A 将导致NAT B开辟一个新的会话，也就是NAT B将要分配公共端口号31001给这个会话。如果两个客户端已经正确的猜到了每一个NAT分配给新会话的端口号，那么一个双向的UDP通讯通道就像上面说的一样已经建立了。
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
A-B 155.99.25.11:62001 B-A 138.76.29.7:31001
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
很明显的，有很多事情都能够导致这个方法失败。假如在每个NAT中被预测的端口号已经被一个不相干的会话使用了，那么NAT将忽略那个端口号并且联接尝试将会失败。假如每个NAT有时或者总是不连续的选择端口号，那么这个方法也将失败。假如在NAT A（或者NAT B）后面的一个不同的客户端打开一个对外的UDP连接到其他外部的目的地，在A（B）建立同 S 的连接之后，在 A（B）发送他的第一个消息给B（A）以前，那么这个不相干的客户端将非有意的"偷走"那个期望的端口号。这种方法因此很不可靠，当每一个复杂的NAT在负载的情况下。根据以上的原因，新的应用程序实现这种方法是不被建议的。在这里描述这种方法纯粹是因为历史和情报的目的。
2.5 同时发生的TCP连接初始
有一种方法能够被用来使用在一些地方来建立直接的点对点的TCP连接在两个都在NAT后面的两个节点。大多数的TCP会话开始和一个终端建立连接都发送一个SYN包，对于这个包的响应另一部分回送一个SYN-ACK包。然而这种情况是可行以及合法的，对于两个终端开始一个TCP会话通过同时的发送到对方 SYN包，作为回应这个包，双方又各自回应使用各自的SYN-ACK包。这种过程被称作"simultaneous open"（同时开始打开）。
假如一个NAT收到一个TCP SYN包从正在尝试与内部建立TCP连接的外部的私有网络，那么NAT将通常拒绝连接企图通过发送回一个TCP RST(connection reset)包。然而，假如SYN包到达包含有源与目的地，且与NAT已经相信是活动的TCP会话相符的地址和端口号，那么NAT将允许那个包通过。尤其是，假如NAT就在当前已经观察并且发出一个对外的SYN包，使用相同的地址和端口号，那么它将认为会话活动的并且允许进入的SYN包。假如客户端 A 和 B能够互相正确的预测他们各自的NAT将要为下一个对外的TCP连接的公共的端口号，并且假设每一个客户端初始一个对外的TCP连接和另一个客户端同步的，以至于每一个客户端的对外SYN包在每一方的SYN包到达对方的NAT以前通过它的本地NAT（译者注：就是当外部进来的SYN包到达前，内部发出的 SYN包一定要先发出去），那么点对点的TCP连接就可以建立了。
很不幸的是，这种方法甚至更脆弱并且对时间的敏感程度超过了上面描述的UDP端口号预测技术。首先，所有相同的事情都能互相导致错误，每一边试图预测 NAT将要分配给新会话的公共端口号。另外如果每个客户端的SYN到达对方的NAT太快，那么NAT将通过一个RST包拒绝SYN，导致本地的NAT依次关闭新的会话。最后，尽管支持"同步打开"通常是一种TCP规范[TCP]的强制部分，但是它并没有被正确的执行或者根本就没有在众多普通的操作系统中应用。基于这个原因，这个方法同样的在这里提到仅仅为了历史原因；这种方法被应用程序使用不被推荐。要求有效的直接的点对点的应用程序应当使用UDP。
--------------------------------------------------------------------------------
P2P之UDP穿透NAT的原理与实现（附源代码）
作者：shootingstars (有容乃大，无欲则刚) 日期：2004-5-25
出处：P2P中国(PPcn.net)
P2P 之 UDP穿透NAT的原理与实现（附源代码）
原创：shootingstars
参考：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
论坛上经常有对P2P原理的讨论，但是讨论归讨论，很少有实质的东西产生（源代码）。呵呵，在这里我就用自己实现的一个源代码来说明UDP穿越NAT的原理。
首先先介绍一些基本概念：
NAT(Network Address Translators)，网络地址转换：网络地址转换是在IP地址日益缺乏的情况下产生的，它的主要目的就是为了能够地址重用。NAT分为两大类，基本的NAT和NAPT(Network Address/Port Translator)。
最开始NAT是运行在路由器上的一个功能模块。
最先提出的是基本的NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。
因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的 IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP 包中的原IP地址，但是不会改变IP包中的端口)
关于基本的NAT可以参看RFC 1631
另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的 TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT才是我们真正讨论的主角。看下图：
Server S1
18.181.0.31:1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 155.99.25.11:62000 v |
|
NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
有一个私有网络10.*.*.*，Client A是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如 10.0.0.10)。如果Client A中的某个进程（这个进程创建了一个UDP Socket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？
首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000 ->18.181.0.31:1235）。
一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从18.181.0.31发送到 62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000端口的数据会被转发，其他的 IP发送到这个端口的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。
呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。
看看下面的情况：
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？
这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是 NAT再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT，后一种叫做Cone NAT。我们期望我们的NAT是第二种，呵呵，如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（可以庆幸的是，现在绝大多数的NAT属于后者，即Cone NAT）
好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。
但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。
那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个 Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP Hole Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。
呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。
现在我们来看看一个P2P软件的流程，以下图为例：
Server S （219.237.60.1）
|
|
+----------------------+----------------------+
| |
NAT A (外网IP:202.187.45.3) NAT B (外网IP:187.34.1.56)
| (内网IP:192.168.0.1) | (内网IP:192.168.0.1)
| |
Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)
首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，Client B登录Server S，NAT B给此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
此时，Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B，那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000，是不是Client A向这个地址发送信息Client B就能收到了呢？答案是不行，因为如果这样发送信息，NAT B会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。现在我们需要的是在NAT B上打一个方向为202.187.45.3（即Client A的外网地址）的洞，那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢，呵呵，当然是Server S。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
P2P技术翻译，主要UDP hole punching技术
P2P技术翻译，主要UDP hole punching技术，经过测试证明有可行性，但也受其制约条件影响
2. 对于使用NAT的P2P通讯的技术
这一部分从细节上描述当前所知的技术对于实现在NAT存在的情况下的P2P通讯，来自应用程序或协议设计者的观点。
2.1. 中继站
大多数可靠的，至少是有效的在NAT存在的情况下实现P2P通讯的方法就是使P2P通讯依赖于网络就像客/服(C/S)通讯。例如，支持两个客户端的主机 A 和 B ，已经各自发起TCP或UDP连接到一个众所周知的有固定IP地址的服务器 S。客户端 A 和 B 两个都居于网络地址解析器后面的私有地址网络中，但是他们两个都没有控制一个公共的IP地址或者固定不变的TCP或UDP端口以使引入到他们的连接能够被直接建立。
Server S
|
|
+----------------------+----------------------+
| |
NAT A NAT B
| |
| |
Client A Client B
不是试图在客户端 A 和 B 之间建立一种直接的TCP或UDP连接，而是两个客户端能够简单的使用服务器 S 来中转他们之间的消息。例如，发送一个消息到客户端 B，那么客户端 A 简单的发送消息到服务器 S 沿着他们已经建立的C/S连接，然后服务器 S 发送消息到客户端 B 上也使用它和B已经存在C/S连接。这种方式具有的优势就是只要两个客户端到服务器都具有连通性那么它将永远可以工作。很明显的缺点就是消耗服务器的处理能力和不必要的网络带宽，并且在两个客户端之间的信息等待时间可能被增加了即使服务器有很好的连接（能力）。
2.2. 反向连接（或逆向连接）
第二种方法工作在仅仅客户端中的一个在NAT的后面。例如，假如客户端 A 在NAT的后面但是客户端 B 不在，如下图所示：
Server S
18.181.0.31:1235
|
|
+----------------------+----------------------+
| |
NAT A |
155.99.25.11:62000 |
| |
| |
Client A Client B
10.0.0.1:1234 138.76.29.7:1234
客户端 A 有私有IP地址 10.0.0.1，并且应用程序使用TCP 端口1234。客户端 A 已经和 公共IP 地址为18.181.0.31 端口 1235 的服务器 S 建立一个连接。NAT A 已经分配端口号62000，他的公共IP地址为 155.99.25.11，为了 A 与 S 的会话提供临时的公共端点地址：因此服务器 S 认为客户端A 的IP地址为155.99.25.11，端口为62000。然而客户端 B 有他自己的固定IP地址，138.76.29.7并且P2P的应用程序对于 B 接受TCP连接在端口1234。
现在假设客户端 B 想要发起一个P2P的通讯会话与客户端 A。B 可能首先接通客户端 A 的地址，或者在客户端 A 认为是自己已有的10.0.0.1:1234，或者在被服务器 S 认为的 A 的地址155.99.25.11:62000。但是以这两种情况，连接将会失败。以第一种情况，直接通信到IP地址10.0.0.1将会完全被网络终止，因为10.0.0.1不是一个公共的路由IP地址。以第二种情况，TCP SYN请求从 B 将会直接的到达 NAT A 端口62000，但是 NAT A 通常将会拒绝连接请求通过一个RST包，因为仅仅向外发出的连接是被允许的。
在试图建立一个直接的到 A 的连接的失败后，客户端 B 能够使用服务器 S 来中转一个请求到客户端 A，使 A 发出一个"反向的"连接请求到达客户端 B。客户端在收到这个通过 S 中转的要求后，开始一个TCP连接到 B 在 B 的公共IP地址和端口号上。NAT A 允许连接发生因为它是在防火墙内部发起的，而 B 能够接受连接是因为它没有在NAT的后面。
大部分当前的P2P系统执行这种方法。当然，它的主要局限性就是这种工作方式仅仅在通讯点中的一方在NAT的后面：如果通讯点都在NAT后面，那么这种方法就作废了。因为反向连接不是一种通用的解决问题方法，他也不被推荐作为首选的策略。应用程序可以选择试图反向连接，但是这种方式应该可以自动后退到另一种机制同时被搁置，例如在中继站既不是一种"正向"也不是一种"反向"连接能够被建立的情况下。
2.3 UDP Hole Punching
第三种方法，也就是这篇文章最感兴趣的一种，有时被叫做"UDP Hole Punching" 。
UDP Hole Punching依赖于已经建立好的NAT协定来允许被恰当设计的P2P应用程序"punch holes"（穿孔）通过NAT和防火墙并且相互之间建立直接的连接，即使当两个正在通讯的主机可能位于同一个NAT的后面。这种方法在RFC 3027 [NAT-PROT]中的5.1部分被简单的提到而且在Internet[KEGEL]被非正式的描述。很不幸，根据名字的意思，这种方法工作的可靠性仅仅对于使用UDP而言。
我们将要考虑两种特殊的情景，以及应用程序如何能够被设计成合适的处理这两种情形。第一种情况，描绘一种普遍情况，希望点对点通讯的两个客户端居于不同的NAT的后面。第二种情况，两个客户端实际上居于同一个NAT的后面，但是（客户端）未必知道他们的这种情况。
2.3.1. 客户端位于不同的NAT的后面
假设客户端 A 和 B 两个都有私有IP地址并且位于不同的网络地址解析器后面。P2P应用程序运行于客户端 A 和 B 以及服务器 S ，各自使用UDP端口1234。A 和 B 已经各自发出UDP通讯会话同服务器 S ，从而分别导致NAT A 分配他的公共UDP端口62000 对于 A 同 S 的会话，NAT B分配他的公共UDP端口31000 对于 B 同 S 的会话。
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
155.99.25.11:62000 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
现在假设客户端 A 想要与客户端 B 直接建立一个UDP通讯会话。假如 A 简单的发送UDP请求到 B 的公共地址 138.76.29.7:31000 ，那么NAT B将通常丢弃这个到来的消息，因为源地址和端口号与和他所发起的外部会话建立连接的服务器 S 不匹配。类似的，如果 B 简单的发送UDP请求到 A 的公共地址，那么NAT A也将丢弃这个消息。
假设 A 发送UDP请求到 B 的公共地址，但是同时的转播一个消息通过服务器 S 到达 B，要求 B 发送UDP请求到 A 的公共地址。A 的往外去的消息直接的到达 B 的公共地址(138.76.29.7:31000)将会使得NAT A开始一个新的通讯会话在 A 的私有地址和 B 的公共地址之间，同时，B 的消息（A通过S要求B发送的）到达 A 的公共地址(155.99.25.11:62000)将会使得NAT B开始一个新的通讯会话在 B 的私有地址和 A 公共地址之间。一旦新的UDP会话在每一方向上开始，那么客户端 A 和 B 就能够相互之间直接的通信而不需要借助服务器 S 了。
UDP hole punching 方法有几个很有用的特性。一旦一个直接的点对点的UDP连接在两个NAT后面的客户端之间建立，那么连接中的任一部分都能够轮流充当"介绍人"的角色来帮助另一部分建立同其他的点建立P2P连接，这个最小的连接负载（也就是最小的连接数量）是在服务器 S 初始化时产生的。应用程序不需要试图明确的检测它究竟在哪一个NAT的后面，即使需要[STUN]，因为以上的程序将要建立P2P通讯通道同样假设客户端中的一端或两端不在同一个NAT的后面。UDP hole punching方法甚至可以自动工作在"双重NAT"，也就是一个或两个客户端要经过两层或更多的地址解析。
2.3.2 客户端在相同的NAT后面
现在考虑两个客户端（可能不知道）居于相同的NAT后面的情况，也就是存在于相同的私有地址空间中。客户端 A 已经建立一个UDP会话同服务器 S ，到达 S 的公共NAT已经分配公共端口62000。
客户端 B 也已经建立一个UDP会话同服务器 S ，到达 S 的公共NAT已经分配公共端口620001。
Server S
18.181.0.31:1234
|
|
NAT
A-S 155.99.25.11:62000
B-S 155.99.25.11:62001
|
+----------------------+----------------------+
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
假设 A 和 B 使用UDP hole punching方法作为方案，使用服务器 S 作为引导来建立一个通讯通道。那么 A 和 B就可以互相知道对方的公共IP地址和端口号也就是被服务器 S 观察的（IP和端口），并且相互发送消息在公共地址上。这两个客户端将能够以这种方式相互通话，只有在NAT允许内部网络的主机开通解释和内部的其他主机的UDP会话而不是外部主机的情况下。例如，当 A 发送一个UDP包到 B 的公共地址，最初的包有一个源IP地址和端口号10.0.0.1:1234以及一个目的IP地址和端口号155.99.25.11:62001。NAT接收这个包，解释他的源地址和端口号55.99.25.11:62000（A的公共地址）以及目的地址和端口号10.1.1.3:1234，然后转寄这个包到 B。即使被NAT支持，这种解释和转寄的步骤在这种环境下很明显也是不必要的，可能增加了反应时间对于 A 和 B 之间的对话，同时增加NAT的负担。
然而这个问题的解决方法是很简单的。当 A 和 B 最初通过服务器 S 交换地址信息时，他们应该包含被他们自己所观察到的IP地址和端口号以及被S观察到的地址(就是公网和私网地址)。两个客户端同时的发送包到对方，以他们知道的两个地址（译者注：我理解是 A 和 B 同时发送两个包，分别发往对方的公网和私网地址，依据下面解释），然后使用第一个连接成功的地址。如果两个客户端在同一个NAT的后面，那么直接到达他们的私有地址的包可能会第一个到达，从而直接的通讯通道没有包含NAT。如果两个客户端在不同的NAT的后面，那么直接发往对方私有地址的包将根本不可能到达，但是两个客户端将很有可能使用他们各自的公共地址建立连接。然而这些包通过一些方法被验证是很重要的，既然在不同的NAT的情况下，A 的消息到达 B 中私有地址的其他的主机节点（反之亦然）是完全有可能的。
2.3.3 固定端口映射
the hole punching技术有一个很重要的告诫：他起作用仅仅假设每一个NAT维持着一个单独的、固定的映射从一个给定的部分（私有IP地址和UDP端口号）到一个解析的部分（公共IP地址和UDP端口号），对于在使用中的UDP端口。对于一个在私网给定的UDP端口，NAT必须保证内部端口总是映射到在全部可定址的Internet上的相同的UDP端口，即使通讯产生在内部UDP端口和在Internet多重不同的外部目的地之间。尤其是，NAT没有必要正确无误的分配和指派一个新的UDP端口为防火墙内部的每一个发起的会话，这个会话是被两个正在通话的终端的地址和端口号定义的。分配一个新的公共端口为每一个新的会话，使得对于一个UDP应用程序来重新使用一个已经建立的（公共IP地址和公共UDP端口）映射（为不同的外部目的主机通讯建立的）是不可能。
然而RFC 3022[NAT-TRAD]建议并且明确的允许NAT维持一个单独的映射从一个部分（私有IP地址和端口）到另一部分（公共IP地址和端口），很不幸，却没有书面要求这种行为。因此，当大部分的NAT实现这种值得做的方法并且因此允许使用the hole punching技术直接的基于UDP的P2P通讯的时候，另一部分当前的NAT却不支持这种技术。因为这是所知的对于建立直接的P2P通讯在两个客户端都在NAT后面并且运行在多种多样的以存在的NAT的情况下最有效的方法，使用这种方法也是被推荐的如果需要有效的P2P通讯，但是也要做好倒退到简单的中继方式，当直接的通讯不能够被建立的时候。
2.4 UDP 端口号预测
很多的UDP hole punching 技术讨论是在允许点对点的UDP会话被创建当一些NAT存在的情况下，这些NAT没有维持一个固定的映射在私有和公共的UDP端口间。这种方法（2.4的方法），有时被叫做"N+1"技术[BIDIR]，工作在假设被NAT选择的公共端口号没有容纳固定的以及起源于一个给定的私有IP地址和端口号的所有会话，但是仍然是可预测的（这句话请看原文！！没翻译好）。再一次考虑这两个客户端的情况，A 和 B，每一个都在单独的NAT后面，已经建立了UDP连接同一个定址的服务器S。
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
NAT A已经分配了他的UDP端口62000对于A 和 S 之间的通讯，并且 NAT B已经分配了他的端口31000对于 B 和 S之间的通讯。通过经过服务器 S 的通讯，A 和 B 互相知道了他们彼此被 S 观察到的公共IP地址和端口号。客户端 A 现在开始发送一个UDP消息到端口31001地址为138.76.29.7（注意端口号的增加），同样的，客户端 B 现在开始发送消息到端口62001地址为155.99.25.11。假如NAT A 和NAT B 继续的分配端口号对于新的会话，并且没有过去太多时间自从 A-S 和 B-S 的会话被发起的时候，然后一个 A 和 B 之间工作的双向通讯通道就应该有结果。A 的消息到 B 导致 NAT A 开辟一个新会话，也就是NAT A 将要分配公共端口号62001给这个会话，因为62001是端口号62000 的下一个连续的端口号，62000是先前那个分配给 A 和 S之间会话的。同样的，B 的消息到 A 将导致NAT B开辟一个新的会话，也就是NAT B将要分配公共端口号31001给这个会话。如果两个客户端已经正确的猜到了每一个NAT分配给新会话的端口号，那么一个双向的UDP通讯通道就像上面说的一样已经建立了。
Server S
18.181.0.31:1234
|
|
+----------------------+----------------------+
| |
NAT A NAT B
A-S 155.99.25.11:62000 B-S 138.76.29.7:31000
A-B 155.99.25.11:62001 B-A 138.76.29.7:31001
| |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
很明显的，有很多事情都能够导致这个方法失败。假如在每个NAT中被预测的端口号已经被一个不相干的会话使用了，那么NAT将忽略那个端口号并且联接尝试将会失败。假如每个NAT有时或者总是不连续的选择端口号，那么这个方法也将失败。假如在NAT A（或者NAT B）后面的一个不同的客户端打开一个对外的UDP连接到其他外部的目的地，在A（B）建立同 S 的连接之后，在 A（B）发送他的第一个消息给B（A）以前，那么这个不相干的客户端将非有意的"偷走"那个期望的端口号。这种方法因此很不可靠，当每一个复杂的NAT在负载的情况下。根据以上的原因，新的应用程序实现这种方法是不被建议的。在这里描述这种方法纯粹是因为历史和情报的目的。
2.5 同时发生的TCP连接初始
有一种方法能够被用来使用在一些地方来建立直接的点对点的TCP连接在两个都在NAT后面的两个节点。大多数的TCP会话开始和一个终端建立连接都发送一个SYN包，对于这个包的响应另一部分回送一个SYN-ACK包。然而这种情况是可行以及合法的，对于两个终端开始一个TCP会话通过同时的发送到对方 SYN包，作为回应这个包，双方又各自回应使用各自的SYN-ACK包。这种过程被称作"simultaneous open"（同时开始打开）。
假如一个NAT收到一个TCP SYN包从正在尝试与内部建立TCP连接的外部的私有网络，那么NAT将通常拒绝连接企图通过发送回一个TCP RST(connection reset)包。然而，假如SYN包到达包含有源与目的地，且与NAT已经相信是活动的TCP会话相符的地址和端口号，那么NAT将允许那个包通过。尤其是，假如NAT就在当前已经观察并且发出一个对外的SYN包，使用相同的地址和端口号，那么它将认为会话活动的并且允许进入的SYN包。假如客户端 A 和 B能够互相正确的预测他们各自的NAT将要为下一个对外的TCP连接的公共的端口号，并且假设每一个客户端初始一个对外的TCP连接和另一个客户端同步的，以至于每一个客户端的对外SYN包在每一方的SYN包到达对方的NAT以前通过它的本地NAT（译者注：就是当外部进来的SYN包到达前，内部发出的 SYN包一定要先发出去），那么点对点的TCP连接就可以建立了。
很不幸的是，这种方法甚至更脆弱并且对时间的敏感程度超过了上面描述的UDP端口号预测技术。首先，所有相同的事情都能互相导致错误，每一边试图预测 NAT将要分配给新会话的公共端口号。另外如果每个客户端的SYN到达对方的NAT太快，那么NAT将通过一个RST包拒绝SYN，导致本地的NAT依次关闭新的会话。最后，尽管支持"同步打开"通常是一种TCP规范[TCP]的强制部分，但是它并没有被正确的执行或者根本就没有在众多普通的操作系统中应用。基于这个原因，这个方法同样的在这里提到仅仅为了历史原因；这种方法被应用程序使用不被推荐。要求有效的直接的点对点的应用程序应当使用UDP。
--------------------------------------------------------------------------------
P2P之UDP穿透NAT的原理与实现（附源代码）
作者：shootingstars (有容乃大，无欲则刚) 日期：2004-5-25
出处：P2P中国(PPcn.net)
P2P 之 UDP穿透NAT的原理与实现（附源代码）
原创：shootingstars
参考：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
论坛上经常有对P2P原理的讨论，但是讨论归讨论，很少有实质的东西产生（源代码）。呵呵，在这里我就用自己实现的一个源代码来说明UDP穿越NAT的原理。
首先先介绍一些基本概念：
NAT(Network Address Translators)，网络地址转换：网络地址转换是在IP地址日益缺乏的情况下产生的，它的主要目的就是为了能够地址重用。NAT分为两大类，基本的NAT和NAPT(Network Address/Port Translator)。
最开始NAT是运行在路由器上的一个功能模块。
最先提出的是基本的NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。
因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的 IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP 包中的原IP地址，但是不会改变IP包中的端口)
关于基本的NAT可以参看RFC 1631
另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的 TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT才是我们真正讨论的主角。看下图：
Server S1
18.181.0.31:1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 155.99.25.11:62000 v |
|
NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
有一个私有网络10.*.*.*，Client A是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如 10.0.0.10)。如果Client A中的某个进程（这个进程创建了一个UDP Socket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？
首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000 ->18.181.0.31:1235）。
一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从18.181.0.31发送到 62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000端口的数据会被转发，其他的 IP发送到这个端口的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。
呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。
看看下面的情况：
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？
这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是 NAT再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT，后一种叫做Cone NAT。我们期望我们的NAT是第二种，呵呵，如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（可以庆幸的是，现在绝大多数的NAT属于后者，即Cone NAT）
好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。
但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。
那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个 Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP Hole Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。
呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。
现在我们来看看一个P2P软件的流程，以下图为例：
Server S （219.237.60.1）
|
|
+----------------------+----------------------+
| |
NAT A (外网IP:202.187.45.3) NAT B (外网IP:187.34.1.56)
| (内网IP:192.168.0.1) | (内网IP:192.168.0.1)
| |
Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)
首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，Client B登录Server S，NAT B给此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
此时，Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B，那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000，是不是Client A向这个地址发送信息Client B就能收到了呢？答案是不行，因为如果这样发送信息，NAT B会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。现在我们需要的是在NAT B上打一个方向为202.187.45.3（即Client A的外网地址）的洞，那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢，呵呵，当然是Server S。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
扫一扫
1529
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
