目前应该还是有点意义吧，好像μtp的加入，能增加一点点速度（部分资源，支持μtp的）。
如果无法实现打洞，那么uTP的意义就只有它的初衷——拥塞控制。
uTP作为基于UDP的传输协议，当与TCP流量发生竞争时，自降优先级以保证TCP连接（主要是网页）的畅通。
在电缆时代，BT占带宽导致网页体验变差的情况非常明显，那时候大多采取限速的方法避免。
但限速方案的缺点也很明显：
- 非开箱即用，需要用户自行操作并了解自己的宽带性能
- 假设限速80%，那么预留的20%可能无法被很好地利用
uTP的诞生是为了解决这些问题。
至于打洞，是所有UDP连接都拥有的特性。
而uTP基于UDP，理所当然地被赋予了这种期待。
在普遍光纤入户的现在，带宽已经不是当年的级别。
当然，带宽占满仍然会导致延迟增大，这一点上uTP有它的意义。（虽然重要性已经降低）
但UDP连接本身是个双刃剑。
比起同样是基于UDP连接的QUIC，甚至WireGuard，uTP显得有点简陋。
在一些环境下使用uTP可能更好，但反之亦然。
我赞成新增uTP的支持，但不能盲信。
当然了，最理想的是把UDP打洞搞出来。
补充：
据我观察，在TCP和uTP均可被直接发起连接的情况下，由远程发起的大部分连接仍然是TCP。
这说明大部分BT客户端是采取TCP优先的策略。
这情况下uTP的拥塞控制可能没有效果，因为前提是占带宽的是uTP连接，它才可以自我调整。
据说有根据uTP拥塞控制器提供的信息来对TCP连接进行限速的机制，具体实现情况未知。
不会有速度增加 因为是基于udp传输的 全世界在哪都不欢迎udp
特别是这种未加密的utp流量 直接识别 限速qos在骨干网上 如果打洞不了 确实没意义了
新的bittorrent.utp_after_holepunch选项和之前的bittorrent.peer_hole_punch有什么区别。。
bittorrent.peer_hole_punch，是和其它peer交互pex报文？
bittorrent.utp_after_holepunch是执行打洞？
不知道这个版本能打洞了没，，要花时间测一下
根据前面的讨论推测，bittorrent.utp_after_holepunch应该是用来控制是直接发起uTP连接，还是通过UDP打孔方式发起。
bittorrent.peer_hole_punch 选项用于启用 BEP 55 Holepunch extension
bittorrent.utp_after_holepunch 选项用于控制发起uTP连接前是否需要先向第三方请求协助打洞
设置窗口BT设置页面里的uTP选项用于控制peer连接优先使用 TCP 或 uTP 的顺序
目前实现的BEP 55打洞只支持 Full Cone NAT / Restricted Cone NAT / Port Restricted Cone NAT 三类，对于 Symmetric NAT 暂时无解。
1個讚
只需要支持NAT1的Full Cone NAT就行，后三种不用考虑，基本不太现实，nat3和nat4效率太低，nat2还可以凑合用用
晚上抽时间我再测一下好使了不
是不是说反了？
另外禁用utp_after_holepunch后，若无法建立uTP连接，会不会重新触发UDP打孔？
就UDP打洞来说，Symmetric NAT 可以与 Full Cone NAT 和 Restricted Cone NAT 建立连接。
NAT4无法接收来自任何未知的端点的连接。
NAT1和NAT2则能够接收来自NAT4发起的连接，但NAT4主机发起这个连接时所使用的是一个新分配的端口。（如果IP也分配到与此前不同的，则只有NAT1才能接收连接）
NAT1和NAT2主机需要对这个新接收到的端点再发起一次连接，才能建立双向的通信。
如果我没理解错，BEP 55会让双方同时发起一个常规的uTP连接。
而NAT1或NAT2主机在接收到这个连接后，按道理会向其NAPT后的[IP:PROT]返回应答。
这时候尽管这个端点与之前中继节点交换到的信息不一致，但实际上连接已经成功建立。
BEP 55让双方同时发起连接，因此只要是Cone NAT，无论是NAT1还是NAT2、3，都能越过各自的防火墙。
由中心服务器控制，远端单方面发起连接时，才需要考虑淘汰NAT234。
说到底BEP 55的方案效率就是这么低。
感谢反馈，已更正
目前不会
您研究得很透彻。搭建各种NAT类型的测试环境很麻烦，我这边还没仔细测过呢。
感谢 @wxhere15 版主又开始持续更新BitComet，
我这边一个问题不知道版主能否优化，
就是有关Torrent市场他人共享种子的问题，
因为我BitComet设定Torrent市场是设定无限，
所以数据一直长大已经将近一千万笔，共2.3G的SQLite DB大小，
但是我又舍不得把累积了这么久的数据重新建置，
我建议可否在介面上增加查询种子笔数的条件，
例如用SELECT * FROM “PeerShares” LIMIT “笔数”，
去避免一次捞取这么大容量的DB的数据，
以上是我小小的期望，也期望BitComet能够越来越好，谢谢。
nat1环境好搞，购买vps服务器就行，基本都是nat1，然后第三台设备用家中自己的电脑，可以在路由器中设置成nat4，就可以进行测试了
感谢您的关心和支持。目前彗星启动时开启了种子市场，就会加载全部数据库记录。如果只加载部分数据的话，排序、查找、保持记录唯一性等操作等很麻烦。欢迎您提出更具体的功能建议。您也可以使用 sqliteadmin 等第三方程序对数据库文件进行整理、备份等操作。
1個讚
感谢版主您即刻答复，因为自己也是有点程式背景，
了解程式功能增加及修改不是只有表面上看到的这么简单，
没关系，这次1.78版增加了uTP协议是很大幅度的改动，
版主已经努力再继续优化，已经非常感谢您的付出了。
谢谢支持。beta3 发布了，欢迎大家试用。
2個讚
beta2还没用上。。没赶上，beta3就出来了
测试完毕，，这个问题修复了，设置为自动检测的情况下可以正常连接了
但是有一个新的问题，UTP设置为优先或者强制的情况，也连不上，应该是相同的代码BUG，，
NAT打洞也测试了，打洞失败，和beta1一样，依旧无法进行打洞，尝试手动添加ip地址也打洞无效
依旧只能服务器B连接到服务器A，服务器C连接到服务器A，服务器C无法连接服务器B
关于UTP传输协议逻辑应当是，是不是按照我说的这个逻辑做的？
禁止，则关闭UTP，走BT协议加密，不允许UTP协议传入
自动检测，默认发起为TCP，如果TCP失败则尝试UTP，允许TPC传入，允许UTP协议传入
优先，忽略BT协议加密设置，始终以UTP请求发起，如果失败，不会自动转换TCP连接，允许TPC传入，允许UTP协议传
强制，忽略BT协议加密设置，始终以UTP请求发起，并且需要传入链接也为UTP，禁止TCP传入，允许UTP协议传入
打洞的还得改善啊，还是无法进行NAT1打洞，不知道那个PEX报文传递的是什么。。。能不能发出来样式看看，传的如果是客户端的监听端口那就毫无意义
服务器B如果TCP进行到服务器A进行peer连接成功，应当与服务器A保持一条udp活跃的长连接通道（可以参考楼上那人说的，TCP和UTP同时启用可以建立上2个通道，或者仅是一个通道用作保持），用作打洞，如果断开该通道数据流，此时会导致端口端口就会关闭NAT，使其无法进行NAT1打洞
如果是nat2可以不需要保持这一个额外的通道来节省客户端性能，因为无法被其它IP连入（当然这个可以不用做，，有人反映吃性能了在说）
是的，一致的。另外BT协议是否加密是独立设置的，和底层走TCP/uTP没有关系。
PEX报文传递的是客户端的监听端口，详见 bep_0055.rst_post
您是在防火墙端口开通的情况下A-B和A-C直接使用uTP连接不上吗？直接uTP连接需要把bittorrent.utp_after_holepunch关掉，不然会先尝试打洞。
一直停留在1.77我还以为不再更新。我也来求下能不能修改些问题
1.新建BT任务数目能不能多些，我经常找片然后一个个点开链接，好像打开一定数量就不会再打开？
2.档案清单和新建BT下的档案清单，例如按大小排序能不能记住，不要每次都搞一次。
3.能不能设置下载速度未到预期，自动增加任务数量？
4.皮肤能不能换风格啊，这XP风格太旧了。
2個讚
NAT打洞必须获得NAPT后的外部端口，因为几乎只有小型局域网才会NAPT前后的端口一致，电信级NAT出现这种情况的概率极低。
如果PEX传递的只是客户端的监听端口的话，那么就只能实现防火墙打洞，以及不转换端口的NAT打洞。
符合这个条件的是上述的拥有公网地址的小型NAT局域网（并非100%，有冲突的可能），以及不存在NAT但开启防火墙的IPv6环境。（后者越来越普遍）
** 还有几乎不会被考虑的NAT6
广义上，这的确算是"Holepunch"的一种，但显然不是用户所期待的“UDP打洞”。
或许，这就是目前市面上支持uTP的BT客户端所能到达的高度吧。
要实现适用于电信级NAT的打洞也并非不可能，但估计需要花费不小的精力。
一种方案是不依赖BEP 55，独自搭建中心服务器来调度——又回到这个话题上面。
是的，A和B连不上，A和C也连不上，是TCP协议连不上，和beta1的版本一样的问题连不上。
这种监听端口的打洞，0意义，基本上不可能存在相同端口的nat情况
不然这种UTP做出来，，也没有任何实际用途意义
可以做，可以先相同客户端连接，不用考虑其它BT客户端打洞？后续找 libtorrent有无考虑开发一下基于UTP的UDP NAT1打洞 · Issue #6331 · arvidn/libtorrent · GitHub 他们同步更新就行
测试NAT1打洞需要至少3台设备，测试环境如下
做种服务器A
防火墙开放TCP端口，做种客户端设置为UTP启用
下载服务器B
B服务器在路由器中封堵TCP端口，NAT值为1
一样设置为UTP启用，执行下载，此时服务器A可以看到一个来源为被动的服务器B请求。
下载服务器C
C服务器在路由器中封堵TCP端口，NAT值为4
设置UTP启用，执行下载，测试是否与服务器B连接成功
服务器A和服务器B可为公网IP的云VPS，服务器B在系统防火墙高级设置封堵TCP入站即可，服务器C可为家中电脑设备