�??xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>&#20122;&#27954;&#23159;&#23159;&#22269;&#20135;&#31934;&#21697;&#30005;&#24433;&#20154;&#20037;&#20037;&#44;&#26085;&#38889;&#20037;&#20037;&#20037;&#20037;&#20037;&#20013;&#25991;&#20154;&#22971;&#44;&#20037;&#20037;&#20037;&#20037;&#20122;&#27954;&#65;&#86;&#26080;&#30721;&#27704;&#19981;</title><link>http://www.shnenglu.com/deane/category/11128.html</link><description>                    �q�逐梦惻I���怸�停步......</description><language>zh-cn</language><lastBuildDate>Sat, 01 May 2010 09:48:49 GMT</lastBuildDate><pubDate>Sat, 01 May 2010 09:48:49 GMT</pubDate><ttl>60</ttl><item><title>双缓冲消息队�?减少锁竞�?/title><link>http://www.shnenglu.com/deane/articles/113983.html</link><dc:creator>李阳</dc:creator><author>李阳</author><pubDate>Thu, 29 Apr 2010 10:29:00 GMT</pubDate><guid>http://www.shnenglu.com/deane/articles/113983.html</guid><wfw:comment>http://www.shnenglu.com/deane/comments/113983.html</wfw:comment><comments>http://www.shnenglu.com/deane/articles/113983.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.shnenglu.com/deane/comments/commentRss/113983.html</wfw:commentRss><trackback:ping>http://www.shnenglu.com/deane/services/trackbacks/113983.html</trackback:ping><description><![CDATA[<p>&nbsp;</p>
<p>在网�l�应用服务器�? ��Z��性能和防止阻�? �l�常�?x��)把逻辑处理和I/O处理分离:<br>I/O�|�络�U�程处理I/O事�g: 数据包的接收和发�? �q�接的徏立和�l�护�{?<br>逻辑�U�程要对收到的数据包�q�行逻辑处理.</p>
<p>通常�|�络�U�程和逻辑�U�程之间是通过数据包队列来交换信息, ���单来说就是一个生产�?消费者模�?<br>�q�个队列是多个线�E�在�׃�n讉K��必须加锁, 意味着每次讉K��都要加锁。如何更好的如何减少锁竞争次数呢 ?</p>
<p>�Ҏ(gu��)��一 双缓冲消息队�?</p>
<p>两个队列�Q�一个给逻辑�U�程读，一个给IO�U�程用来写，当逻辑�U�程��d��队列后会(x��)���自��q��队列与IO�U�程的队列相调换�?br>IO�U�程每次写队列时都要加锁�Q�逻辑�U�程在调换队列时也需要加锁，但逻辑�U�程在读队列时是不需要加锁的.</p>
<p>队列�~�冲区的大小要根据数据量的大���进行调整的�Q�如果缓冲区很小�Q�就能更及时的处理数据，但吞吐量以及出现资源竞争的几率大多了�?/p>
<p>可以�l�缓冲队列设�|�最大上限，���过上限的数量之后，���包丢弃不插入队列�?br>另外�Q�双�~�冲的实��C��有不同策略的�Q?/p>
<p>一是读操作优先�Q�就是生产者只要发现空闲缓�Ԍ��马上swap�Q?br>二是写线�E�只有在当前的缓冲区写满了，才进行swap操作�?br>三是上层逻辑按照帧率来处理，每一帧的时候将双层�~�冲队列调换一下，取一个队列来处理卛_��</p>
<p>&nbsp;</p>
<p><br>�Ҏ(gu��)���?提供一个队列容�?</p>
<p>提供一个队列容器，里面有多个队列，每个队列都可固定存放一定数量的消息。网�l�IO�U�程要给逻辑�U�程投递消息时�Q�会(x��)从队列容器中取一个空队列来��用，直到���该队列填满后再攑֛�容器中换另一个空队列。而逻辑�U�程取消息时是从队列容器中取一个有消息的队列来��d���Q�处理完后清�I�队列再攑֛�到容器中�?/p>
<p>�q�样便��得只有在寚w��列容器进行操作时才需要加锁，而IO�U�程和逻辑�U�程在操作自己当前��用的队列旉���不需要加锁，所以锁竞争的机�?x��)大大减���了�?/p>
<p>�q�里为每个队列设了个最大消息数�Q�看来好像是打算只有当IO�U�程写满队列时才�?x��)将其放回到容器中换另一个队列。那�q�样有时也会(x��)出现IO�U�程未写满一个队列，而逻辑�U�程又没有数据可处理的情况，特别是当数据量很���时可能�?x��)很��?gu��)��出现[�q�个可以通过讄������时来处�? 如果当前旉���-向队列放入第一个包的时�?&gt; 50 ms, ���将其放回到容器中换另一个队列]�?/p>
<p>通常我们逻辑服务器会(x��)以场景来划分�U�程,不同�U�程执行不同场景.一个线�E�可以执行多个场�?因�ؓ(f��)玩家属于场景,我们�?x��)把玩家数�?包括其缓冲池丢给场景 ��d���? <br></p>
<img src ="http://www.shnenglu.com/deane/aggbug/113983.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.shnenglu.com/deane/" target="_blank">李阳</a> 2010-04-29 18:29 <a href="http://www.shnenglu.com/deane/articles/113983.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>[p2p]UDP用打�z�技术穿透NAT的原理与实现�Q�附源代�?转）</title><link>http://www.shnenglu.com/deane/articles/89619.html</link><dc:creator>李阳</dc:creator><author>李阳</author><pubDate>Thu, 09 Jul 2009 04:04:00 GMT</pubDate><guid>http://www.shnenglu.com/deane/articles/89619.html</guid><wfw:comment>http://www.shnenglu.com/deane/comments/89619.html</wfw:comment><comments>http://www.shnenglu.com/deane/articles/89619.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.shnenglu.com/deane/comments/commentRss/89619.html</wfw:commentRss><trackback:ping>http://www.shnenglu.com/deane/services/trackbacks/89619.html</trackback:ping><description><![CDATA[<br><br>首先先介�l�一些基本概念：(x��)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT(Network Address <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Translators)�Q�网�l�地址转换�Q�网�l�地址转换是在IP地址日益�~�Z��的情况下产生的，它的主要目的���是��Z��能够地址重用。NAT分�ؓ(f��)两大�c�，基本的NAT和NAPT(Network <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Address/Port Translator)�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最开始NAT是运行在路由器上的一个功能模块�?
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最先提出的是基本的NAT�Q�它的��生基于如下事实：(x��)一个私有网�l�（域）中的节点中只有很���的节点需要与外网�q�接�Q�呵呵，�q�是在上世纪90�q�代中期提出的）。那么这个子�|�中其实只有���数的节炚w��要全球唯一的IP地址�Q�其他的节点的IP地址应该是可以重用的�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 因此�Q�基本的NAT实现的功能很���单，在子�|�内使用一个保留的IP子网�D�，�q�些IP对外是不可见的。子�|�内只有���数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节炚w��要访问外部网�l�，那么基本NAT���p��责将�q�个节点的子�|�内IP转化��Z��个全球唯一的IP然后发送出厅R�?基本的NAT�?x��)改变I(y��)P包中的原IP地址�Q�但是不�?x��)改变I(y��)P包中的端�?<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 关于基本的NAT可以参看RFC 1631</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 另外一�U�NAT叫做NAPT�Q�从名称上我们也可以看得出，NAPT不但�?x��)改变经�q�这个NAT讑֤�的IP数据报的IP地址�Q�还�?x��)改变I(y��)P数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵�Q�我没有见到�q�）�Q�NAPT才是我们真正讨论的主角。看下图�Q?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Server S1<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 18.181.0.31:1235<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^ Session 1 (A-S1) ^ |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 18.181.0.31:1235 | |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v 155.99.25.11:62000 v |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 155.99.25.11<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^ Session 1 (A-S1) ^ |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 18.181.0.31:1235 | |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v 10.0.0.1:1234 v |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Client A<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10.0.0.1:1234<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 有一个私有网�l?0.*.*.*�Q�Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A是其中的一台计���机�Q�这个网�l�的�|�关�Q�一个NAT讑֤��Q�的外网IP�?55.99.25.11(应该�q�有一个内�|�的IP地址�Q�比�?0.0.0.10)。如果Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A中的某个�q�程�Q�这个进�E�创��Z��一个UDP <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Socket,�q�个Socket�l�定1234端口�Q�想讉K��外网��L��18.181.0.31�?235端口�Q�那么当数据包通过NAT时会(x��)发生什么事情呢�Q?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 首先NAT�?x��)改变这个数据包的原IP地址�Q�改�?55.99.25.11。接着NAT�?x��)��?f��)�q�个传输创徏一个Session�Q�Session是一个抽象的概念�Q�如果是TCP�Q�也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的�W�一个UDP开始，�l�束呢，呵呵�Q�也许是几分钟，也许是几���时�Q�这要看具体的实��C���Q��ƈ且给�q�个Session分配一个端口，比如62000�Q�然后改变这个数据包的源端口�?2000。所以本来是�Q?0.0.0.1:1234-&gt;18.181.0.31:1235�Q�的数据包到了互联网上变��Z���Q?55.99.25.11:62000-&gt;18.181.0.31:1235�Q��?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 一旦NAT创徏了一个Session后，NAT�?x��)记�?2000端口对应的是10.0.0.1�?234端口�Q�以后从18.181.0.31发送到62000端口的数据会(x��)被NAT自动的�{发到10.0.0.1上。（注意�Q�这里是�?8.181.0.31发送到62000端口的数据会(x��)被�{发，其他的IP发送到�q�个端口的数据将被NAT抛弃�Q�这样Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A��׃��Server S1建立以了一个连接�?/p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 呵呵�Q�上面的基础知识可能很多人都知道了，那么下面是关键的部分了�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 看看下面的情况：(x��)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Server S1 Server S2<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 18.181.0.31:1235 138.76.29.7:1235<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------------+----------------------+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 18.181.0.31:1235 | | | 138.76.29.7:1235 |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v 155.99.25.11:62000 v | v 155.99.25.11:62000 v<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cone NAT<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 155.99.25.11<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 18.181.0.31:1235 | | | 138.76.29.7:1235 |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v 10.0.0.1:1234 v | v 10.0.0.1:1234 v<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Client A<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10.0.0.1:1234<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 接上面的例子�Q�如果Client A的原来那个Socket(�l�定�?234端口的那个UDP Socket)又接着向另外一个Server <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S2发送了一个UDP包，那么�q�个UDP包在通过NAT时会(x��)怎么样呢�Q?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; �q�时可能�?x��)有两种情况发生�Q�一�U�是NAT再次创徏一个Session�Q��ƈ且再�ơ�ؓ(f��)�q�个Session分配一个端口号�Q�比如：(x��)62001�Q�。另外一�U�是NAT再次创徏一个Session�Q�但是不�?x��)新分配一个端口号�Q�而是用原来分配的端口�?2000。前一�U�NAT叫做Symmetric <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT�Q�后一�U�叫做Cone <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT。我们期望我们的NAT是第二种�Q�呵呵，如果你的NAT刚好是第一�U�，那么很可能会(x��)有很多P2P软�g��q��。（可以庆幸的是�Q�现在绝大多数的NAT属于后者，即Cone <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT�Q?/p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 好了�Q�我们看刎ͼ�通过NAT,子网内的计算机向外连�l�是很容易的�Q�NAT相当于透明的，子网内的和外�|�的计算��Z��用知道NAT的情况）�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 但是如果外部的计���机惌���问子�|�内的计���机���比较困难了�Q�而这正是P2P所需要的�Q��?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 那么我们如果想从外部发送一个数据报�l�内�|�的计算机有什么办法呢�Q�首先，我们必须在内�|�的NAT上打上一�?#8220;�z?#8221;�Q�也���是前面我们说的在NAT上徏立一个Session�Q�，�q�个�z�不能由外部来打�Q�只能由内网内的��L��来打。而且�q�个�z�是有方向的�Q�比如从内部某台��L���Q�比如：(x��)192.168.0.10�Q�向外部的某个IP(比如�Q?19.237.60.1)发送一个UDP包，那么���在�q�个内网的NAT讑֤�上打了一个方向�ؓ(f��)219.237.60.1�?#8220;�z?#8221;�Q�（�q�就是称为UDP <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hole <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Punching的技术）以后219.237.60.1���可以通过�q�个�z�与内网�?92.168.0.10联系了。（但是其他的IP不能利用�q�个�z�）�?/p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 呵呵�Q�现在该轮到我们的正题P2P了。有了上面的理论�Q�实��C��个内�|�的��L��通讯���差最后一步了�Q�那���是鸡生蛋还是蛋生鸡的问题了�Q�两辚w��无法��d��发出�q�接��h���Q�谁也不知道谁的公网地址�Q�那我们如何来打�q�个�z�呢�Q�我们需要一个中间�h来联�p�这两个内网��L���?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 现在我们来看看一个P2P软�g的流�E�，以下图�ؓ(f��)例：(x��)</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Server S �Q?19.237.60.1�Q?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------------+----------------------+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT A (外网IP:202.187.45.3) NAT B (外网IP:187.34.1.56)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | (内网IP:192.168.0.1) | (内网IP:192.168.0.1)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 首先�Q�Client A��d��服务器，NAT A������ơ的Session分配了一个端�?0000�Q�那么Server S收到的Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A的地址�?02.187.45.3:60000�Q�这���是Client A的外�|�地址了。同��P��Client B��d��Server S�Q�NAT <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B�l�此�ơSession分配的端口是40000�Q�那么Server S收到的B的地址�?87.34.1.56:40000�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 此时�Q�Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B�Q�那么他可以从Server S那儿获得B的公�|�地址187.34.1.56:40000�Q�是不是Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A向这个地址发送信息Client B���p��收到了呢�Q�答案是不行�Q�因为如果这样发送信息，NAT <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B�?x��)将�q�个信息丢弃�Q�因�������L(f��ng)��信息是不误���来的�Q��ؓ(f��)了安全，大多数NAT都会(x��)执行丢弃动作�Q�。现在我们需要的是在NAT <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B上打一个方向�ؓ(f��)202.187.45.3�Q�即Client A的外�|�地址�Q�的�z�，那么Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A发送到187.34.1.56:40000的信�?Client B���p��收到了。这个打�z�命令由谁来发呢�Q�呵呵，当然是Server S�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; �ȝ��一下这个过�E�：(x��)如果Client A惛_��Client B发送信息，那么Client A发送命令给Server S�Q�请求Server <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S命��oClient B向Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A方向打洞。呵呵，是不是很�l�口�Q�不�q�没关系�Q�想一惛_��很清楚了�Q�何况还有源代码呢（侯老师说过�Q�在源代码面前没有秘�?<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8�Q�）�Q�然后Client A���可以通过Client B的外�|�地址与Client B通信了�?/p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 注意�Q�以上过�E�只适合于Cone NAT的情况，如果是Symmetric NAT�Q�那么当Client B向Client <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A打洞的端口已�l�重新分配了�Q�Client B���无法知道这个端口（如果Symmetric <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAT的端口是��序分配的，那么我们或许可以猜测�q�个端口��P��可是�׃��可能��D����p�|的因素太多，我们不推荐这�U�猜���端口的�Ҏ(gu��)���Q��?/p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;另一���文章接上：(x��)</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 下面解释一下上面的文章中没有提及或者说我觉得比较欠�~�的地方. <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; �U�有地址/端口和公有地址/端口:我们知道,现在大部分网�l�采用的都是NAPT(Network&nbsp;Address/Port&nbsp;Translator)�?�q�个东东的作用是一个对外的对话在经�q�NAT之后IP地址和端口号都会(x��)被改�?在这里把一�ơ会(x��)话中客户自己认�ؓ(f��)在��用的IP地址和端口号成�ؓ(f��)�U�有地址/端口,而把�l�过NAPT之后被改写的IP地址和端口号�U�Cؓ(f��)公有地址/端口.或者可以这么理�?�U�有地址/端口是你安���人对你的�늧�而公有地址/端口则是你真正对外公开的名�?如何获得用户的私用地址/端口�?�q�个很简单了,而要得到公有地址/端口号就要在�q�接上另一台机器之后由那台机器看到的IP地址和端口号来表�C? <br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 如果明白了上面的东西,下面�q�入我们的代�?在这里解释一下关键部分的实现: <br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 客户端首先得到自��q���U�有地址/�l�端,然后向server端发送登陆请�?server端在得到�q�个��h��之后���可以知道这个client端的公有地址/�l�端,server�?x��)��?f��)每一个登陆的client保存它们的私有地址/端口和公有地址/端口. <br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OK,下面开始关键的打洞���程.假设client&nbsp;A要向client&nbsp;B对话,但是A不知道B的地址,即��知道�Ҏ(gu��)��NAT的原理这个对话在�W�一�ơ会(x��)被拒�l?因�ؓ(f��)client&nbsp;B的NAT认�ؓ(f��)�q�是一个从没有�q�的外部发来的请�?�q�个时�?A如果发现自己没有保存B的地址,或者说发送给B的会(x��)话请求失败了,它会(x��)要求server端让B向A打一个洞,�q�个B-&gt;A的会(x��)话意义在于它使NAT&nbsp;B认�ؓ(f��)A的地址/端口是可以通过的地址/端口,�q�样A再向B(t��i)发送对话的时候就不会(x��)再被NAT&nbsp;B拒绝�?打一个比�Ҏ(gu��)��说明打洞的过�E?A��x��B家做�?但是遭到了B的管家NAT&nbsp;B的拒�l?理由�?我从来没有听我家B提过你的名字,�q�时A扑ֈ�了A,B都认识的朋友server,要求server�l�B报一个信,让B去跟���家说A是我的朋�?于是,B跟管家NAT&nbsp;B�?A是我认识的朋�?�q�样A的访问请求就不会(x��)再被���家NAT&nbsp;B所拒绝�?���而言�?UDP打洞���是一个通过server保存下来的地址使得彼此之间能够直接通信的过�E?server只管帮助建立�q�接,在徏立间接之后就不再介入�? </p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 下面是一个模拟P2P聊天的过�E�的源代码，�q�程很简单，P2PServer�q�行在一个拥有公�|�IP的计���机上，P2PClient�q�行在两个不同的NAT后（注意�Q�如果两个客��L(f��ng)���q�行在一个NAT后，本程序很可能不能�q�行正常�Q�这取决于你的NAT是否支持loopback <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; translation�Q�详�?a ><u><font color=#0000ff>http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt</font></u></a>�Q�当�Ӟ��此问题可以通过双方先尝试连接对方的内网IP来解冻I��但是�q�个代码只是��Z��验证原理�Q��ƈ没有处理�q�些问题�Q�，后登录的计算机可以获得先��d��计算机的用户名，后登录的计算机通过send <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; username message的格式来发送消息。如果发送成功，说明你已取得了直接与�Ҏ(gu��)���q�接的成功�?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; �E�序现在支持三个命��o�Q�send , getu , exit</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; send格式�Q�send username message<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 功能�Q�发送信息给username</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; getu格式�Q�getu<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 功能�Q�获得当前服务器用户列表</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exit格式�Q�exit<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 功能�Q�注销与服务器的连接（服务器不�?x��)自动监���客��h��否吊�U�）</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 代码很短�Q�相信很�Ҏ(gu��)��懂，如果有什么问题，可以�l�我发邮�?a href="&#109;&#97;&#105;&#108;&#116;&#111;&#58;&#122;&#104;&#111;&#117;&#104;&#117;&#105;&#115;&#50;&#50;&#64;&#115;&#105;&#110;&#97;&#46;&#99;&#111;&#109;"><u><font color=#0000ff>zhouhuis22@sina.com</font></u></a> <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 或者在CSDN上发送短消息。同�Ӟ���Ƣ迎转发此文�Q�但希望保留作者版�?-�Q��?br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _05/04052509317298.rar" <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a ><u><font color=#0000ff>http://www.ppcn.net/upload/2004_05/04052509317298.rar</font></u></a> 　</p>
<p>&nbsp;</p>
<p>另一���介�l�打�z�技术的�Q�补充）</p>
<p>UDP打洞技术依赖于由公共防火墙和cone NAT�Q�允�?d��ng)R��当的有计划的端对端应用�E�序通过NAT"打洞"�Q�即使当双方的主机都处于NAT之后。这�U�技术在 RFC3027�?.1节[NAT PROT] 中进行了重点介绍�Q��ƈ且在Internet[KEGEL]中进行了非正式的描叙�Q�还应用��C��最新的一些协议，例如[TEREDO,ICE]协议中。不�q�，我们要注意的是，"�?如其名，UDP打洞技术的可靠性全都要依赖于UDP�?br>�q�里���考虑两种典型场景�Q�来介绍�q�接的双方应用程序如何按照计划的�q�行通信的，�W�一�U�场景，我们假设两个客户端都处于不同的NAT之后�Q�第二种场景�Q�我们假设两个客��L(f��ng)��都处于同一个NAT之后�Q�但是它们彼此都不知�?他们在同一个NAT�?�?br><br><br>&nbsp;<br>处于不同NAT之后的客��L(f��ng)��通信<br><br>&nbsp;&nbsp;&nbsp; 我们假设 Client A �?Client B 都拥有自��q���U�有IP地址�Q��ƈ且都处在不同的NAT之后�Q�端对端的程序运行于 CLIENT A,CLIENT B,S之间�Q��ƈ且它们都开放了UDP端口1234�?CLIENT A和CLIENT B首先分别与S建立通信�?x��)话�Q�这时NAT A把它自己的UDP端口62000分配�l�CLIENT A与S的会(x��)话，NAT B也把自己的UDP端口31000分配�l�CLIENT B与S的会(x��)话�?br><br>假如�q�个时�?CLIENT A 想与 CLIENT B建立一条UDP通信直连�Q�如�?CLIENT A只是���单的发送一个UDP信息到CLIENT B的公�|�地址138.76.29.7:31000的话�Q�NAT B�?x��)不加考虑的将�q�个信息丢弃�Q�除非NAT B是一�?full cone NAT�Q�，因�ؓ(f��) �q�个UDP信息中所包含的地址信息�Q�与CLIENT B和服务器S建立�q�接时存储在NAT B中的服务器S的地址信息不符。同��L(f��ng)���Q�CLIENT B如果做同��L(f��ng)��事情�Q�发送的UDP信息也会(x��)�?NAT A 丢弃�?br><br>&nbsp;假如 CLIENT A 开始发送一�?UDP 信息�?CLIENT B 的公�|�地址上，与此同时�Q�他又通过S中�{发送了一个邀请信息给CLIENT B�Q�请求CLIENT B也给CLIENT A发送一个UDP信息�?CLIENT A的公�|�地址上。这时CLIENT A向CLIENT B的公�|�IP(138.76.29.7:31000)发送的信息��D�� NAT A 打开一个处�?CLIENT A的私有地址和CLIENT B的公�|�地址之间的新的通信�?x��)话�Q�与此同�Ӟ��NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公�|�地址(155.99.25.11:62000)之间的新的通信�?x��)话。一旦这个新的UDP�?x��)话各自向对��?gu��)��开了，CLIENT A和CLIENT B之间���可以直接通信�Q�而无需S来牵�U�搭桥了�?�q�就是所谓的打洞技�?�Q?/p>
<br><br><br>
<img src ="http://www.shnenglu.com/deane/aggbug/89619.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.shnenglu.com/deane/" target="_blank">李阳</a> 2009-07-09 12:04 <a href="http://www.shnenglu.com/deane/articles/89619.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>                                                                                                                          <footer>
<div class="friendship-link">
<p>��л���������ǵ���վ�������ܻ���������Դ����Ȥ��</p>
<a href="http://www.shnenglu.com/" title="&#31934;&#21697;&#35270;&#39057;&#20037;&#20037;&#20037;&#20037;">&#31934;&#21697;&#35270;&#39057;&#20037;&#20037;&#20037;&#20037;</a>

