直接复制跳转后的地址去添加下载，是可以正常多线程的，最好不要用Accept-Ranges来判断，很多服务器不一定返回Accept-Ranges
用curl -r 0-0 地址 来判断是否返回Content-Range头
能不能实现一个策略选项，按种子内每个需下载文件的剩余大小来动态实现BT分块的下载优先级
例如这个种子，其中两个文件没有长效种子加速（虽然写着有3个长效种源，不知为何连不上没加速），导致其余文件都下完了，剩下两个文件等BT的慢速下载（我在其余文件下到90%多时候手动调成最高优先级的）
导致整个种子的下载时间拉长了
如果有个策略能在下载时候能动态调整BT分块的优先选择，优先下载剩余大小多的文件，那么整个种子的总下载时间应该可以缩短
完善utp的必要性和可能遇到的问题
通过UDP打洞可以 一定程度上解决NAT和防火墙阻挡的问题
NAT方面主要是穿透全锥形NAT 其他类型的NAT对端口号和地址有更严格的现在
我们平时所说的NAT其实是 NAT-PT 其会转换端口
也有之转换地址而不转换的端口的NAT其相对较为少见
或我们更多的称其为 防火墙
而防火墙（简单的包过滤防火墙）的穿透就比NAT-PT要容易一些
其不会转换端口 不需要在想办法确认转换后的端口了
尽管随着IPv6的推广 公网数量不足的问题得到缓解
但是防火墙的问题依然存在 而且在目前很多的网络设备对IPv6的支持依然不完善
比如缺少IPv6防火墙设置功能 有些仅有一总开关控制 不能放行单个端口
更有的完全没有办法设置
所以UDP打孔对提升客户端的连通性有很大的帮助
这使得两个未开放端口（TCP）的客户端之间的直连成为可能
不再需要通过“公网”用户间接连通 当然这需要utp
再考虑到现在的libtorrent系客户端站主导地位
其支持utp固所有使用libtorrent库的客户端应都支持utp
utp的设计应考虑对libtorrent系的兼容 或直接借鉴其实现方法
BC目前已经支持utp不过有比较严重的性能问题使得其几乎不可用
CPU占用率高而传输速度却很低
在之前的测试中即使在局域网环境先BC的utp似乎也无法正常工作
两客户端均为BC的情况下 当传输达到一达并不快速度后就会断开
过一段时间后再次连上之后再断开 重复这一过程
尽管现在utp功能默认是关闭的
但还是 建议在其完善前在其选项后面 加上“（实验性）”以防止用户意外开启
不过在修复utp性能问题前我们还面临的一个问题就是UDP发包量过多瘫痪网络问题
目前依然是靠压制全局UDP发包量来解决的
但若之后utp修复后再压制UDP发包量比必然会对utp传输造成影响
目前看来其是由 DHT网络的UDP发包过多而造成的
而我认为造成这一问题的原因是DHT节点过多
DHT节点并非越多越好 过多的节点维护开销会很大
固需要精简DHT节点数量
在和网友的研究中发现BC 的DHT的节点存在一定程度上的“重复记录”
从文档上来看 libtorrent系客户端 似乎默认会忽略跟自身CIDR相近的DHT节点
及在路由上相近的节点
出此之外 从源码上看lt似乎还会忽略同一/24网段下的节点
即一个/24段下面只记录DHT节点
而BC会对每个KID不同的节点都进行记录 即使其使用相同的地址和端口
这在远古时期不是什么问题 但在现在就显得有些不合适了
使得挂机时间越长DHT节点数越多 维护开销也越多
所以目前的建议是：
IPv4下每个地址只保留一个DHT节点 其余的将被忽略
IPv6下的情况比较复杂 个人认为每个/64 或/56 地址块下保留一个节点即可 参考：链接
当然也可以考虑实行和lt类似的忽略在路由上相近的节点以减少攻击
但不管怎么说 DHT节点的数量必须得到控制
节制DHT流量看算是修复utp的一项前置条件
除此之外我们可能呢还需要一个自动控制UTP传输量的方法
就像控制磁盘缓存那样自动调节 而不是依靠压制总发包量来实现
2個讚
其实bt默认的算法是下载最快的区块，如果做了优先级反而会影响下载速度，特别是刚发布种子数不多的情况下
上面反馈过用户peer发起utp的超时忘记改了
其实udp发包速度并不影响，对同一个ip每秒发3000个包都没事，主要是连接数，也就是运营商说的会话数，也就是a和b通讯跑1000M都没问题(之前帖子有比特彗星utp打流测试)，就是不能在短时间出现超过1000个不同的ip地址
速度慢是优化有问题，视乎是客户端发送我要下载数据包有间隔，所以比其他软件慢的多
cpu反馈过好几次了，还没修
dht其实有控制的，统计只是显示了总计观察到多少个，在启用专家模式左侧信息可以看到实时存储了多少个，上限值在记得是1000(刚好触发运营商的1000限制)，可以加个高级选项控制下dht最大数量应该就能解决了
关于上面提到的/24只记录一个ip我觉得不合理，根据kad邻居算法，这么做可能导致距离原因无法连接dht网络快速找到用户
直接加个dht最大值就好了，比如说8个-10000个可选
无论是运营商限制 路由器硬件性能限制 还是 linux 跟踪连接数限制
当发包量达到一定数量后 新的连接便无法建立 这会影响到用户的上网体验
是不可接受的 于是控制发包量便是不得不做的事情
当然我们确实可以要求用户更换运营商 更换路由器或扩大 跟踪连接表
但是用户会觉得 换个软件会更简单 不是所有人都有1TB的大内存
确实 不过目前也不着急 还有些前置问题要解决
例如若utp影响了网络传输该怎么办 如何自动控制utp传输
在充分测试前 不能默认打开utp功能
专家模式下确实可以查看存储节点 但是没有明显的计数
不能确定存储的节点数量 或者维护时联系的节点数量
这个倒是个不错的方法 始终将DHT节点数控制在一个可接受的范围内
不会太少也不会太多
忽略IP地址上相近的节点是为了预防运营商的钓鱼节点 当然在国内其实问题不大
其次在DHT网络中节点之间的距离和其IP地址是否靠近没有关系
在IP地址上靠近的节点在DHT网络中可能距离很远
不过一个/24段只记录一个节点可能不太适合国内环境
会使得大量运行在NAT后面的节点无法被记录 无论其是否开放端口
改成v4一个公网地址保留一个节点 v6一个/64地址块保留一个节点会更加合理
实现一个策略选项，用户可自行选择设置就好
我上电脑确认了下，上限值1000是存储的hash，dht节点数量没有限制，所以会导致每30分钟查询一次DHT网络发起的会话数比较多（产生大约1500-2000，此时大于运营商1000限制），专家模式下都能看到
加个高级选项限制每30分钟发起的会话数就行（随机挑选8个-10000个可选去查询来获取hash），存储的DHT节点最大数量可以保持现状不变
dht最重要能存储公网ip的dht节点，这样内网才能连接到他们，不管是不是同一个ip多个端口，其实这种更好，可以表明对方肯定是DHT超级节点服务器，预期连接的网络质量更好，而且能24小时提供全天服务
顺序下载可能就是你想要的功能
维护的哈希条目不是问题 DHT节点数才是
相比起限制查询数 还是限制总记录的节点数更好
在高级设置中 分开控制IPv6和IPv4节点数
当然也可能是开了匿名模式的qb或者钓鱼节点
qb在匿名模式下每次连接用户 其peerID会变化 但不确定其KID是否变化
相比起依赖超级节点 使用活跃的普通节点更重要
我们不需要也不应该过渡依赖所谓的超级节点 这和DHT去中心化思想相悖
这样还不如去使用传统tracker
简单总结一下DHT的改进建议
精简DHT节点记录数量
- v4一个公网地址保留一个节点
- v6一个/64地址块保留一个节点
在高级设置添加限制DHT节点总数的选项
- IPv6和IPv4节点总数分开控制
- 维护时老旧且无回应的节点应该被剔除
这样一来既能控制DHT开销 也使得所记录的节点有足够的差异性
同时建议在侧边栏中显示节点数量 就像bt任务那样
按我所述的问题，顺序下载大部分情况都会更慢了，短板效应会更凸显，如果末尾有长效种子加速不到的文件。bt默认的下载算法是没考虑长效种子加速的。在长效种子的环境下并不是最优选择。
v2.12 正式版预览(win32/macOS/Linux/docker)已上传，欢迎试用
linux版本是不是传错了，下载链接还是2.12.1，我去试试docker看看内存剩余量正常了没有
安卓版也可以同步下内核更新，，，应该也会有内存剩余问题，由于判断真实内存有错误，会导致取不到BT任务内存缓存
补充
测试了下安卓版，当前2.5.1版本剩余真实内存判断是正常的，安卓下没有这个取不到内存的毛病
docker的剩余内存统计正常了，Linux版应该也ok了
但是beta新加的统计信息这些都显示不出来，会报错在控制台 net::ERR_EMPTY_RESPONSE
/panel/statistics 里也没看到有分别显示出进程堆缓存TCP缓冲区等内存使用情况，可能是这个原因导致报错
下载2.12.1用7z解压发现修改时间是14号昨天的，不是今天15号最新的，估计是包传错了导致的docker一起出问题
现在科学了，滚动条
有了，虽然和浏览器的有点区别，不过至少有这个头了
Extension: application_layer_protocol_negotiation (len=11)
Type: application_layer_protocol_negotiation (16)
Length: 11
ALPN Extension Length: 9
ALPN Protocol
ALPN string length: 8
ALPN Next Protocol: http/1.1
还是有问题，，，那个链接只能跑2个线程，设置的是5个
从线程2来看，是302后没有发Range: bytes=4454149223- 在跳转之前就发了
现在是第二个线程有继续发起，，但是设置5线程下载的情况，第3-5个线程是空白
感觉是 开始检测服务器是否支持断点续传。那里没处理好，导致没有新建后续线程
2025-01-16 00:49:38 开始检测服务器是否支持断点续传。
2025-01-16 00:49:38 工作线程启动。
2025-01-16 00:49:38 开始连接download.zygames.com:443...
2025-01-16 00:49:38 连接download.zygames.com:443成功。
2025-01-16 00:49:38 GET /qqsm/install_mars3/30235c786052b430b0dc8d98a43f11a6f4fe6/QQSM3_OB_CHN_3.0.235_Green.rar HTTP/1.1
2025-01-16 00:49:38 Host: download.zygames.com
2025-01-16 00:49:38 Connection: close
2025-01-16 00:49:38 Accept: */*
2025-01-16 00:49:38 Range: bytes=4454149223-
2025-01-16 00:49:38 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
2025-01-16 00:49:38 HTTP/1.1 302 Found
2025-01-16 00:49:38 Cache-Control: private
2025-01-16 00:49:38 Content-Type: text/html; charset=utf-8
2025-01-16 00:49:38 Location: https://download1.zygames.com/qqsm/install_mars3/30235c786052b430b0dc8d98a43f11a6f4fe6/QQSM3_OB_CHN_3.0.235_Green.rar
2025-01-16 00:49:38 Server: Microsoft-IIS/7.5
2025-01-16 00:49:38 X-AspNet-Version: 4.0.30319
2025-01-16 00:49:38 X-Powered-By: ASP.NET
2025-01-16 00:49:38 Date: Wed, 15 Jan 2025 16:49:37 GMT
2025-01-16 00:49:38 Connection: close
2025-01-16 00:49:38 Content-Length: 234
2025-01-16 00:49:38 重定向到 https://download1.zygames.com/qqsm/install_mars3/30235c786052b430b0dc8d98a43f11a6f4fe6/QQSM3_OB_CHN_3.0.235_Green.rar
2025-01-16 00:49:38 开始连接download1.zygames.com:443...
2025-01-16 00:49:39 连接download1.zygames.com:443成功。
2025-01-16 00:49:39 GET /qqsm/install_mars3/30235c786052b430b0dc8d98a43f11a6f4fe6/QQSM3_OB_CHN_3.0.235_Green.rar HTTP/1.1
2025-01-16 00:49:39 Host: download1.zygames.com
2025-01-16 00:49:39 Connection: close
2025-01-16 00:49:39 Accept: */*
2025-01-16 00:49:39 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
2025-01-16 00:49:39 HTTP/1.1 200 OK
2025-01-16 00:49:39 Date: Wed, 15 Jan 2025 16:49:38 GMT
2025-01-16 00:49:39 Content-Type: application/x-rar-compressed
2025-01-16 00:49:39 Content-Length: 8908298447
2025-01-16 00:49:39 Connection: close
2025-01-16 00:49:39 Last-Modified: Fri, 20 Dec 2024 07:19:24 GMT
2025-01-16 00:49:39 ETag: "67651a7c-212f9d8cf"
2025-01-16 00:49:39 Cache-Control: max-age=604800
2025-01-16 00:49:39 Age: 262
2025-01-16 00:49:39 Ctl-Cache-Status: MISS from hb-wuhan9-ca20, HIT from jl-changchun10-ca22
2025-01-16 00:49:39 Request-Id: 38266787e7226f1ab1488d68d53ce5a7
2025-01-16 00:49:39 cache: dnion-slice-cache
2025-01-16 00:49:39 Server: DnionOS
2025-01-16 00:49:39 检测到服务器支持断点续传。
2025-01-16 00:49:39 开始读取数据...
除非服务器使用了transfer-encoding: chunked块传输，否则请求range: bytes=0-0一定会返回
content-range: bytes 0-0/8908298447
才发现这个命令行模式其实是可以连接DHT网络的
只是WEBUI里面还没有专门显示DHT的地方 只能从追踪器那一栏查看DHT
可以给优先 WEBUI加上GUI那样的状态栏以显示端口状况和DHT网络
话说这个后面的td是什么的缩写呢？
似乎从等待队列中分离出来了 现在请求完成的很快
建议将代理中的 “服务器” 改为IP地址 并添加
与上方服务器类型相似的提示 以说明其只支持IP而不支持域名以及主机名
（可以专门提一下localhost 它也算是个域名）
感谢反馈。Linux版的x64命令行版本bitcometd打包的是旧版，已重新上传 BitComet-2.12.1-x86_64.deb文件和docker仓库bitcomet-webui
感谢建议，下一版改进。在统计页面里有DHT节点数。
bitcometd 是 BitComet daemon 的缩写，意为单独的后台进程。windows和linux版都有，macOS版没做
感谢建议
1個讚
后台进程吗 daemon应该是守护进程吧 用来监控主进程的
但这个是完整的独立进程 基本的功能都有
并不能和之前的带图形界面的版本一起运行
也许改成-CLI会更好 表示命令行模式
与原有的GUI相对应 尽管现在还不能输入任何命令
是QQSM3_OB_CHN_3.0.235_Green.rar那个链接吧？我测试过可以100个连接同时下载。要不你右键菜单选重新下载试试呢
daemon确实是守护进程的意思。我是参照apache的httpd.exe起的名字，就当是守护webui服务吧
