上次发完贴子后，有很多网友给出了很好的意见，可惜的是，贴子丢失了，我没能记住他们的名字，在这里向这些网友表示感谢。
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软件失灵。（特别是如果双方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT，这种情况下，建立p2p的连接将会比较困难。关于Restricted Cone NAT，请参看http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt）
49 个解决方案
#1
好了，我们看到，通过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就能收到了。既然Client A不能够通知Client B来打这个洞，那么我们只能通过服务器来转发这个命令了。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
这是一个Client A与Client B建立p2p连结的大概的流程：
Client A->Server S (Client A向Server S发送一个请求，请求信息是希望Client B向Client A方向打洞)
Server S->Client B (S要求B向A打洞)
Client B->Client A (打洞消息，这个消息Client A很可能不会收到，但是收不到没有关系，NAT B上的洞已经打好了)
Client A->Client B (发送正真的消息)
注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback translation，详见http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
程序现在支持三个命令：send , getu , exit
send格式：send username message
功能：发送信息给username
getu格式：getu
功能：获得当前服务器用户列表
exit格式：exit
功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）
代码很短，相信很容易懂，如果有什么问题，可以给我发邮件zhouhuis22@sina.com 或者在CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权8-）。
最后感谢CSDN网友 PiggyXP 和 Seilfer的测试帮助
源代码可以到http://www.ppcn.net/show.aspx?id=1306&cid=2下载。(页面下方有下载链接)
但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是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就能收到了。既然Client A不能够通知Client B来打这个洞，那么我们只能通过服务器来转发这个命令了。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
这是一个Client A与Client B建立p2p连结的大概的流程：
Client A->Server S (Client A向Server S发送一个请求，请求信息是希望Client B向Client A方向打洞)
Server S->Client B (S要求B向A打洞)
Client B->Client A (打洞消息，这个消息Client A很可能不会收到，但是收不到没有关系，NAT B上的洞已经打好了)
Client A->Client B (发送正真的消息)
注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback translation，详见http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
程序现在支持三个命令：send , getu , exit
send格式：send username message
功能：发送信息给username
getu格式：getu
功能：获得当前服务器用户列表
exit格式：exit
功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）
代码很短，相信很容易懂，如果有什么问题，可以给我发邮件zhouhuis22@sina.com 或者在CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权8-）。
最后感谢CSDN网友 PiggyXP 和 Seilfer的测试帮助
源代码可以到http://www.ppcn.net/show.aspx?id=1306&cid=2下载。(页面下方有下载链接)
#2
后记：
1 关于穿透Symmetric NAT，对于双方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT的情况，建立p2p的连接将非常困难。现在我知道的只有端口预测这一种办法，即猜测下一次Symmetric NAT会分配什么端口。这个中间涉及到很多问题，我希望下一次有机会能够谈一谈。
2 关于建立起TCP的p2p连接，这个情况比1更复杂，所以。。。我暂时不知道如何做到这一点。
另：我接触p2p的时间很短，也没有实际产品的开发经验，文中有什么问题和错误希望广大网友能够指出。
1 关于穿透Symmetric NAT，对于双方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT的情况，建立p2p的连接将非常困难。现在我知道的只有端口预测这一种办法，即猜测下一次Symmetric NAT会分配什么端口。这个中间涉及到很多问题，我希望下一次有机会能够谈一谈。
2 关于建立起TCP的p2p连接，这个情况比1更复杂，所以。。。我暂时不知道如何做到这一点。
另：我接触p2p的时间很短，也没有实际产品的开发经验，文中有什么问题和错误希望广大网友能够指出。
#3
嗯，太好了，呵呵
这个帖子是网络版的财富，很有重贴的必要^_^
这个帖子是网络版的财富，很有重贴的必要^_^
#4
对了，此文附带源码的下载地址为
http://iunknown.com.cn/csdn/network/P2P_by_shootingstars.rar
非常感谢 _foo 朋友免费提供的空间，非常感谢！！
http://iunknown.com.cn/csdn/network/P2P_by_shootingstars.rar
非常感谢 _foo 朋友免费提供的空间，非常感谢！！
#5
好文！感谢楼主和版主。
#6
这篇文章封版以前发过，现在再发出来，很好啊！
#7
支持支持,肉頂肉頂
#8
不過源碼好象沒辦法下載了
#9
好文章
我实现了Cone NAT的情况，如果是Symmetric NAT我就通过服务器中转了,不过这样效果不是很好,请大家讨论一下如何实现Symmetric NAT情况下的P2P
我实现了Cone NAT的情况，如果是Symmetric NAT我就通过服务器中转了,不过这样效果不是很好,请大家讨论一下如何实现Symmetric NAT情况下的P2P
#10
的确不错，非常棒！我想问一下！这个所谓的洞能持续多长时间啊？
比如说！这次我发信息借助服务器双方都打好了互相通讯的洞！那么这个洞会不会持久保持下去啊？还是隔一个很短的时间就被取消了啊？
比如说！这次我发信息借助服务器双方都打好了互相通讯的洞！那么这个洞会不会持久保持下去啊？还是隔一个很短的时间就被取消了啊？
#11
To liuzhijun(云)
我也不确切知道NAT上的每一个Session在没有数据传输的时候会自动持续多长时间。不过我想这个时间应该与NAT的具体实现有关。
QQ大概每分钟联系服务器一次，我想这应该是个推荐值吧。^_^
我也不确切知道NAT上的每一个Session在没有数据传输的时候会自动持续多长时间。不过我想这个时间应该与NAT的具体实现有关。
QQ大概每分钟联系服务器一次，我想这应该是个推荐值吧。^_^
#12
我用90秒向服务器发一次心跳包
#13
也就是说每隔大概一分钟或者90秒就通知服务器，让服务器通知其他客户端打洞吗？
请说得具体点吧！我是刚接触这个！有些术语不太明白！
请说得具体点吧！我是刚接触这个！有些术语不太明白！
#14
但是如果这样的话！那岂不是服务器的负载会很大！QQ会这样吗！到不如直接通过服务器转发信息来得方便？
#15
请教楼主,如果tcp的话,是否就不必如此?
另,大家知道UPnP是个什么东东吗?
另,大家知道UPnP是个什么东东吗?
#16
liuzhijun(云)
如果平均每秒有10000个人发送心跳信息，假设每个心跳包10个字节，那么服务器接收的数据是100KByte，呵呵，这个数据量并不是很大。（而且每个客户是一分钟才发送一次心跳，那么我想如果全部客户都是p2p的话，随便一个服务器带100000个客户没有问题，当然，这是理想情况）
如果全部信息都从服务器中转的话，那么数据量将远远不止这个数。加上如果需要传输语音，视频或者文件的话，服务器将不可能承受这么大的压力。
To WSAConnect(出来闹总有一天是要还的)(对不起,我是上帝)
在两个内网之间建立Tcp连接将是非常困难的，我现在还不知道有什么好的办法在两个内网之间建立tcp连接。
upnp。。。我也不是太清楚。。。
如果平均每秒有10000个人发送心跳信息，假设每个心跳包10个字节，那么服务器接收的数据是100KByte，呵呵，这个数据量并不是很大。（而且每个客户是一分钟才发送一次心跳，那么我想如果全部客户都是p2p的话，随便一个服务器带100000个客户没有问题，当然，这是理想情况）
如果全部信息都从服务器中转的话，那么数据量将远远不止这个数。加上如果需要传输语音，视频或者文件的话，服务器将不可能承受这么大的压力。
To WSAConnect(出来闹总有一天是要还的)(对不起,我是上帝)
在两个内网之间建立Tcp连接将是非常困难的，我现在还不知道有什么好的办法在两个内网之间建立tcp连接。
upnp。。。我也不是太清楚。。。
#17
好，留底先
#18
shootingstars(有容乃大，无欲则刚) 说得真好啊！很对！
上面的这个文章的代码 你有实验过吗！我好象实验了不行啊！有时只能单边发！
有时单边都发不通！
上面的这个文章的代码 你有实验过吗！我好象实验了不行啊！有时只能单边发！
有时单边都发不通！
#19
upnp的情况请看msdn
windows messager 就是采用的这种技术
windows messager 就是采用的这种技术
#20
to liuzhijun(云)
这个代码只是试验性质的，所以只能应用于双方都是Cone Nat的网络。关于你的Nat是什么类型的，你可以到：
http://sourceforge.net/projects/stun/
下载一个工具，这个工具实现了stun(Simple Traversal of UDP through NATs-- RFC 3489）协议，可以判断你的NAT的类型。
这个代码只是试验性质的，所以只能应用于双方都是Cone Nat的网络。关于你的Nat是什么类型的，你可以到：
http://sourceforge.net/projects/stun/
下载一个工具，这个工具实现了stun(Simple Traversal of UDP through NATs-- RFC 3489）协议，可以判断你的NAT的类型。
#21
shootingstars(有容乃大，无欲则刚)
那QQ怎么能够任何网络都通讯啊？
它是不是要临时判断网络然后选择是直发还是服务器转发？
还有那个工具它有3个，我要下载哪个啊？
那QQ怎么能够任何网络都通讯啊？
它是不是要临时判断网络然后选择是直发还是服务器转发？
还有那个工具它有3个，我要下载哪个啊？
#22
shootingstars(有容乃大，无欲则刚)
我的机器测试结果是：
----------------------------------
No NAT detected - VoIP should work
Preserves port number
Supports hairpin of media
Public IP address: 219.129.11.30
----------------------------------
请问是什么意思啊？
#23
还想请问一下！
好象我一直没有搞清楚这个心跳包的问题！
是不是相当于要隔一段时间就要从客户到服务器发个信息来维持客户的这个端口，以便服务器能够随时向这个客户发送信息？
如果是这样，可不可以每隔一段时间向所有这个客户的好友（其他用户）包括服务器发送心跳信息，这样会不会稍微好些！如果只是想服务器发送心跳包，那么如果要和客户通讯的时候一样需要服务器发送打洞信息，对方客户一样会发送打洞信息，这样就会发送两次。
请大家都来讨论讨论吧！
好象我一直没有搞清楚这个心跳包的问题！
是不是相当于要隔一段时间就要从客户到服务器发个信息来维持客户的这个端口，以便服务器能够随时向这个客户发送信息？
如果是这样，可不可以每隔一段时间向所有这个客户的好友（其他用户）包括服务器发送心跳信息，这样会不会稍微好些！如果只是想服务器发送心跳包，那么如果要和客户通讯的时候一样需要服务器发送打洞信息，对方客户一样会发送打洞信息，这样就会发送两次。
请大家都来讨论讨论吧！
#24
to liuzhijun(云):
说明你的IP是公网IP，没有经过NAT的转换。任何其他的IP向你发送信息都是没有问题的。
如果是你向其他的用户发送信息，需要对方或者是在Cone Nat后，或者是公网IP。（这个限制其实是由于我的程序不完善造成的，其实如果有一方如果是公网ip的话，双方的通信应该就很简单了）
关于你的第二个问题，我在原来的贴子中讨论过：如果是像QQ这样的聊天程序，没有必要维持与每一个客户的连接，因为：
一：你的QQ好友可能很多，而你可能一天内都不会与任何一个好友聊天，而同时维持这么多的连接是没有必要的。
二：你与一个好友聊天，很可能在短时间内你会再次发送信息，其实你自己已经在维持这个Session的有效性了。
三：即使你与另外一个客户的Session因为时间关系已经失效了，那么重新建立一个p2p连接的开销也并非那么大。（服务器需要转发一个命令而已）
说明你的IP是公网IP，没有经过NAT的转换。任何其他的IP向你发送信息都是没有问题的。
如果是你向其他的用户发送信息，需要对方或者是在Cone Nat后，或者是公网IP。（这个限制其实是由于我的程序不完善造成的，其实如果有一方如果是公网ip的话，双方的通信应该就很简单了）
关于你的第二个问题，我在原来的贴子中讨论过：如果是像QQ这样的聊天程序，没有必要维持与每一个客户的连接，因为：
一：你的QQ好友可能很多，而你可能一天内都不会与任何一个好友聊天，而同时维持这么多的连接是没有必要的。
二：你与一个好友聊天，很可能在短时间内你会再次发送信息，其实你自己已经在维持这个Session的有效性了。
三：即使你与另外一个客户的Session因为时间关系已经失效了，那么重新建立一个p2p连接的开销也并非那么大。（服务器需要转发一个命令而已）
#25
mark
#26
to shootingstars(有容乃大，无欲则刚)
那我如果在每个客户（某个NAT内部）和服务器之间维持一个TCP连接，这样就因该不用发送心跳包了吧！如果一个客户发信给另外一个客户，如果不成功就用这个和服务器的TCP直连通知服务器，那这样我的这个TCP端口会不会和我发送给其他客户的UDP端口（发送信息的UDP端口）重复啊？
还有一个问题：
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口和以前这个还是一样的吗？
那我如果在每个客户（某个NAT内部）和服务器之间维持一个TCP连接，这样就因该不用发送心跳包了吧！如果一个客户发信给另外一个客户，如果不成功就用这个和服务器的TCP直连通知服务器，那这样我的这个TCP端口会不会和我发送给其他客户的UDP端口（发送信息的UDP端口）重复啊？
还有一个问题：
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口和以前这个还是一样的吗？
#27
mark
#28
精华啊
#29
to liuzhijun(云)
我想TCP连接仍然存在需要发送心跳包的问题。（NAT仍然可能会因为超时切断这个连接）
TCP的端口与UDP的端口是没有关系的。我想如果使用TCP连接服务器，而使用UDP来连结其他的客户端，这种设计可能会更加复杂，并且我没有实践过。
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口不会一样。
我想TCP连接仍然存在需要发送心跳包的问题。（NAT仍然可能会因为超时切断这个连接）
TCP的端口与UDP的端口是没有关系的。我想如果使用TCP连接服务器，而使用UDP来连结其他的客户端，这种设计可能会更加复杂，并且我没有实践过。
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口不会一样。
#30
TCP的NAT我倒是用，UDP没有写过，不过都差不多的。
#31
学习~!
#32
致敬，另外推荐大家看看 eMule 的源码哦
#33
怎么解决!nat中外网想主动链接内网的机器?
#34
to shootingstars(有容乃大，无欲则刚)
哎！遇到问题了！我下载的代码不知为什么只能单边发送，就是后来的那个可以发送
另外一边不能发送啊，总是失败，你有没有看过这个的原代码啊？帮我看看好吗？
哎！遇到问题了！我下载的代码不知为什么只能单边发送，就是后来的那个可以发送
另外一边不能发送啊，总是失败，你有没有看过这个的原代码啊？帮我看看好吗？
#35
eMule上面有具体讲P2P吗？
#36
学习，顶
#37
大家有实验过这个代码的都来发发言吧！我好象测试了不行啊！只能一边！
#38
to liuzhijun(云)
你能说明一下双方的NAT的情况吗？（双方的NAT的类型）
你能说明一下双方的NAT的情况吗？（双方的NAT的类型）
#39
我们都是中国电信的用的是VDSL拨号上网！还好我们各个宿舍都有电脑，每个宿舍有一个号
都是一个小局域网！呵呵！所以才有机会可以实验！就是这样的吧！因该是CONE NAT吧！
都是一个小局域网！呵呵！所以才有机会可以实验！就是这样的吧！因该是CONE NAT吧！
#40
你们是使用的Win2000作为网关吗？
Win2000作为NAT是Symmetric NAT（STUN检测结果）。
还有，你们是使用同一个外网IP出去的吗？
注意：如果两个客户端处于同一个NAT后，将可能不能正常通讯。
Win2000作为NAT是Symmetric NAT（STUN检测结果）。
还有，你们是使用同一个外网IP出去的吗？
注意：如果两个客户端处于同一个NAT后，将可能不能正常通讯。
#41
这样的吗？Win2000是Symmetric NAT类型的吗？
我晕啊！那具体那些网络才是CONE NAT的网络呢？
我们用的是Win2000的共享上网，就是Win2000作为网关！
那如果是这样的话！其不是很多P2P都不能用了啊？
我晕啊！那具体那些网络才是CONE NAT的网络呢？
我们用的是Win2000的共享上网，就是Win2000作为网关！
那如果是这样的话！其不是很多P2P都不能用了啊？
#42
To liuzhijun(云)
呵呵，不过我也是用的Win2000 Pro做的网关，并且试验成功了。。。原因我也不知道为什么。。。（不知道STUN是如何判断的？）
再问一下:你们的测试双方是在一个NAT后吗？（Win2000肯定不支持loopback translation）
呵呵，不过我也是用的Win2000 Pro做的网关，并且试验成功了。。。原因我也不知道为什么。。。（不知道STUN是如何判断的？）
再问一下:你们的测试双方是在一个NAT后吗？（Win2000肯定不支持loopback translation）
#43
不是吧！你两边都发送成功了吗？是不是和防火墙有关系啊！
你在程序里面有改过东西吗？我测试双方都不是在一个NAT后面啊
我用了3个宿舍的局域网，1个局域网中的主机做服务器，另外两客户端在另外两个NAT里面！
你在程序里面有改过东西吗？我测试双方都不是在一个NAT后面啊
我用了3个宿舍的局域网，1个局域网中的主机做服务器，另外两客户端在另外两个NAT里面！
#44
还是只有一边行，我晕啊！救命啊！神啊！
shootingstars(有容乃大，无欲则刚) 大哥救命啊！
shootingstars(有容乃大，无欲则刚) 大哥救命啊！
#45
to 楼主：
问个问题，假设有下面的情况，只有2个客户端，没有服务器
+----------------------+----------------------+
| |
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)
clientA and clientB 都知道自己的外网IP,然后她们通过打电话（or By Email)告诉对方自己的外网IP,然后
(1)clientA发一个UDP包裹给NAT B (外网IP:187.34.1.56),这样就在Nat A上打了一个洞
(2)clientB发一个UDP包裹给NAT A(外网IP:202.187.45.3),这样就在Nat B上打了一个洞
两边都有洞了，现在ClientA and ClientB 是不是就能通信了？
问个问题，假设有下面的情况，只有2个客户端，没有服务器
+----------------------+----------------------+
| |
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)
clientA and clientB 都知道自己的外网IP,然后她们通过打电话（or By Email)告诉对方自己的外网IP,然后
(1)clientA发一个UDP包裹给NAT B (外网IP:187.34.1.56),这样就在Nat A上打了一个洞
(2)clientB发一个UDP包裹给NAT A(外网IP:202.187.45.3),这样就在Nat B上打了一个洞
两边都有洞了，现在ClientA and ClientB 是不是就能通信了？
#46
To AntingZ(夕惕若)(买了一杆▄︻┳═一)
此种情况下，你需要首先确定双方NAT的类型。你可以使用STUN协议来确定NAT的类型。
如果想用此种方法建立连接，必须双方都是Cone NAT，而且必须有一方不是Restricted Cone NAT。
此种情况下，你需要首先确定双方NAT的类型。你可以使用STUN协议来确定NAT的类型。
如果想用此种方法建立连接，必须双方都是Cone NAT，而且必须有一方不是Restricted Cone NAT。
#47
太经典的文章了，佩服！
#48
好东东啊
#49
怎么在列表里死活找不到这个帖子啊，我顶上去看看^_^
#1
好了，我们看到，通过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就能收到了。既然Client A不能够通知Client B来打这个洞，那么我们只能通过服务器来转发这个命令了。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
这是一个Client A与Client B建立p2p连结的大概的流程：
Client A->Server S (Client A向Server S发送一个请求，请求信息是希望Client B向Client A方向打洞)
Server S->Client B (S要求B向A打洞)
Client B->Client A (打洞消息，这个消息Client A很可能不会收到，但是收不到没有关系，NAT B上的洞已经打好了)
Client A->Client B (发送正真的消息)
注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback translation，详见http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
程序现在支持三个命令：send , getu , exit
send格式：send username message
功能：发送信息给username
getu格式：getu
功能：获得当前服务器用户列表
exit格式：exit
功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）
代码很短，相信很容易懂，如果有什么问题，可以给我发邮件zhouhuis22@sina.com 或者在CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权8-）。
最后感谢CSDN网友 PiggyXP 和 Seilfer的测试帮助
源代码可以到http://www.ppcn.net/show.aspx?id=1306&cid=2下载。(页面下方有下载链接)
但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是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就能收到了。既然Client A不能够通知Client B来打这个洞，那么我们只能通过服务器来转发这个命令了。
总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。
这是一个Client A与Client B建立p2p连结的大概的流程：
Client A->Server S (Client A向Server S发送一个请求，请求信息是希望Client B向Client A方向打洞)
Server S->Client B (S要求B向A打洞)
Client B->Client A (打洞消息，这个消息Client A很可能不会收到，但是收不到没有关系，NAT B上的洞已经打好了)
Client A->Client B (发送正真的消息)
注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。
下面是一个模拟P2P聊天的过程的源代码，过程很简单，P2PServer运行在一个拥有公网IP的计算机上，P2PClient运行在两个不同的NAT后（注意，如果两个客户端运行在一个NAT后，本程序很可能不能运行正常，这取决于你的NAT是否支持loopback translation，详见http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，当然，此问题可以通过双方先尝试连接对方的内网IP来解决，但是这个代码只是为了验证原理，并没有处理这些问题），后登录的计算机可以获得先登录计算机的用户名，后登录的计算机通过send username message的格式来发送消息。如果发送成功，说明你已取得了直接与对方连接的成功。
程序现在支持三个命令：send , getu , exit
send格式：send username message
功能：发送信息给username
getu格式：getu
功能：获得当前服务器用户列表
exit格式：exit
功能：注销与服务器的连接（服务器不会自动监测客户是否吊线）
代码很短，相信很容易懂，如果有什么问题，可以给我发邮件zhouhuis22@sina.com 或者在CSDN上发送短消息。同时，欢迎转发此文，但希望保留作者版权8-）。
最后感谢CSDN网友 PiggyXP 和 Seilfer的测试帮助
源代码可以到http://www.ppcn.net/show.aspx?id=1306&cid=2下载。(页面下方有下载链接)
#2
后记：
1 关于穿透Symmetric NAT，对于双方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT的情况，建立p2p的连接将非常困难。现在我知道的只有端口预测这一种办法，即猜测下一次Symmetric NAT会分配什么端口。这个中间涉及到很多问题，我希望下一次有机会能够谈一谈。
2 关于建立起TCP的p2p连接，这个情况比1更复杂，所以。。。我暂时不知道如何做到这一点。
另：我接触p2p的时间很短，也没有实际产品的开发经验，文中有什么问题和错误希望广大网友能够指出。
1 关于穿透Symmetric NAT，对于双方都是Symmetric NAT，或者一方是Symmetric NAT，另一方是Restricted Cone NAT的情况，建立p2p的连接将非常困难。现在我知道的只有端口预测这一种办法，即猜测下一次Symmetric NAT会分配什么端口。这个中间涉及到很多问题，我希望下一次有机会能够谈一谈。
2 关于建立起TCP的p2p连接，这个情况比1更复杂，所以。。。我暂时不知道如何做到这一点。
另：我接触p2p的时间很短，也没有实际产品的开发经验，文中有什么问题和错误希望广大网友能够指出。
#3
嗯，太好了，呵呵
这个帖子是网络版的财富，很有重贴的必要^_^
这个帖子是网络版的财富，很有重贴的必要^_^
#4
对了，此文附带源码的下载地址为
http://iunknown.com.cn/csdn/network/P2P_by_shootingstars.rar
非常感谢 _foo 朋友免费提供的空间，非常感谢！！
http://iunknown.com.cn/csdn/network/P2P_by_shootingstars.rar
非常感谢 _foo 朋友免费提供的空间，非常感谢！！
#5
好文！感谢楼主和版主。
#6
这篇文章封版以前发过，现在再发出来，很好啊！
#7
支持支持,肉頂肉頂
#8
不過源碼好象沒辦法下載了
#9
好文章
我实现了Cone NAT的情况，如果是Symmetric NAT我就通过服务器中转了,不过这样效果不是很好,请大家讨论一下如何实现Symmetric NAT情况下的P2P
我实现了Cone NAT的情况，如果是Symmetric NAT我就通过服务器中转了,不过这样效果不是很好,请大家讨论一下如何实现Symmetric NAT情况下的P2P
#10
的确不错，非常棒！我想问一下！这个所谓的洞能持续多长时间啊？
比如说！这次我发信息借助服务器双方都打好了互相通讯的洞！那么这个洞会不会持久保持下去啊？还是隔一个很短的时间就被取消了啊？
比如说！这次我发信息借助服务器双方都打好了互相通讯的洞！那么这个洞会不会持久保持下去啊？还是隔一个很短的时间就被取消了啊？
#11
To liuzhijun(云)
我也不确切知道NAT上的每一个Session在没有数据传输的时候会自动持续多长时间。不过我想这个时间应该与NAT的具体实现有关。
QQ大概每分钟联系服务器一次，我想这应该是个推荐值吧。^_^
我也不确切知道NAT上的每一个Session在没有数据传输的时候会自动持续多长时间。不过我想这个时间应该与NAT的具体实现有关。
QQ大概每分钟联系服务器一次，我想这应该是个推荐值吧。^_^
#12
我用90秒向服务器发一次心跳包
#13
也就是说每隔大概一分钟或者90秒就通知服务器，让服务器通知其他客户端打洞吗？
请说得具体点吧！我是刚接触这个！有些术语不太明白！
请说得具体点吧！我是刚接触这个！有些术语不太明白！
#14
但是如果这样的话！那岂不是服务器的负载会很大！QQ会这样吗！到不如直接通过服务器转发信息来得方便？
#15
请教楼主,如果tcp的话,是否就不必如此?
另,大家知道UPnP是个什么东东吗?
另,大家知道UPnP是个什么东东吗?
#16
liuzhijun(云)
如果平均每秒有10000个人发送心跳信息，假设每个心跳包10个字节，那么服务器接收的数据是100KByte，呵呵，这个数据量并不是很大。（而且每个客户是一分钟才发送一次心跳，那么我想如果全部客户都是p2p的话，随便一个服务器带100000个客户没有问题，当然，这是理想情况）
如果全部信息都从服务器中转的话，那么数据量将远远不止这个数。加上如果需要传输语音，视频或者文件的话，服务器将不可能承受这么大的压力。
To WSAConnect(出来闹总有一天是要还的)(对不起,我是上帝)
在两个内网之间建立Tcp连接将是非常困难的，我现在还不知道有什么好的办法在两个内网之间建立tcp连接。
upnp。。。我也不是太清楚。。。
如果平均每秒有10000个人发送心跳信息，假设每个心跳包10个字节，那么服务器接收的数据是100KByte，呵呵，这个数据量并不是很大。（而且每个客户是一分钟才发送一次心跳，那么我想如果全部客户都是p2p的话，随便一个服务器带100000个客户没有问题，当然，这是理想情况）
如果全部信息都从服务器中转的话，那么数据量将远远不止这个数。加上如果需要传输语音，视频或者文件的话，服务器将不可能承受这么大的压力。
To WSAConnect(出来闹总有一天是要还的)(对不起,我是上帝)
在两个内网之间建立Tcp连接将是非常困难的，我现在还不知道有什么好的办法在两个内网之间建立tcp连接。
upnp。。。我也不是太清楚。。。
#17
好，留底先
#18
shootingstars(有容乃大，无欲则刚) 说得真好啊！很对！
上面的这个文章的代码 你有实验过吗！我好象实验了不行啊！有时只能单边发！
有时单边都发不通！
上面的这个文章的代码 你有实验过吗！我好象实验了不行啊！有时只能单边发！
有时单边都发不通！
#19
upnp的情况请看msdn
windows messager 就是采用的这种技术
windows messager 就是采用的这种技术
#20
to liuzhijun(云)
这个代码只是试验性质的，所以只能应用于双方都是Cone Nat的网络。关于你的Nat是什么类型的，你可以到：
http://sourceforge.net/projects/stun/
下载一个工具，这个工具实现了stun(Simple Traversal of UDP through NATs-- RFC 3489）协议，可以判断你的NAT的类型。
这个代码只是试验性质的，所以只能应用于双方都是Cone Nat的网络。关于你的Nat是什么类型的，你可以到：
http://sourceforge.net/projects/stun/
下载一个工具，这个工具实现了stun(Simple Traversal of UDP through NATs-- RFC 3489）协议，可以判断你的NAT的类型。
#21
shootingstars(有容乃大，无欲则刚)
那QQ怎么能够任何网络都通讯啊？
它是不是要临时判断网络然后选择是直发还是服务器转发？
还有那个工具它有3个，我要下载哪个啊？
那QQ怎么能够任何网络都通讯啊？
它是不是要临时判断网络然后选择是直发还是服务器转发？
还有那个工具它有3个，我要下载哪个啊？
#22
shootingstars(有容乃大，无欲则刚)
我的机器测试结果是：
----------------------------------
No NAT detected - VoIP should work
Preserves port number
Supports hairpin of media
Public IP address: 219.129.11.30
----------------------------------
请问是什么意思啊？
#23
还想请问一下！
好象我一直没有搞清楚这个心跳包的问题！
是不是相当于要隔一段时间就要从客户到服务器发个信息来维持客户的这个端口，以便服务器能够随时向这个客户发送信息？
如果是这样，可不可以每隔一段时间向所有这个客户的好友（其他用户）包括服务器发送心跳信息，这样会不会稍微好些！如果只是想服务器发送心跳包，那么如果要和客户通讯的时候一样需要服务器发送打洞信息，对方客户一样会发送打洞信息，这样就会发送两次。
请大家都来讨论讨论吧！
好象我一直没有搞清楚这个心跳包的问题！
是不是相当于要隔一段时间就要从客户到服务器发个信息来维持客户的这个端口，以便服务器能够随时向这个客户发送信息？
如果是这样，可不可以每隔一段时间向所有这个客户的好友（其他用户）包括服务器发送心跳信息，这样会不会稍微好些！如果只是想服务器发送心跳包，那么如果要和客户通讯的时候一样需要服务器发送打洞信息，对方客户一样会发送打洞信息，这样就会发送两次。
请大家都来讨论讨论吧！
#24
to liuzhijun(云):
说明你的IP是公网IP，没有经过NAT的转换。任何其他的IP向你发送信息都是没有问题的。
如果是你向其他的用户发送信息，需要对方或者是在Cone Nat后，或者是公网IP。（这个限制其实是由于我的程序不完善造成的，其实如果有一方如果是公网ip的话，双方的通信应该就很简单了）
关于你的第二个问题，我在原来的贴子中讨论过：如果是像QQ这样的聊天程序，没有必要维持与每一个客户的连接，因为：
一：你的QQ好友可能很多，而你可能一天内都不会与任何一个好友聊天，而同时维持这么多的连接是没有必要的。
二：你与一个好友聊天，很可能在短时间内你会再次发送信息，其实你自己已经在维持这个Session的有效性了。
三：即使你与另外一个客户的Session因为时间关系已经失效了，那么重新建立一个p2p连接的开销也并非那么大。（服务器需要转发一个命令而已）
说明你的IP是公网IP，没有经过NAT的转换。任何其他的IP向你发送信息都是没有问题的。
如果是你向其他的用户发送信息，需要对方或者是在Cone Nat后，或者是公网IP。（这个限制其实是由于我的程序不完善造成的，其实如果有一方如果是公网ip的话，双方的通信应该就很简单了）
关于你的第二个问题，我在原来的贴子中讨论过：如果是像QQ这样的聊天程序，没有必要维持与每一个客户的连接，因为：
一：你的QQ好友可能很多，而你可能一天内都不会与任何一个好友聊天，而同时维持这么多的连接是没有必要的。
二：你与一个好友聊天，很可能在短时间内你会再次发送信息，其实你自己已经在维持这个Session的有效性了。
三：即使你与另外一个客户的Session因为时间关系已经失效了，那么重新建立一个p2p连接的开销也并非那么大。（服务器需要转发一个命令而已）
#25
mark
#26
to shootingstars(有容乃大，无欲则刚)
那我如果在每个客户（某个NAT内部）和服务器之间维持一个TCP连接，这样就因该不用发送心跳包了吧！如果一个客户发信给另外一个客户，如果不成功就用这个和服务器的TCP直连通知服务器，那这样我的这个TCP端口会不会和我发送给其他客户的UDP端口（发送信息的UDP端口）重复啊？
还有一个问题：
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口和以前这个还是一样的吗？
那我如果在每个客户（某个NAT内部）和服务器之间维持一个TCP连接，这样就因该不用发送心跳包了吧！如果一个客户发信给另外一个客户，如果不成功就用这个和服务器的TCP直连通知服务器，那这样我的这个TCP端口会不会和我发送给其他客户的UDP端口（发送信息的UDP端口）重复啊？
还有一个问题：
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口和以前这个还是一样的吗？
#27
mark
#28
精华啊
#29
to liuzhijun(云)
我想TCP连接仍然存在需要发送心跳包的问题。（NAT仍然可能会因为超时切断这个连接）
TCP的端口与UDP的端口是没有关系的。我想如果使用TCP连接服务器，而使用UDP来连结其他的客户端，这种设计可能会更加复杂，并且我没有实践过。
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口不会一样。
我想TCP连接仍然存在需要发送心跳包的问题。（NAT仍然可能会因为超时切断这个连接）
TCP的端口与UDP的端口是没有关系的。我想如果使用TCP连接服务器，而使用UDP来连结其他的客户端，这种设计可能会更加复杂，并且我没有实践过。
如果一个端口消失了（作用时间过了），那么下次进行会话时新生成的端口不会一样。
#30
TCP的NAT我倒是用，UDP没有写过，不过都差不多的。
#31
学习~!
#32
致敬，另外推荐大家看看 eMule 的源码哦
#33
怎么解决!nat中外网想主动链接内网的机器?
#34
to shootingstars(有容乃大，无欲则刚)
哎！遇到问题了！我下载的代码不知为什么只能单边发送，就是后来的那个可以发送
另外一边不能发送啊，总是失败，你有没有看过这个的原代码啊？帮我看看好吗？
哎！遇到问题了！我下载的代码不知为什么只能单边发送，就是后来的那个可以发送
另外一边不能发送啊，总是失败，你有没有看过这个的原代码啊？帮我看看好吗？
#35
eMule上面有具体讲P2P吗？
#36
学习，顶
#37
大家有实验过这个代码的都来发发言吧！我好象测试了不行啊！只能一边！
#38
to liuzhijun(云)
你能说明一下双方的NAT的情况吗？（双方的NAT的类型）
你能说明一下双方的NAT的情况吗？（双方的NAT的类型）
#39
我们都是中国电信的用的是VDSL拨号上网！还好我们各个宿舍都有电脑，每个宿舍有一个号
都是一个小局域网！呵呵！所以才有机会可以实验！就是这样的吧！因该是CONE NAT吧！
都是一个小局域网！呵呵！所以才有机会可以实验！就是这样的吧！因该是CONE NAT吧！
#40
你们是使用的Win2000作为网关吗？
Win2000作为NAT是Symmetric NAT（STUN检测结果）。
还有，你们是使用同一个外网IP出去的吗？
注意：如果两个客户端处于同一个NAT后，将可能不能正常通讯。
Win2000作为NAT是Symmetric NAT（STUN检测结果）。
还有，你们是使用同一个外网IP出去的吗？
注意：如果两个客户端处于同一个NAT后，将可能不能正常通讯。
#41
这样的吗？Win2000是Symmetric NAT类型的吗？
我晕啊！那具体那些网络才是CONE NAT的网络呢？
我们用的是Win2000的共享上网，就是Win2000作为网关！
那如果是这样的话！其不是很多P2P都不能用了啊？
我晕啊！那具体那些网络才是CONE NAT的网络呢？
我们用的是Win2000的共享上网，就是Win2000作为网关！
那如果是这样的话！其不是很多P2P都不能用了啊？
#42
To liuzhijun(云)
呵呵，不过我也是用的Win2000 Pro做的网关，并且试验成功了。。。原因我也不知道为什么。。。（不知道STUN是如何判断的？）
再问一下:你们的测试双方是在一个NAT后吗？（Win2000肯定不支持loopback translation）
呵呵，不过我也是用的Win2000 Pro做的网关，并且试验成功了。。。原因我也不知道为什么。。。（不知道STUN是如何判断的？）
再问一下:你们的测试双方是在一个NAT后吗？（Win2000肯定不支持loopback translation）
#43
不是吧！你两边都发送成功了吗？是不是和防火墙有关系啊！
你在程序里面有改过东西吗？我测试双方都不是在一个NAT后面啊
我用了3个宿舍的局域网，1个局域网中的主机做服务器，另外两客户端在另外两个NAT里面！
你在程序里面有改过东西吗？我测试双方都不是在一个NAT后面啊
我用了3个宿舍的局域网，1个局域网中的主机做服务器，另外两客户端在另外两个NAT里面！
#44
还是只有一边行，我晕啊！救命啊！神啊！
shootingstars(有容乃大，无欲则刚) 大哥救命啊！
shootingstars(有容乃大，无欲则刚) 大哥救命啊！
#45
to 楼主：
问个问题，假设有下面的情况，只有2个客户端，没有服务器
+----------------------+----------------------+
| |
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)
clientA and clientB 都知道自己的外网IP,然后她们通过打电话（or By Email)告诉对方自己的外网IP,然后
(1)clientA发一个UDP包裹给NAT B (外网IP:187.34.1.56),这样就在Nat A上打了一个洞
(2)clientB发一个UDP包裹给NAT A(外网IP:202.187.45.3),这样就在Nat B上打了一个洞
两边都有洞了，现在ClientA and ClientB 是不是就能通信了？
问个问题，假设有下面的情况，只有2个客户端，没有服务器
+----------------------+----------------------+
| |
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)
clientA and clientB 都知道自己的外网IP,然后她们通过打电话（or By Email)告诉对方自己的外网IP,然后
(1)clientA发一个UDP包裹给NAT B (外网IP:187.34.1.56),这样就在Nat A上打了一个洞
(2)clientB发一个UDP包裹给NAT A(外网IP:202.187.45.3),这样就在Nat B上打了一个洞
两边都有洞了，现在ClientA and ClientB 是不是就能通信了？
#46
To AntingZ(夕惕若)(买了一杆▄︻┳═一)
此种情况下，你需要首先确定双方NAT的类型。你可以使用STUN协议来确定NAT的类型。
如果想用此种方法建立连接，必须双方都是Cone NAT，而且必须有一方不是Restricted Cone NAT。
此种情况下，你需要首先确定双方NAT的类型。你可以使用STUN协议来确定NAT的类型。
如果想用此种方法建立连接，必须双方都是Cone NAT，而且必须有一方不是Restricted Cone NAT。
#47
太经典的文章了，佩服！
#48
好东东啊
#49
怎么在列表里死活找不到这个帖子啊，我顶上去看看^_^