uTP 的异常占用展现出一定的周期性，以下截图监测大约 20 分钟
但 WebUI 的响应问题跟 uTP 的异常占用似乎没有关系
我这边也打开摘要和用户列表页面监测，但没能复现
可能第三方程序短时间内重复查询才会触发？
两码事，utp是在工作线程运行的，不在主线程上面，不知道怎么讨论起utp来了，，不过utp确实是需要解决的问题，更重要的是传输速度，其次是CPU消耗吃满一个核心
webgui切换用户列表试试，这时候会发起的api目的地址不同，你截图看起来是在主界面待机
截图时是主界面，后面另外开了摘要和用户列表
结果是一样的，所以没有另外截图
监测时自动刷新的请求地址分别是
http://127.0.0.1:8414/api/task/summary/get
http://127.0.0.1:8414/api_v2/task_list/get
http://127.0.0.1:8414/api/task/peers/get
说起来这路径有 /api 也有 /api_v2，是不是该统一一下
uTP 问题跟 WebUI 的响应问题无关的话，确实可以先不管
毕竟也不是一朝一夕的问题了，也不是不能用
我这出现的性能消耗是在浏览器gzip解码上？在浏览器上直接访问看看延迟，因为我观察到CPU占用巨大，浏览器解压缩耗费时间长，可以让官方给webgui加zstd压缩试试，速度巨快，cpu性能是gzip的3倍
用插件删了accept-encoding请求头，获取响应未压缩的数据就快了0.1-0.2秒左右，可以说忽略不计了，依旧是1秒多出结果
占用还是比较高，视乎是浏览器收到数据后界面自动排序录入数据还是怎么的
还是比特彗星主线程在查询数据就花了1秒，然后才发给浏览器
因为原版的api也是要1秒这样，可以表明不是新版api引起的响应慢，CPU占用3%左右，当前运行500个做种任务
| Overall Tasks: | Total: 502 / Running: 502 |
|---|---|
| Long-Term Seeding: | 850 files ready for seeding |
http://127.0.0.1:1235/panel/task_list
多半也是这个原因导致了比特彗星整个主界面卡，主界面等待接收数据然后显示到表格里，因为延迟高然后就界面未响应了，统计里面显示的少点文件数就没事，文件数超过10w就卡卡的，现在1秒卡顿还能接受
你几乎不用在意 gzip 的开销，现代计算机，哪怕是树莓派，都能毫无压力的轻松解压缩 gzip
说回 utp 的问题，我观察到 utp_service 这个线程相当可疑。我不太会用调试器，但从线程的情况看，感觉飞这么高像是在低效的拷贝数据。
1個讚
是的，之前对uTP做过profile，需要把udp的小数据包拼成大数据块，做了很多内存操作。后续可以考虑更换数据结构，实现高效数据处理。uTP一开始是奔着实现基本功能去做的，没花太多精力去优化
2個讚
@wxhere15
这个basic验证能加吗？ 现在可以手动抓令牌 但是不知道这个令牌什么时候会失效
其实是想实现和qb这样类似的操作逻辑
Win上的UI也可以加一下手动屏蔽的功能
手动屏蔽地址和订阅地址相互分开
用户可以在编辑框中任意的添加新IP和删除已有的IP
手动添加的和通过规则订阅的互不干扰
通过api创建任务时, 建议可以传自定义的目录.
目前传 候选下载目录 以外的值会报错save_folder invalid, 这样限制不太友好. 一般只要是目录存在的, 就应该允许创建.
现在通过命令行和api下载的文件, 都是不能传自定义的目录, 这样堆在一起, 后期管理起来太麻烦.
目前版本用旧的webgui的api可以传递下载目录
在优化界面响应慢的要1秒甚至无响应性能问题吗，说不定api慢也同样解决了
IP过滤器封禁的peer在将其IP从IP过滤器中移除后，并不会自动解封因IP过滤器命中而封禁的对应IP。
是否能考虑优化一下这个（将IP从过滤器移除后解封有关IP），因为从WebUI添加黑名单IP后，就算将其删除，也无法解封被封禁的IP了，除非前往GUI手动解封。
这个之前有提过，可以加个取消拦截的api，post对应的ip来解封
包括post指定ip进入标记为用户手动封禁黑名单
1個讚
请求添加 arm64 docker 版本发布
老大 给出个arm64 的docker吧
IP 过滤器是否适用于长效做种？
有报告称恶意刷流已经把魔爪伸到 BitComet 的长效种子了（未确认，可能是同一出口 IP 下的正常用户）
长效做种不是 BitComet 的私有协议吗？
那个报告能看一眼吗
这个ip过滤器仅限BT协议，对web seed，long seed都不会起效果的
长效种子支持tcp10线程+udp1线程，一个ip出现11个连接是正常现象
我也是从 QQ 群的聊天记录中看到的，并没有详细信息
初步猜测是被误封的公共 IP 通过长效种子连上资源
主要是想确认一下长效种子有没有被利用的可能性
如果有，是否需要考虑把 IP 过滤器应用到长效种子中
关于 IPv4/IPv6 双栈 Tracker 的问题
发现 BitComet 在 announce 时，对于双栈 Tracker，会跟随操作系统的前缀策略使用 IPv4 或 IPv6
通常 Tracker 根据请求的源地址来确定 Peer 的 IP，这导致 BitComet 只能提交 IPv4 或 IPv6 二选一的地址
对于常规种子，用户可以添加包含仅 IPv4 与 仅 IPv6 的自定义 Tracker 列表来避免这个问题
而对于只能同时请求一个 Tracker 的私有种子，则可能影响连通性
可参考 Tixati 的双栈模式
不建议参考 qBittorrent 用所有地址去请求一次的做法
若其中包含无 Internet 访问权限的地址，会导致响应问题
另外发现 BitComet 在 announce 的时候会带上 natmapped localip port_type 的查询参数
大多数 Tracker 实现应该不支持此参数，是否必要
平均一个 announce 请求约 450B，而这 3 个查询参数约 30B 的额外开销
同一个peeridkey（每次重启客户端发生改变），私有种子会被重写覆盖ip，意义不大，比如说请求两次，第一次ipv4，第二次ipv6，那么会被ipv6覆盖掉ipv4，登录pt网站看到的ip地址为ipv6，ipv4已经被覆盖删除，至少目前的pt服务端程序都是这么做的。
现在根据系统api调度还是比较合理的，Windows系统的api做法是优先使用ipv6，目前的问题是因为服务器ipv6故障，导致的访问失败后，不会使用ipv4去重试，永远在第一个Addresses上发起，应该和浏览器一样，如果30秒访问失败还是怎么的，会自动转成ipv4访问站点，不过感觉故障失败设计起来比较麻烦还不如直接A和AAAA汇报两次。。。
port_type字符串表面了是否绿灯
natmapped这个应该废弃了，bep规范上面都没有写，本地ip为公网ip与对外ip相同的情况，经过测试值也始终是1，没有出现其它值情况
localip通过系统api取本地网卡ipv4，一般用于学校私有tracker中（强制禁用LSD），所有人出口ip相同，需要通过汇报字符串判断内网ip，不过目前确实没见到有任何公共tracker和私有tracker在使用，都是取与服务器通讯建立tcp握手ip
不过像这样，直接把tracker搭建在内网服务器上，用内网ip形式访问也能正确取得握手ip为内网ip，，，所以这参数也没多大用了，除非pt tracker服务器在公网阿里云上，要服务校内所有人才需要这种参数
总结port_type和localip可以没用，但是不能没有，占用不了什么流量，natmapped感觉可以删除，主要开销还是服务器响应的用户列表数据，不过通过zstd压缩后也没多少回包流量了，虽然压缩率不高但是还是有压缩率的