基于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，传输速度测试了好久了。但愿实际上线后能撑得住。