1、【转】 P2P 之 UDP穿透 NAT的原理与实现(附源代码)2011-02-24 09:58转载自 最终编辑 日期：2009-01-31 来源：csdn 作者：shootingstarsP2P 之 UDP 穿透NAT 的原理与实现（附源代码）原创：shootingstars参考：论坛上经常有对 P2P原理的讨论，但是讨论归讨论，很少有实质的东西产生（源代码）。呵呵，在这里我就用自己实现的一个源代码来说明 UDP穿越 NAT的原理。首先先介绍一些基本概念：NAT(Network Address Translators)，网络地址转换：网络地址转换是在 IP地址日益缺乏的情况下产生的，它的主要目
2、的就是为了能够地址重用。NAT 分为两大类，基本的 NAT和 NAPT(Network Address/Port Translator)。最开始 NAT是运行在路由器上的一个功能模块。最先提出的是基本的 NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪 90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的 IP地址，其他的节点的 IP地址应该是可以重用的。因此，基本的 NAT实现的功能很简单，在子网内使用一个保留的 IP子网段，这些 IP对外是不可见的。子网内只有少数一些 IP地址可以对应到真正全球唯一的IP 地址。如果
3、这些节点需要访问外部网络，那么基本 NAT就负责将这个节点的子网内 IP转化为一个全球唯一的 IP然后发送出去。(基本的 NAT会改变IP包中的原IP 地址，但是不会改变 IP包中的端口)关于基本的NAT 可以参看 RFC 1631另外一种 NAT叫做 NAPT，从名称上我们也可以看得出，NAPT 不但会改变经过这个 NAT设备的 IP数据报的IP 地址，还会改变 IP数据报的TCP/UDP 端口。基本 NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT 才是我们真正讨论的主角。看下图：有一个私有网络 10.*.*.*，Client A 是其中的一台计算机，这个网络的网关（一个 NA
4、T设备）的外网 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的这个端口
5、的第一个 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
6、.181.0.31发送到62000端口的数据会被转发，其他的 IP发送到这个端口的数据将被 NAT抛弃）这样 Client A就与 Server S1建立以了一个连接。呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。看看下面的情况：接上面的例子，如果 Client A的原来那个 Socket(绑定了 1234端口的那个 UDP Socket)又接着向另外一个 Server S2发送了一个 UDP包，那么这个 UDP包在通过 NAT时会怎么样呢？这时可能会有两种情况发生，一种是 NAT再次创建一个 Session，并且再次为这个 Session分配一个端口号（比如：62001）。
7、另外一种是NAT 再次创建一个 Session，但是不会新分配一个端口号，而是用原来分配的端口号 62000。前一种 NAT叫做 Symmetric NAT，后一种叫做Cone NAT。我们期望我们的 NAT是第二种，呵呵，如果你的 NAT刚好是第一种，那么很可能会有很多 P2P软件失灵。（可以庆幸的是，现在绝大多数的 NAT属于后者，即 Cone NAT）好了，我们看到，通过 NAT,子网内的计算机向外连结是很容易的（NAT 相当于透明的，子网内的和外网的计算机不用知道NAT 的情况）。但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是 P2P所需要的）。那么我们如果想从外部发送
8、一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的 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 不能利用这个洞）。呵
9、呵，现在该轮到我们的正题P2P 了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。现在我们来看看一个 P2P软件的流程，以下图为例：首先，Client A 登录服务器，NAT A 为这次的Session 分配了一个端口 60000，那么 Server S收到的 Client A的地址是202.187.45.3:60000，这就是 Client A的外网地址了。同样，Client B 登录 Server S，NAT B 给此次 Session
10、分配的端口是 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.18
11、7.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通信
12、了。注意：以上过程只适合于 Cone NAT的情况，如果是 Symmetric NAT，那么当 Client B向 Client A打洞的端口已经重新分配了，Client B 将无法知道这个端口（如果 Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。下面是一个模拟 P2P聊天的过程的源代码，过程很简单，P2PServer 运行在一个拥有公网 IP的计算机上，P2PClient 运行在两个不同的 NAT后（注意，如果两个客户端运行在一个 NAT后，本程序很可能不能运行正常，这取决于你的 NAT是否支持
13、loopback translation，详见，当然，此问题可以通过双方先尝试连接对方的内网 IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过 send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。程序现在支持三个命令：send , getu , exitsend格式：send username message功能：发送信息给usernamegetu格式：getu功能：获得当前服务器用户列表exit格式：exit功能：注销与服务器的连接（服务器不会自动监测客户是
14、否吊线）代码很短，相信很容易懂，如果有什么问题，可以给我发邮件 或者在 CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权 8-）。最后感谢 CSDN网友 PiggyXP 和 Seilfer 的测试帮助工程下载地址:-基于 UDP的 P2P问题拾遗UDP协议包经 NAPT透明传输的说明:NAPT为每一个 Session分配一个 NAPT自己的端口号，依据此端口号来判断将收到的公网IP 主机返回的 TCP/IP数据包转发给那台内网 IP地址的计算机。在这里 Session是虚拟的，UDP 通讯并不需要建立连接，但是对于 NAPT而言，的确要有一个 Session的概念存在。NAPT 对
15、于 UDP协议包的透明传输面临的一个重要的问题就是如何处理这个虚拟的 Session。我们都知道TCP 连接的 Session以SYN包开始，以 FIN包结束，NAPT 可以很容易的获取到 TCP Session的生命周期，并进行处理。但是对于 UDP而言，就麻烦了，NAPT 并不知道转发出去的 UDP协议包是否到达了目的主机，也没有办法知道。而且鉴于 UDP协议的特点，可靠很差，因此 NAPT必须强制维持 Session的存在，以便等待将外部送回来的数据并转发给曾经发起请求的内网 IP地址的计算机。NAPT 具体如何处理UDP Session的超时呢？不同的厂商提供的设备对于 NAPT的实现
16、不近相同，也许几分钟，也许几个小时，些 NAPT的实现还会根据设备的忙碌状态进行智能计算超时时间的长短。现在来看一下 NAPT是依据什么策略来判断是否要为一个请求发出的 UDP数据包建立 Session的主要有一下几个策略:A. 源地址(内网 IP地址)不同，忽略其它因素, 在 NAPT上肯定对应不同的 SessionB. 源地址(内网 IP地址)相同，源端口不同，忽略其它的因素，则在 NAPT上也肯定对应不同的SessionC. 源地址(内网 IP地址)相同，源端口相同，目的地址(公网 IP地址)相同，目的端口不同，则在 NAPT上肯定对应同一个 SessionD. 源地址(内网 IP地址)
17、相同，源端口相同，目的地址(公网 IP地址)不同，忽略目的端口，则在 NAPT上是如何处理 Session的呢？D的情况正式我们关心和要讨论的问题。依据目的地址(公网 IP地址)对于 Session的建立的决定方式我们将NAPT 设备划分为两大类:Symmetric NAPT:对于到同一个 IP地址，任意端口的连接分配使用同一个 Session; 对于到不同的 IP地址, 任意端口的连接使用不同的 Session. 我们称此种NAPT 为 Symmetric NAPT. 也就是只要本地绑定的UDP 端口相同， 发出的目的IP 地址不同，则会建立不同的 Session.Cone NAPT:对于到
18、同一个 IP地址，任意端口的连接分配使用同一个 Session; 对于到不同的 IP地址，任意端口的连接也使用同一个 Session.我们称此种NAPT 为 Cone NAPT. 也就是只要本地绑定的UDP 端口相同， 发出的目的地址不管是否相同， 都使用同一个 Session.客户端都处于相同的 NAT之后我们假设，Client A 和 Client B 要使用上一节我们所描述的 “UDP 打洞技术”，并通过服务器 S这个“媒人”来认识，这样 Client A 和 Client B首先从服务端 S得到了彼此的公网 IP地址和端口，然后就往对方的公网 IP地址和端口上发送消息。在这种情况下，如
19、果 NAT 仅仅允许在 内部网主机与其他内部网主机（处于同一个NAT 之后的网络主机）之间打开 UDP会话通信通道，而内部网主机与其他外部网主机就不允许的话，那么 Client A 和 Client B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”)，因为数据包首先从局域网的私有 IP发送到 NAT转换，然后“绕一圈”，再回到局域网中来，但是这样总比这些数据通过公网传送好。举例来说，当 Client A 发送了一个 UDP数据包到 Client B 的公网 IP地址，这个数据包的报头中就会有一个源地址 10.0.0.1:124和一个目标地址155.9
20、9.25.11:62001。NAT 接收到这个包以后，就会(进行地址转换)解析出这个包中有一个公网地址源地址 155.99.25.11:62000和一个目标地址 10.1.1.3:1234，然后再发送给 B，虽说 NAT支持“loopback translation”，我们也发现，在这种情形下,这个解析和发送的过程有些多余，并且这个 Client A 和 Client B 之间的对话可能潜在性地给 NAT增加了负担。UDP打洞技术有很多实用的地方：第一，一旦这种处于 NAT之后的端对端的直连建立之后，连接的双方可以轮流担任 对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器 S
21、的工作量；第二，应用程序不用关心这个NAT 是属于 cone还是 symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT 之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重 NAT之后，不论连接的双方经过多少层 NAT才到达 Internet，都可以进行通信。UPD端口号预言明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和 31001） 恰好已经被一个不相关的会话所使用，那么 NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个 NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。如果隐
22、藏在NAT A 后的一个不同的客户端 X（或者在 NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在 客户端 A 建立了与服务器 S 的连接之后，客户端 A 与 客户端 B 建立连接之前；那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个 NAT方包含以上碰到的问题，这个方法都不会奏效。自从使用这种方法来实践 P2P的应用程序以来,在处于 cone NAT 系列的网络环境中这个方法还是实用的；如果有一方为 cone NAT 而另外一方为 symmetric NAT，那么应用程
23、序就应该预先发现另外一方的 NAT 是什么类型，再做出正确的行为来处理通信，这样就增大了算法的复杂度，并且降低了在真实网络环境中的普适性。最后，如果 P2P的一方处在两级或者两级以上的 NAT下面，并且这些 NATs 接近这个客户端是 symmetric 的话，端口号预言 是无效的！保持端口绑定在使用“UDP 打洞技术”时有一点必须要注意：它只能在双方的 NAT都是 cone NAT（或者干脆没有 NAT）时才能正常工作；这些 NAT在自己的公网 UDP端口被使用时保持着端口的绑定私有 IP，私有 UDP端口对和公网 IP，公网 UDP端口对的一一对应。如果像 symmetricNAT 那样给
24、每个新的会话都分配一个新的公网端口，那么 UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信转换。伴随着 cone NAT 的推广，“UDP 打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP 打洞技术”。（注：因为我国的国情，网络技术应用得比较晚，所以可以说绝大部分的网络都是 cone NAT，所以 UDP 打洞技术基本上可以畅通无阻的使用，只是还要注意对 NAT是否支持“loopback translation”的测试）利用“同时开放 TCP连接”建立基于 TCP的 P2PSim
25、ultaneous TCP open 同时开放 TCP连接这里有一种方法能够在某种情况下建立一个穿透 NAT的端对端 TCP直连。我们知道，绝大多数的TCP 会话的建立，都是通过一端先发送一个 SYN包开始，另一方则回发一个 SYN-ACK包的过程。然而，这里确实存在另外一种情况，就是 P2P的双方各自同时地发出一个 SYN包到对方的公网地址上，然后各自都单独地返回一个 ACK响应来建立一个 TCP会话，这个过程被称之为：“Simultaneous open”（“同时开放连接”）。如果一个 NAT接收到一个来自私有网络外面的 TCP SYN 包，这个包想发起一个“引入”的 TCP 连接，一般来
26、说，NAT 会拒绝这个连接请求并扔掉这个 SYN 包，或者回送一个 TCP RST（connection reset，重建连接）包给请求方。但是，有一种情况，当这个接收到的 SYN 包 中的源 IP地址和端口、目标 IP地址和端口都与 NAT登记的一个已经激活的 TCP会话中的地址信息相符时，NAT 将会放行这个 SYN 包，让它进入 NAT内部。特别要指出，如果 NAT恰好看到一个刚刚发送出去的一个SYN 包也和上面接收到的 SYN包中的地址信息相符合的话，那么 NAT将会认为这个 TCP连接已经被激活，并将允许这个方向的 SYN包进入NAT内部。如果 Client A 和 Client B
27、 能够彼此正确的预知对方的 NAT将会给下一个 TCP连接分配的公网 TCP端口，并且两个客户端能够同时地发起一个“外出”的 TCP连接，并在对方的 SYN 包到达之前，自己刚发送出去的 SYN包都能顺利的穿过自己的 NAT的话，一条端对端的 TCP连接就成功地建立了。不幸的是，这个诡计比3.4 节所讲的UDP 端口预言更容易被粉碎，并且对时间的敏感性的依赖更多！首先，除非双方的NAT 都是Simple firewalls 或者都像 cone NAT那样处理 TCP通信，否则两个客户端还是无法建立这个TCP 直连，因为它们无法预知对方的 NAT会分配给新的会话的端口号是多少。 另外，如果双方的
28、 SYN 到达对方的NAT 速度太快（举例来说，就是 SYN A的还未穿过 NAT A时，SYN B已经提早到达了 NAT A），对方的 NAT会将这个SYN 扔掉，并返回一个 RST 包，这样就使得这个发快了的一方 NAT关闭原来的会话，又重新建立一个新的会话，再利用这个新的会话重发一个 SYN，这时端口预言就失效了，因为再次分配到相同的端口地址的几率太小了。最后，尽管在“TCP 规范”中说明了“Simultaneous open”是一种支持的标准技术，但是在一些公共操作系统中，对这种技术的支持并不好。基于这个原因，我们也在这里郑重申明，并不推荐使用这个技术。如果您的应用程序想要穿透 NAT
29、并进行高效率高性能的P2P 的通信，应该使用 UDP技术！过程详细描述：Client A发送一个TCP SYN 包给 Client B，我们把这个SYN 包叫做 SYN A,包含的信息如下：SrcAddress：10.0.0.1 Tcp port ：1234 DestAddress：138.76.29.7 Tcp port：31000 0同时，Client B 发送一个TCP SYN 包给Client A，我们把这个包叫做 SYN B,包含的信息如下：SrcAddress：10.1.1.3 Tcp port ：1234DestAddress：155.99.25.11 Tcp port：6200
30、0 0SYN A首先通过NAT A（必须在 SYN B到达 NAT A之前），NAT A 看到这个包并将其地址信息进行转换为：SrcAddress：155.99.25.11 Tcp port ：62000 0DestAddress：138.76.29.7 Tcp port：31000 0我们把这个经过 NAT A 转换的包叫做 SYN A同样，SYN B 首先通过NAT B（也必须在 SYN A到达 NAT B之前），NAT B 看到这个包并进行地址转换为：SrcAddress：138.76.29.7 Tcp port：31000 0DestAddress：155.99.25.11 Tcp p
31、ort ：62000 0我们把这个经过 NAT B转换的包叫做 SYN B这时，NAT A 和 NAT B都在自己的 TCP连接表中存储了含有上面两个公网 IP地址和端口信息，因此，只要看到包含这两个信息的 SYN包，都会让其通过。就在这个瞬间，SYN A到达了 NAT B，NAT B 检查了一下 SYN A，发现它的地址信息和自己 TCP连接表中的信息相符，便让 SYN A通过了，并将 SYN A的地址信息转换为：我们称这个包为 SYN ASrcAddress：155.99.25.11 Tcp port ：62000 0DestAddress：10.1.1.3 Tcp port：1234 以
32、使这个包能够到达内部网中 Client B上 也就在这个瞬间，SYN B到达了 NAT A，NAT A 检查了一下 SYN B，发现它的地址信息和自己 TCP连接表中的信息相符，便让 SYN B通过了，并将 SYN B的地址信息转换为：我们称这个包为 SYN BSrcAddress：138.76.29.7 Tcp port ：31000 0DestAddress：10.0.0.1 Tcp port：1234 以使这个包能够到达内部网中 Client A上这时，Client A 收到了 SYN B，Client B 收到了 SYN A，并返回给对方 ACK，经过三次握手，这个 P2P的 TCP连
33、接就建立了。下面解释一下上面的文章中没有提及或者说我觉得比较欠缺的地方. 私有地址/端口和公有地址/端口:我们知道,现在大部分网络采用的都是 NAPT(Network Address/Port Translator)了,这个东东的作用是一个对外的对话在经过NAT之后 IP地址和端口号都会被改写,在这里把一次会话中客户自己认为在使用的 IP地址和端口号成为私有地址/端口,而把经过 NAPT之后被改写的 IP地址和端口号称为公有地址/端口.或者可以这么理解,私有地址/端口是你家里人对你的昵称而公有地址/端口则是你真正对外公开的名字.如何获得用户的私用地址/端口号,这个很简单了,而要得到公有地址/端
34、口号就要在连接上另一台机器之后由那台机器看到的 IP地址和端口号来表示. 如果明白了上面的东西,下面进入我们的代码,在这里解释一下关键部分的实现: 客户端首先得到自己的私有地址/终端,然后向 server端发送登陆请求,server端在得到这个请求之后就可以知道这个 client端的公有地址/终端,server 会为每一个登陆的 client保存它们的私有地址/端口和公有地址/端口. OK,下面开始关键的打洞流程.假设 client A要向 client B对话,但是 A不知道B的地址,即使知道根据 NAT的原理这个对话在第一次会被拒绝,因为 client B的 NAT认为这是一个从没有过的外
35、部发来的请求.这个时候,A 如果发现自己没有保存 B的地址,或者说发送给 B的会话请求失败了,它会要求 server端让 B向 A打一个洞,这个 B-A的会话意义在于它使NAT B 认为 A的地址/端口是可以通过的地址/端口,这样 A再向B 发送对话的时候就不会再被 NAT B拒绝了.打一个比方来说明打洞的过程,A 想来 B家做客,但是遭到了B 的管家 NAT B的拒绝,理由是:我从来没有听我家 B提过你的名字,这时 A找到了 A,B都认识的朋友 server,要求 server给 B报一个信,让 B去跟管家说 A是我的朋友,于是,B 跟管家 NAT B说,A 是我认识的朋友,这样 A的访问请
36、求就不会再被管家NAT B 所拒绝了.简而言之,UDP 打洞就是一个通过 server保存下来的地址使得彼此之间能够直接通信的过程,server 只管帮助建立连接,在建立间接之后就不再介入了. 好了,原理性的东西解释到这里,附件中有一个完整的 P2P演示程序,命令行模式下,包括 server端和client 端,在运行的时候首先启动server 端,然后打开几个client端分别登陆,之后彼此之间就可以相互通信了.程序在本机上测试通过,也就是测试的环境 server和client 都是一台机器,还没有在不同的机器上测试过,不知道会不会有问题:) 下载地址: http:/ 参考资料: 1)P2P
37、 之 UDP 穿透NAT 的原理与实现（附源代码）-http:/ 2)王艳平 附: 又被人翻出这个东西来了. 我得说,这不是一个成熟的东西,据我的了解,商业上的做法也不是这么做的,所以,同学一笑而过吧,别把这个玩具当回事,我自己看着都觉得惭愧. NAPT(The IP Network Address/Port Translator) 为何阻碍了 P2P软件 的应用? 通过 NAPT 上网的特点 决定了只能 由 NAPT内的计算机 主动向 NAPT外部的 主机发起连 接，外部的主机 想直接和 NAPT内的 计算机直接 建立连接是 不被允许的 。 IM(即时通讯 )而言，这意味着由 于 NAPT内的计算机 和 NAPT外的计算机 只能通过服务器中转数 据来进行通 讯。对于 P2P方式的下载 程序而言，意味着 NAPT内的计算机不能接 收到 NAPT外部的连 接，导致连接数 用过少，下载速度很 难上去。因此 P2P软件必须要 解决的一个 问题就是要 能够在一定 的程度上解 决 NAPT内的计算机 不能被外部 连接的问题 。
