想要了解BEP55的效率，你可以创建个私有种子来测试，彗星在私有种子下只使用BEP55，在BT任务才启用NAT1打洞
私有种子 PT内网IP UDP打洞说明.txt
BT任务打洞需要1.81版本，全世界唯一支持打洞的BT客户端
https://bbs.itzmx.com/thread-98941-1-1.html
PT任务打洞需要1.95版本，同样是全世界唯一支持打洞的BT客户端，实现使用BT协议标准为BEP 55 Holepunch extension
BT打洞原理
使用PEX交互打洞信息，可以做到实时打洞成功
（直接看我发过的视频和之前站内发的帖子更容易理解，A为公网，B为NAT1，C为NAT4，B和A连接，C连接A后使用PEX实时获得来自A响应可用于打洞的peerB。同时1.95做到了AB两者网络异常断开后反向回连）
PT打洞原理
私有种子根据规范，使用BEP55协议，打洞需要等待2分钟左右
（UTP直接发起请求连接失败后，则对自身客户端已经建立TCP和UTP传输连接的所有peer发起BEP55协议请求，随后响应可用于打洞的peer）
站内下载的1.81及以上比特彗星客户端，仅需设置”选项-BT下载-为BT连接启用UTP传输协议“改为自动检测，即可实现BT任务打洞
PT任务打洞则需要1.95及以上版本，需要启用UTP传输协议的同时，高级设置bittorrent.utp_after_holepunch 改为自动
bittorrent.peer_hole_punch 默认启用，无需改动
bittorrent.private_torrent_peer_hole_punch 默认是，无需改动
bittorrent.utp_after_holepunch 默认禁用，需要改为自动
目前1.95版本UTP传输速率比较龟速，依旧需要等待后续版本更新优化打洞成功后的传输速率。
截至目前2022年11月20日测试结果，其它BT客户端测试依旧不支持UDP打洞
你这张图的udp打孔就是bep55，假设这个用户是C，你是用户A，B和C连接成功，并且C有公网ip，但是B和C是通过UTP连接的，所以你A连接到B后，bep55响应了B的UTP列表，得到对方C的信息，由于C有公网ip，你A就直接请求到C是TCP连接了
这就是上面说的，比特彗星的UTP视乎不愿意发起下载上传请求，所以现在版本开启UTP速度才会很慢，启用后基本上最快只有10MB/s内，其它BT软件UTP倒是可以轻松跑满1Gbps
黄色代表反吸血正在检测中，绿色代表正常用户，红色代表吸血用户，灰色代表等待连接
1個讚
嗯 这样的话就只能等优化utp传输效率的
不然的话开utp的CPU占用太高 速度也没有
根本不敢开 即使支持也没法用
元数据下载什么时候能和其它BT软件一样，多个peer同时累加进度，然后不会暂停下载重新开始后 元数据又变回0重新从头开始
cpu问题应该很好优化才对，，但是不知道官方为什么还没开始优化，应该来说捕获个dmp然后能分析cpu在哪行代码使用，然后改代码优化吧
之前提出后没有关注后续的更新，今天才发现1.80版本已经支持implied_port和PEX端口替换。
这边测试后，发现DHT的implied_port工作正常，并且能正确发起uTP打洞，让两个NAT3客户端建立连接。
但禁用DHT后，仅测试PEX时发现提供的仍然是本地监听端口，而不是外网端口。
该视频实际上也是通过DHT获得NAPT后的端口，而非PEX
视频位置03:30中可以看到，在未连上任何peer，也就是未进行PEX前，就已经获得了136.243.24.11的公网端口62643
该视频未列出用户来源，但根据界面可以推断出是DHT
是没有正确替换端口，或者是同一IP多个端口被去重了？
抓包看到的都是编码后的BT流，不好解读……
禁用DHT的情况，需要发起请求为UTP时候成功连接到对方，PEX才会响应自身NAT1打洞后的端口进行交互peer列表
也就是说只有AB两人的话，必须要有一方已经打洞成功能够访问到对方，你测试时候由于双方是NAT3，则需要借助第三者来进行ABC打洞，视频中演示的是NAT4类型（DHT也算一个第三者）
qbittorrent 至今还没实现NAT1打洞，开发者甚至不知道什么是NAT1，2024年了，比特彗星依旧是全球唯一支持打洞的BT下载软件
包括qbittorrent 对IPV6也不支持
测试时就是用3个客户端，其中一个公网（S），两个NAT3（A与B），并且强制uTP连接
预期的结果是，当公网S与内网A建立uTP连接后，会把内网peer实际连接的公网端口，而不是其通告的本地监听端口加入到PEX列表
然而，当内网B通过uTP连接上公网S后，进行PEX获取到的仍然是内网A的监听端口而不是公网端口
同样地，内网A在这之后从公网S获得的PEX，也是内网B的本地监听端口
同时测试了qBittorrent（基于libtorrent），虽然lt的源码中有PEX端口替换的部分，但实际上也没有交换到NAPT后的公网端口
在implied_port正常工作的情况下，PEX端口替换重要性不高
但既然已经做了，希望它能正确工作
你指的是比特彗星还是qb，比特彗星在1.81版本就开始完美NAT1打洞了，而且支持2台客户端打洞，PEX交互端口也是正常工作的，1.95版本优化了加快交互PEX，大概建立连接开始传输有速度后等待7秒左右执行打洞（一定要有速度，如果0KB是不会交互PEX打洞信息的）
NAT3理论上是不能打洞的，对比NAT1来说让NAT3打洞实现起来比较困难，毕竟NAT3无法保持外部UDP端口打开，NAT3的打洞成功率会低很多
qb那边和开发者联系过，，，然后他们都不懂NAT1，看issues历史消息就知道了
比特彗星PEX如图所示，比特彗星会正确使用NAT后的远程端口用于打洞
DHT如图所示，NAT3打洞后的端口，成功被公网ip服务器反向回连成功，NAT3打洞的前提一定是对方有公网ip或者NAT1，所以NAT3打洞的价值不大，最好设置好DMZ或者upnp来获取NAT1
然而在qb，无法进行任何方式的NAT1打洞
好久沒用…2.06看上去多了雙擊停止驗證任務…
剛剛任務跳動點錯了個1tb的任務…而且還不帶中斷記錄…
能不能增加一個確認提示呢…
233333
剛剛從QB回來的…QB沒了硬盤快取設定…實在太垃圾
下載幾個MB/S…硬盤被扯爆100%使用率…
立馬又刪掉了…
外國人的思想是很奇怪的…
@wxhere15
目前有优化utp的计划吗？
现阶段utp有比较严重的性能问题 以至于几乎不可用
为保证软件和系统的正常运行只能禁用 utp
这使得打洞功能也不可用
之前帖子就讨论过，，qb更倾向使用系统级的缓存，隐藏在系统中不可见，容易被其它程序刷新冲掉，进程不占用独享内存去使用导致取不到缓存，所以很垃圾
好像是
导入和导出下载列表
他人共享 (18,560,000).bc_bak
16 GB RAM 吃了 15 GB,
比特彗星 崩溃 造成的,
这几天 没再发生.
麻烦改一下.
删除任务时
按 Delete 有作用,
但
按 最右边的 数字区 的 Del 没有作用.
(指 所有下载(下载中/完成/未完成/正在运行)
HTTP/FTP 下载 取得 服务器 上的 原始日期时间
例:
https://download.bitcomet.com/achive/BitComet_2.06.zip
下载 文件 原始日期时间 应该是
2024/01/18 上午 12:43 32,432,861 BitComet_2.06.zip
另外:
如图:
請問開通 [好友上傳通道] 過一陣子就沒有上傳速度?
查看旗標狀態上傳並沒有通道窒息
全局6M上傳頻寬扣掉 1M 長效,也還有 5M 可供上傳…
當停止任務後重新啟動，上傳速度就會恢復正常，初步感覺並非對方的問題。然而，上傳一段時間後速度又會歸零，必須手動重新啟動任務才能再次享有正常上傳速度。不太清楚這可能是什麼問題，是否有可能解釋或解決這種情況呢？還是要滿足什條件才能實現優先上傳?
所以才問問能不能加上…關閉任務提示…畢竟如果數TB的種子…校檢一次要數小時…誤點心態要爆炸…
