楼上说的没错，但是nat1的效果最好，nat2 3只会增加服务器的负担，，甚至可能无法实现打洞，只能靠客户端去猜测，，意义不大。
因为2和3是对 对方ip进行开放打洞放通，其它用户的ip通过这个洞是进不来的。
例如服务器判断端口号为6666，但是其它用户无法通过6666来连入，所以基本可以放弃nat2 3的打洞
nat1可以实现打洞对所有ip进行放通，任何人可以直接进入无需在次打洞，这个效率才是最好的。
打洞实现的前提，，一定要有服务器来支撑实现，比特彗星正好有服务器，可以做这个实现，不像其他软件是没有服务器，这就无法实现打洞
甚至可以和现有的长效种子服务器数据库整合起来，记录nat类型和端口号即可，下发到客户端即可实现打洞
有关客户端启用UTP的选项，我想了下，可以做成自动检测，类似这样
自动检测，在有绿灯的情况下，则禁止UTP传输接受和发起请求，如果表现为黄灯阻塞，则启用UTP功能
优先，客户端默认发起UTP请求，
禁止，客户端完全屏蔽UTP功能，不进行启用，
强制，客户端默认发起UTP请求，并且只允许接受UTP请求。
Transmission这些没有服务器的支撑，，，远远是不能比的，
哈哈哈哈 画图直接P的
NAT大致分为下面四类
Full Cone
这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A.不管是不是C发过来的.
例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.8.100:5000) → NAT(202.100.100.100 : 8000) → C(292.88.88.88:2000)
任何发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)
Restricted Cone
这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用任何端口和A通信.其他的外网机器不行.
例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.8.100:5000) → NAT(202.100.100.100 : 8000) → C(292.88.88.88:2000)
任何从C发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)
Port Restricted Cone
这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用原来的端口和A通信.其他的外网机器不行.
例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
A(192.168.8.100:5000) → NAT(202.100.100.100 : 8000) → C(292.88.88.88:2000)
C(202.88.88.88:2000)发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)
以上三种NAT通称Cone NAT.我们只能用这3种NAT进行UDP打洞.
Symmetic
对于这种NAT.连接不同的外部目标.原来NAT打开的端口会变化.而Cone NAT不会.虽然可以用端口猜测.但是成功的概率很小.因此放弃这种NAT的UDP打洞.
我们看看不同NAT之间的NAT打洞。NAT打洞需要Server配合，需要2种Server：
根据以上信息，基于服务器打洞可以说基本上只能做nat1来打洞
nat2和nat3只能在客户端做，当nat2的客户端连接到了nat1的客户端后，此时可以打洞，前提是要已经连接成功的情况下，等于是说有一方一定要有外网ip
让nat1的客户端来连入nat2客户端这台，，，基本上来说没意义。只能是1对1，不能是1对N，开发难度大的话，可以完全放弃这种客户端的NAT打洞
有专用服务器支撑的话就只调度可被直接连接的节点了，严格来说除了NAT1之外，还有无NAT和固定映射的主机（姑且把后者都视作NAT1）
记录NAT2、3的节点也不是不行，但服务器同时还要担当信令为两个NAT节点沟通二元组，负担比较大
BEP-55中的描述就是借助中继节点来做信令，为节点A和节点B沟通二元组信息
理论上可以不需要专用服务器来实现穿透，但是条件比较苛刻
首先[中继节点M]要能跟[发起节点A]建立连接，这要求至少其中一个节点是NAT1
而[中继节点M]同时要跟[目标节点B]建立连接，这里也要求其中一个节点是NAT1
理想的情况是[中继节点M]是NAT1，那么[发起节点A]和[目标节点B]即使是NAT2、3也能实现穿透
但如果[中继节点M]不是NAT1的话，说明[发起节点A]和[目标节点B]都是NAT1，既然两者都可以互相直连，那中继纯粹是多余的
这样的设计还有一个乐观的期待，那就是假设[中继节点M]虽然不是NAT1，但通过其他的中继节点成功与[发起节点A]和[发起节点B]建立了连接，这样[节点M]、[节点A]、[节点B]都是NAT2、3，也能实现穿透
然而实际的应用环境中，这种情况很罕见，只能碰碰运气看中继节点是不是NAT1的同时还连了目标节点
由专用服务器调度的话可以大大提升命中率，但如果记录的NAT1节点太多，可能还需要考虑如何评估哪些节点能为客户端找到所需要的文件
毕竟穿透只是手段，资源才是目的
一些想法
1.【上传参数】实现自动测速【3次以上取平均值，取50%为默认参数】，每天或者每周运行一次。首次安装测速一次。
2.【信息资讯】开设一个【专栏】，用来推送【业内】相关消息。普及一下相关术语知识。
3.【激励计划】测试【有偿上传】来保持【BT网络的活跃度】，可以参考【积分兑换】【长效数量】【兑换奖励】【云加速:服务器或者bitcomet用户自动加速】
4.【云加速】依靠【服务器】或者bitcomet用户自动加速通道，来实现【冷门资源加速】。这是个有偿加速功能。依靠于【激励计划】。实现步骤，1.用户提交【冷门资源】，2.【服务器或者加入【激励计划】的bitcomet用户】自动下载资源，并同时上传。
云加速什么鬼，巴不得彗星死吗
迅雷：这我熟悉呀~ 
你这想法完全不现实，首先第一点自动限速就不符合BT分享精神了
第二点倒是感觉可以做，普及一些BT相关问答
第三点，IPFS， FIL这些为什么暴死，不是没道理的，这种积分式有偿做种，并不合理
第四点，你真想玩这些，目前我推荐你挂迅雷网心云
【自动测速】的目的不是【限速】，是为了确保【上传】是打开的。所以【每天或者每周强制运行一次。】
【激励模式】并不等同与ipfs模式。是为了【保活】。参考bittorrent speed。
迅雷的【网心云、星域云】是有偿cdn分布式网络。还是一个【封闭的独立网络】，没钱不给用的。
参考百度网盘的【下载提速】
最近UDP传输打击越来越严了。。真不知道做出来后效果会怎么样
下载完成后自动杀毒这个功能坏掉了。
卡巴斯基用法例如，参数为SCAN
"C:\Program Files (x86)\Kaspersky Lab\Kaspersky Free 21.3\avp.com" SCAN "C:\Program Files"
猜測 龜兔賽跑 的概念, 例如: 長效種子 udp 跑 kb 與 tcp 跑 mb, 兩個世界的差異… XD
除非有導入 quic, 或其他加密協定, 突破重圍…
如上…
自动测速 是为了确保【上传】是打开的，防止有人【关闭上传】。
并不是所有的事情都需要【官方人员】亲自操作。参考Linux的【社区】模式。
云加速模式，可以不使用【服务器】。只使用【bitcomet用户加速】。
这又不是开源软件，非开源哪来的社区维护，关闭上传会自动降低下载速度甚至无速度，人为的关闭上传，那他也没办法下载了。只有qb那软件，才可以做到完全关闭上传不影响下载速度，qb能做到彻底进行吸血只下载不上传
1.谁规定只有开源项目才能使用社区模式？
2.既然你认为bitcomet不能使用【社区】，那换个名称也行，比如【爱好者】【志愿者】也一样。
3.至于bitcomet关闭上传会不会影响下载，没测试过。但重点不是这个，目的是为了确保【上传】有用。限制每秒1k跟关闭上传有什么区别？
反吸血应对外使用，因为bitcomet无法对其进行制约。
对内【bitcomet用户】不应使用【反吸血】，否则会造成大量【用户】流失。毕竟【有觉悟】的还是少数人。用户量不足，bt就无法持续下去。而对于bitcomet来说，官方本就可以强制设置上传参数，以确保【bitcomet】的bt网络正常运行。这比【反吸血】更有利于bt网络。
