eMule内网穿透原理

测试开始以来，效果不错，Low2Low成功率颇高。

关注了一下大家的反馈，有人担心内网穿透会增加HighID负担，这个理解得有所偏差，关于内网穿透的原理，比较成熟的帖子有: https://www.wendangku.net/doc/2513934481.html,/article/79/79799.shtm

不过这个说的比较复杂，用我自己的浅薄理解，简单说来就是:

内网计算机(也就是LowID)，都通过至少一层网关连接互联网，没有自己的独立IP和端口(别人看到的你的IP是网关的)，所以别人无法主动与你建立连接，两个内网用户自然也就无法连通，更无法实现传输。

但是内网计算机可以主动连接其他有独立IP的外网计算机，再通过udp协议通讯的时候，因为udp是非持续连接的，所以网关那边会给你开一个临时端口，让你能够接受外网计算机返回给你的udp包，如果一段时间内没有传输，临时端口便会取消。

这个步骤就可有空子钻，比如A和B 两台内网计算机，都同时连接外网计算机C进行udp协议的传输，A和B分别用到了临时端口Ap和Bp，这个时候通过Ap就可以主动连接到A，Bp就可以主动连接到B，所以C所要做的，就是把Ap告诉B,把Bp告诉A。AB通过从C那里知道的Ap和Bp，即可实现UDP直连。只要连接不断，临时端口就一直有效，传输期间，C什么都不需要参与，这个过程，俗称打洞，C帮AB打好洞，AB就可以自己玩了。

当然我这个是最简单的讲法，根据不同的网关设备，还是有很多不同情况需要解决。

有人怕Low2Low会耗HighID资源，这个多虑了，不是说不耗，而是耗的根小，C只不过初期接受一下AB发来的UDP请求，并向双方返回一次数据，打洞成功之后就再也没事了。本身UDP传输就耗的资源很少，这一两次UDP传输相对于连接频繁的eMule，可以忽略不计了。

更要说明的一点就是，我们目前测试用的内网穿透eMule，都是连接的我们自己的一台服务器用来做“C”，帮LowID打洞，没有依赖任何其他HighID，而我们那台破PIII服务器，目前同时处理着几百个low2low的连接，也几乎没占多少服务器资源。

当然将来最好的方案，是可以让eMule的Low2Low基于Kad来进行，这样可以不依赖任何第三方的服务器，独立的发展下去。基本原理是LowID利用自己的buddy来做帮助打洞，每个HightID只会帮1个LowID做buddy，所以不会增加HighID的负担。这方面我们也作了研究，不日也准备进行测试。

内网穿透目前是一套成熟的方案，QQ，BC等都早已开始大规模使用。为什么eMule到现在为止才开始由我们开始测试内网穿透呢？主要是因为eMule的开发长期以来都由老外们主导，国外大都由公网IP，Low2Low对他们来说，太不重要。而我们自己也走了很多的弯路，去年尝试通过内置VNN来解决问题，但

VNN相对eMule，是一套太大的解决方案，需要注册和安装虚拟网卡才能使用。虽然我们后来的版本自动完成了这2步，但是VNN的服务器还是无法拖起eMule这巨大的用户群进行这样复杂的应用。

所以这次痛定思痛，自己从头开始开发，主要就是让使用tcp协议传输数据的eMule可以利用到UDP直连，并且解决各种各样的细节问题(因为eMule之前都没考虑到low2low问题)。
国外也有个neo版本的eMule，尝试利用kad解决Low2Low的问题，但实际使用效果不好。我们在开发过程中也想参考，不过基本没参考成，代码太复杂太乱。最后还是根据自己的思路自己写的，会比neo的思路更清晰些。

这次的内网测试版本，是我们VeryCD软件开发组近几个月努力得来的一点小成绩，希望能够早日正式发布。我虽不是软件开发，但有幸参与这个过程。所以把自己所理解的东西向大家解释一下。虽然会有纰漏，但不熟悉相关技术的同志，应该更容易理解。

最后补充，eMule既然是开源软件，这项技术成熟之后，必然可以共用，对所有eMule用户，都能有所帮助。