beta6已上传，欢迎使用。大家新反馈的问题也会陆续处理
WebUI：修复HTTP + IP访问页面时，无法复制信息到系统剪贴板的问题
不起作用，可能打包错了，看webui.zip文件修改日期没有变化
局域网下beta6比beta4的utp快多了，虽然比其它BT软件还有不小差距，但是至少不是650KB/s了，beta6局域网下UTP可以达到12MB/s左右
应该还能改善下，比如说我一直让改的那个socket缓存，现在8M是针对单个连接还是最大值（虽然测试时候用的是单个peer连接）
然后就是tcp的socket当前缓存大小是多少？tcp我记得可以自动调整，但是比qbittorrent传给utorrent也差了10MB/s的速度
UDP 长效上传速率没什么变化，局域网下还是Beta5 的300KB/s，估计要从下载方更新了
beta6的utp可能是rtt延迟降速原因？现在降速阈值是多少延迟？是截图上显示的200ms吗？utorrent可以自定义到1000毫秒
net.utp_target_delay
net.utp_receive_target_delay
beta6传给qbittorrent倒是快了不少，有50MB/s了，之前beta版本是30MB/s左右，提升socket缓存的效果很明显
beta6用UTP传给utorrent你看看还能不能进一步提速到qbittorrent传给utorrent那样快，比如提升下rtt延迟降速的阈值到1000？
就是那个UTP那个延迟改一下，，如果是200ms的话那肯定不太合理，传输数据的时候，局域网都快100ms了，公网400ms的情况加上开销就是500ms了，感觉延迟降速设置1000ms比较合理
beta6 TCP 确实有大约10MB/s的差距
磁力分载点：magnet:?xt=urn:btih:HFMEWCZF72GKCNO4DKDKDTXTGGLTJRRK&xt=urn:btmh:12207ac1800780cc7ec792801461d69857ac9707a55f7e2e2e346d5454e1ca57c5d4&dn=BitComet%20V2.21%20Beta6%20%5B20260601%5D
是的，忘了打包最新版webui了，下一版修复
单个udp连接
目前没有专门设置TCP socket系统缓冲区大小，还是OS默认大小
其他问题晚一点看看
UTP的速度提上来是好事 不过发包量还是需要控制
不然还是会像DHT那样 为了保持网络不断流而而关闭功能
运营商限制的是tcp/udp连接数，也称作session、会话数等
不管传送多少内容，都是在同一个ip和端口内发生，不管传输多少数据，都是一个连接，只要ip地址和端口都没发生改变
可以A和B打流，用UTP协议模拟真实传输跑满千兆宽带都不会发生限制的，因为在同一个连接内发生
一张图看懂例子
DHT因为会对1000个个ip地址发请求，所以占用了比较多的连接数，一些运营商可能就限制了连接数，现在版本限制udp包每秒数量，或者禁止DHT是为了抑制请求新的ip地址速度
假设一个种子有1万个peer同伴在下载，那么也需要同时限制tcp的network.max_connecting_connections 来控制请求速度，不然依旧会被运营商限制连接数
https://bbs.itzmx.com/thread-110404-1-1.html
运营商方面 UDP的总发包量应该也是有限制的
多了估计就是直接丢包 当然也可能是只固定比例丢包
这个其实对网络的的影响不大
我倒是更担心这些UDP包会冲垮那些性能不足的路由器
或者处于路由模式下的光猫
十五年前光猫和千兆路由器的硬件承受能力为16W pps，只要mtu设置正确，搓搓有余了
如果是早期版本默认为548的情况下，小包转发会引起瓶颈，后来版本提升到了1457，现在最新的beta版本已经提到了1472，基本不会有硬件性能问题了
除非路由器刷机了，然后在路由器上面做了什么奇怪的操作，导致路由器运行的其它应用剥夺性能
就像他一样，在路由器上运行BT软件，那么路由器才会引发瓶颈
你永远也不会知道用户在用什么上网
有些人用 qb会断网 用ut会断网 甚至用迅雷都会断网
所以较为保守的默认值是必须的 尤其是在DHT还没有改的情况下
当然我们也可以继续关着DHT
而且utp不应作为一种主推功能 其应该只是在TCP无法建立时的一种补充
TCP开放需要自己拥有公网/外网IP，或者网管员开放内网映射给自己…否则不可能。而且UDP/UTP同样也会受内网限制…
也别高估运营商附带的设备性能，为了节约成本 ，往往附带的设备都是最低配置，仅仅能用而已…，不会给高性能配置。 当然 用户自己加钱另配除外。
如果是连接数问题的话那需要限制的就不是UDP发包量了
应该限制并发连接数 但是UDP没有并发连接数 也许可以改成现在同时通信的IP地址数量?/
现在UTP修的差不多了 主要是要把DHT的开销降下去
BC目前在关闭DHT 的情况下似乎还是会有少量DHT流量 不知道是不是bug
还差点，现在多个任务运行的话，强制为UTP的时候永远是0KB/s，估计和等待发起阻塞有关
统计里看到是接收的流量吧？关闭只能控制发送的流量，原理上没有任何技术可以禁用收到的流量
UTP的10秒超时控制还有点问题，经常控制不住，启用UTP后等待发起会越来越多
单任务测试就没问题，多个任务就出bug了，控制不住
只用tcp的话就没这个问题，可以正常控制在10秒超时，而且期间上传速度也正常达到50MB/s，不会因为等待发起导致无法上传
就是等待发起迁移到正在发起的速度特别慢，一秒就减少几个等待发起，正在发起是特别空闲的
关于UDP问题的一些看法
正如前面提到的，UDP问题主要在连接数上，而不是包率
※实际上在链路可靠的情况下，UDP开销比TCP低，同速率下uTP的包率是更低的
众所周知UDP在网络层是无连接的，但现代网关都支持连接跟踪（特别在NAT下必不可少），会为UDP通信赋予连接状态
连接跟踪表占用内存
但即使10万的活跃连接，基于Linux的连接跟踪也只占用35-45MiB，其他方案可能更低
现代路由器的硬件配置是完全可以满足10万级连接数的
但在实际场景中发现，很多固件（包括OpenWrt的默认值）对连接数的限制设得非常低，很多是 16834 (16K)
包括一些高端路由器，因为其硬件加速支持的流表可能正好是16K，且不希望软件参与
而时限方面，Linux内核默认值对UDP未响应的连接是30秒，已响应的是180秒
也就是说，假设对10000个端点发起连接，其中有5000个端点进行了响应的话，30秒内连接数会占用10000，30-180秒期间占用5000
通过网关监控开启和关闭DHT时的连接数推移，可以确认BC大部分连接数由DHT产生
BC的UDP通信中，uTP/UDP追踪器/UDP长效 的远程端点在单位时间内是有限的，但DHT端点却会随时间一直增长
除固件连接数上限的瓶颈外，另一个需要关注的是新连接对CPU的负荷
软件加速及部分硬件加速，需要在每个连接的第二个包之后才能生效
即使支持新连接首包的硬件加速，其流表也有上限，溢出部分由软件处理
未被加速的新连接首包必须经过完全的网络栈，需要CPU深度参与
BC目前UDP发起限制默认是每秒1000，若其中大部分是DHT发起的新连接，低端或老旧的路由器很可能处理不过来
综上，UDP问题在于单位时间内的连接数及新连接的激增，其中绝大部分来自DHT
※在活跃任务数量较多时，uTP/UDP长效 可能也会产生较多的连接，但这些是用户预期且可控的开销
首先需要确认的是目前对DHT节点是否有合适的老化或筛选机制
大家也发现，BC运行时DHT节点会一直增长，专家模式下可以看到其中包含长时间未进行通信的节点
1.历史节点是否会定时尝试通信（如DHT ping）
2.历史节点是否值得保留（理论上内存占用会一直增长）
另外，若有恶意用户发布大量DHT节点，BC是否有对应的防御机制？
※参考libtorrnet源码可以发现，LT对每个网段（IPv4为/24，IPv6为/64）仅保留一个节点
只要优选DHT节点，上面提到的UDP问题可以大幅改善
另外发现一个问题，每秒发起的UDP包限制适用于所有UDP通信
上面提到，uTP/UDP追踪器/UDP长效 产生的连接开销是合理的，并非积极限制的对象
特别是uTP与UDP长效在上传时需要较高的包率，目前受1000pkt/s的限制，只能提供约1400KB/s的速度
1個讚
上图是我网关的连接数推移，可以看到有一定间隔的激增
root@Oniicyan-OP:~# conntrack -L | grep -e 192.168.8.188 -e fc00::215:5dff:fe0a:8971 | wc -l
conntrack v1.4.8 (conntrack-tools): 10630 flow entries have been shown.
10322
root@Oniicyan-OP:~# conntrack -L | grep -e 192.168.8.188 -e fc00::215:5dff:fe0a:8971 | grep udp | wc -l
conntrack v1.4.8 (conntrack-tools): 10161 flow entries have been shown.
9714
以上是我在连接数激增时捕捉到的conntrack信息
192.168.8.188和fc00::215:5dff:fe0a:8971是我BC绑定的IP，无其他程序使用
网关10630个连接中，有10322个为BC
网关10161个连接中，有9714个为BC的UDP
截图这种峰值是已经优化过了的
这是优化后的效果，所以你可以看到每30分钟查询一次DHT把结果缓存到数据库中，在早期版本是每次下载任务实时查询一次DHT网络（或者达到单个任务的20分钟倒计时刷新期）
如果用的是2021年后发布优化DHT的版本，然后BT任务下载的时候去通过缓存获取peer结果，30分钟内不会产生DHT查询流量，这个过程可以加快获取用户列表
要解决就是别和1000个已知节点查询就好了。专家模式能看到比特彗星是记录1000个，可以减少点查询数量
libtorrent这个做法其实并不合理，会导致一些节点永远不可见，不如做随机从列表中挑选。保证能发现到每一个节点
比如比特彗星现在存储1000个DHT节点，可以从中随机挑选400个来连接，减少每30分钟定时查询时的数量
最好高级设置可自定义，可设置数值为8-1000，对于DHT而言查询最小值为8，在小的话就不推荐了
beta 7 已发布，欢迎试用