<div class="friend-links">


</div>
</div>

</footer>

<a href="http://www.numxj.cn" target="_blank">������Ʒ�þ��������</a>|
<a href="http://www.qdog.com.cn" target="_blank">�����˳�������վ�þ�99�ȹ���</a>|
<a href="http://www.skjzy.cn" target="_blank">�þþ�Ʒһ����������������Ļ</a>|
<a href="http://www.ggpj.net.cn" target="_blank">�þ����޾�Ʒ����av������վ</a>|
<a href="http://www.dg-rx.cn" target="_blank">���޾�Ʒ�ۺϾþ�</a>|
<a href="http://www.zhaoyang-db.com.cn" target="_blank">��Ʒ��Ƶ�þþþ�</a>|
<a href="http://www.hhh328.cn" target="_blank">�þþ�Ʒ����һ����������</a>|
<a href="http://www.enjoa.cn" target="_blank">���b��Ʒ�þþþþþ�</a>|
<a href="http://www.h6343.cn" target="_blank">�ݺ�ɫ���˾þþ�Ʒ�ۺ���</a>|
<a href="http://www.zqyipin.cn" target="_blank">�þ�99�þó�����Ѳ���</a>|
<a href="http://www.androidfans.com.cn" target="_blank">�����������˾þþ�Ʒ</a>|
<a href="http://www.qhsy217.cn" target="_blank">�þþ�Ʒ?������������Ļ</a>|
<a href="http://www.qqhaobofangqi.cn" target="_blank">91�þþ�Ʒ��Ӱ</a>|
<a href="http://www.jrsddk.cn" target="_blank">�þù�������һ����������</a>|
<a href="http://www.cctv-87.cn" target="_blank">�þ����ľ�Ʒ����������Ļ</a>|
<a href="http://www.simple521.cn" target="_blank">�Ļ��þ�ӰԺ</a>|
<a href="http://www.xn88.cn" target="_blank">ɫ���ۺϾþ�������Ļ��</a>|
<a href="http://www.ryjv.cn" target="_blank">�þþþ�����һ����������vr</a>|
<a href="http://www.whnnmj.cn" target="_blank">�þþþ���ѿ�����ӰƬ</a>|
<a href="http://www.pochai.cn" target="_blank">������Ʒ99�þ���ѹۿ�</a>|
<a href="http://www.ode.net.cn" target="_blank">�þ��ۺ��ۺϾþ�97ɫ</a>|
<a href="http://www.jsrst-gov.cn" target="_blank">�����߳��þ���ѹۿ�</a>|
<a href="http://www.netbirds.cn" target="_blank">���޾�ƷNV�þþþþþþþ�</a>|
<a href="http://www.hskx.org.cn" target="_blank">�������߾þþ�Ʒ���Ĺ���</a>|
<a href="http://www.damingxing.cn" target="_blank">�������ù�����Ʒ��Ӱ�˾þ�</a>|
<a href="http://www.xhxqbj.cn" target="_blank">���޾�Ʒ����þþþ�</a>|
<a href="http://www.lbaak.cn" target="_blank">�þ�99������Ʒ�þ�99</a>|
<a href="http://www.myjhy.cn" target="_blank">��Ʒ�þ��ۺ�1��2��3������</a>|
<a href="http://www.barf1.com.cn" target="_blank">ɫ͵͵91�þ��ۺ���������</a>|
<a href="http://www.ghmsgs.cn" target="_blank">���޼���V����ëƬ�þþ�Ʒ</a>|
<a href="http://www.99j9.cn" target="_blank">�þ��ۺϾþ��ۺϾþ�</a>|
<a href="http://www.kqvx.cn" target="_blank">�ձ�WVһ��һ���þ��㽶</a>|
<a href="http://www.fragrancebeads.cn" target="_blank">ɫ���þþ��������ۺ�����Ʒ
</a>|
<a href="http://www.ha-jc.cn" target="_blank">�þ�����������Ļ��Ʒһ����</a>|
<a href="http://www.muxi365.cn" target="_blank">�þþþ�Ʒ�þþþþ�
</a>|
<a href="http://www.todouba.cn" target="_blank">��Ʒ�þþþþ�����������Ļһ��</a>|
<a href="http://www.hoqw.cn" target="_blank">�þþþþþ�����Av����</a>|
<a href="http://www.starlight-caraccessories.cn
" target="_blank">��Ʒ�þþþþù���91</a>|
<a href="http://www.52cjw.cn" target="_blank">�þþ�Ʒ������Ʒ��������</a>|
<a href="http://www.jmjrt.cn" target="_blank">����AV����þþ�Ʒɫ��
</a>|
<a href="http://www.yiyaosheji.cn" target="_blank">�����ۺϾþ��ۺϼ���þ�</a>|
<script>
(function(){
    var bp = document.createElement('script');
    var curProtocol = window.location.protocol.split(':')[0];
    if (curProtocol === 'https') {
        bp.src = 'https://zz.bdstatic.com/linksubmit/push.js';
    }
    else {
        bp.src = 'http://push.zhanzhang.baidu.com/push.js';
    }
    var s = document.getElementsByTagName("script")[0];
    s.parentNode.insertBefore(bp, s);
})();
</script>
</body>