search

Simple-Tracker / qBittorrent-ClientBlocker

一款适用于 qBittorrent/Transmission (Beta)/BitComet (Beta, Partial) 的客户端屏蔽器, 默认屏蔽包括但不限于迅雷等客户端. A client blocker compatible with qBittorrent/Transmission (Beta)/BitComet (Beta, Partial) which is prohibited to include but not limited to clients such as Xunlei.
MIT License
840 stars 20 forks source link

疑似因进度0%，增强自动屏蔽误杀peer #47

Open shelfofclub opened 4 months ago

shelfofclub commented 4 months ago

目前只是疑似，欢迎大家一起讨论！ 目前只是疑似，欢迎大家一起讨论！ 目前只是疑似，欢迎大家一起讨论！

今天第一次使用，就看到屏蔽日志里出现：

[2024-03-31 16:20:17][CheckPeer_AddBlockPeer (Bad-Progress_Uploaded)] 2408:8240:XXXX ""|"qBittorrent 4.6.4" (TorrentInfoHash: XXX, TorrentTotalSize: 667.11 MB, Progress: 0.00%, Uploaded: 30.66 MB).

一方面是正常的客户端名，另一方面当时上传速度并不高。如果是出现最近dt开头那种的，至少上传速度有1MiB/S以上。所以我认为不是异常peer。

猜测出现这种情况的原因会不会是：某些原因导致peer进度获取出错，既然进度为0，无论如何都会被禁。例如，之前上传了30+M，连接中断了，再次建立连接，但还没建立好的时候，会不会获取信息出错？我不了解qb的情况，只是大胆猜测一下。

环境： win 10 64-bit qb v4.3.7 64-bit qBittorrent-ClientBlocker 3.1b3 qBittorrent-ClientBlocker config:

{
    "debug": false,
    "interval": 6,
    "cleanInterval": 3600,
    "banTime": 86400,
    "timeout": 6,
    "logPath": "logs",
    "logToFile": true,
    "qBURL": "",
    "qBUsername": "",
    "qBPassword": "",
    "skipCertVerification": false,
    "blockList": [
        "^-(SD|XF|QD|BN|DL)(\\d+)-",
        "^-XL(\\d+)-", "((^(Xunlei)? *?\\d+\\.\\d+\\.\\d+\\.\\d+)|cacao_torrent)",
        "anacrolix[ /]torrent v?([0-1]\\.(([0-9]|[0-4][0-9]|[0-5][0-2])\\.[0-9]+|(53\\.[0-2]( |$)))|unknown)",
        "^-DT", "dt[ /]torrent",
        "trafficConsume",
        "go[ \\.]torrent",
        "Taipei-Torrent dev"
    ],
    "_blockList": [ // 可选 blockList, 合并以屏蔽媒体播放器.
        "^-(UW\\w{4}-", // uTorrent Web.
        "^-SP(([0-2]\\d{3})|(3[0-5]\\d{2})))-", "StellarPlayer", // 恒星播放器.
        "dandanplay" // 弹弹 Play.
    ],
    "ipUploadedCheck": true,
    "ipUpCheckIncrementMB": 0,
    "banByProgressUploaded": false
}

禁用ipUpCheckIncrementMB是感觉默认数值在跑满千兆的情况下似乎会禁掉peer。

Simple-Tracker commented 4 months ago

感谢反馈!

参考: https://github.com/Simple-Tracker/qBittorrent-ClientBlocker/pull/45#issuecomment-2020127010

banByPUStartMB | 10 (MB) | 增强自动屏蔽/起始大小. 若客户端上传量大于起始大小, 则允许屏蔽 Peer
banByPUStartPrecent | 2 (%) | 增强自动屏蔽/起始进度. 若客户端上传进度大于设置起始进度, 则允许屏蔽 Peer
banByPUAntiErrorRatio | 5 (X) | 增强自动屏蔽/滞后防误判倍率. 若 Peer 报告下载进度与设置倍率及 Torrent 大小之乘积得到之下载量 比 客户端上传量 还低, 则允许屏蔽 Peer

所以这个客户端很明显满足了这些条件, 此处的起始进度换算成的体积是 667.11 * 0.02 = 13.3422MB, 而 banByPUAntiErrorRatio 则由于客户端是 0 进度而和 0 倍率无异.

以 2MB/s 上传来看, 15 秒仍然不回报进度, 即使它顶着一个正常客户端的名称, 我们也不认为这是合理的行为. 因对端侧出现的问题导致的持续吸血也应属于对端自行解决的问题, 屏蔽器在保护我们用户的基础上尽可能的避免这些问题. 但是对于高速上传 (>= 5MB/s) 的小体积种子, banByPUStartMB /banByPUStartPrecent 是否过低, 仍然是一个问题.

另: ipUpCheckIncrementMB 设计为千兆上行持续跑满, 若要禁用设置为 0 是错误的, 应禁用 ipUploadedCheck.

shelfofclub commented 4 months ago

@Simple-Tracker 从数据上看，确实是违反了判定条件。只是如果进度0%的数据是错误的呢？也许是如果链接还没建立好，导致进度默认为0？这可能不是屏蔽器的问题，而是qb的问题。 有时候会观察到用户列表里，一个peer一闪而过，并且对TA具有一些上传量。 所以，感觉这个事情可能会很麻烦。不好判断这些一闪而过的家伙。

ipUpCheckIncrementMB 设计为千兆上行持续跑满, 若要禁用设置为 0 是错误的, 应禁用 ipUploadedCheck.

我想同时保留ipUpCheckPerTorrentRatio的功能，所以这样设置。看了下代码，每次判断ipUpCheckIncrementMB的条件时，都会看是否大于0。所以把它设置为0了

Simple-Tracker commented 4 months ago

ipUpCheckPerTorrentRatio

那就这么用吧! 我们以后可以把这个纳入考虑, 一闪而过的家伙如果介意的话可以提高 StartMB 去判断, 如果想接近关闭就把 banByPUStartPrecent 设置为 100% 即可.

JockeyWang commented 4 months ago

目前我使用的config.json，更新到3.0版本后（同时QBEE更新到4.6.4.10）发现屏蔽的peer明显增多，不知道是否正常。 还有我一直建议能否将百分比精确到千分位，我已经注意到有些大种子（数个到数十个G）即使等待1%也是非常要命的。 还有个问题，我发现即使这样配置，也经常遇到一个8G的种子，在跑了1-2G及以上的流量才会被封禁。

{
  "debug": false,
  "interval": 3,
  "cleanInterval": 3600,
  "banTime": 86400,
  "sleepTime": 10,
  "timeout": 6,
  "longConnection": true,
  "logPath": "logs",
  "logToFile": true,
  "logDebug": false,
  "qBURL": "",
  "qBUsername": "",
  "qBPassword": "",
  "skipCertVerification": false,
  "banByProgressUploaded": true,
  "banByPUStartMB": 32,
  "banByPUStartPrecent": 1,
  "banByPUAntiErrorRatio": 2,
  "banByRelativeProgressUploaded": true,
  "banByRelativePUStartMB": 32,
  "banByRelativePUStartPrecent": 1,
  "banByRelativePUAntiErrorRatio": 2,
  "blockList": [
    "-(XL|SD|XF|QD|BN|DL|DT)(\\d+)-",
    "((^(xunlei)? *?\\d+\\.\\d+\\.\\d+\\.\\d+)|cacao_torrent)",
    "anacrolix[ /]torrent v?([0-1]\\.(([0-9]|[0-4][0-9]|[0-5][0-2])\\.[0-9]+|(53\\.[0-2]( |$)))|unknown)",
    "dt[ /]torrent",
    "trafficconsume",
    "go[ \\.]torrent",
    "Taipei-Torrent dev"
  ]
}
shelfofclub commented 4 months ago

关于进度0%的情况补充：

在PT种子中，正好看到一个peer，使用ut 2.0.4，链接是BT，标志是U I E，刚开始下载。向TA上传的速度很快，20+MiB/s。但十几二十秒后，TA汇报的进度从0增长到非0。这种情况如果发生在BT中，恐怕也会触发条件，被禁。

个人感觉对于这种情况和一闪而过的情况，增强自动屏蔽可能无法做到完美。还是期待一下“增强自动屏蔽_相对”功能的修复，用相对的流量变化应该好过用一个时刻的流量情况。

shelfofclub commented 4 months ago

还有我一直建议能否将百分比精确到千分位，我已经注意到有些大种子（数个到数十个G）即使等待1%也是非常要命的。

@JockeyWang 从代码看似乎把这个整数参数改成浮点数，就能随意调节大小了。你问问作者看看吧

Simple-Tracker commented 4 months ago

增强自动屏蔽_相对

绝对流量变化相对更简单易用, 且因为无状态的原因不占用资源.
它通过 StartMB 得到起始大小 1 (并由于上传速度关联间接得到起始时间).
通过 StartPrecent 与 Torrent 关联得到起始大小 2.
满足起始大小 1 和起始大小 2 后满足 AntiErrorRatio (若 Peer 报告下载进度与设置倍率及 Torrent 大小之乘积得到之下载量 比 客户端上传量 还低).
即启用.

相对流量变化相对更复杂, 它通过存储 Torrent Map 并等待一段时间进行相对检查, 这会消耗一定的资源.
StartMB 仍然是起始大小 1, 只不过变成了一个周期的起始大小 1.
而 StartPrecent 则是上传进度变化的百分比, 此时和 Torrent 的体积无关, 比较的是实际上传进度和对端报告进度的差异.
AntiErrorRatio 同上.
该功能在 3.1 版本中应该是可用的 (但不知有无 bug).

Simple-Tracker commented 4 months ago

目前我使用的config.json，更新到3.0版本后（同时QBEE更新到4.6.4.10）发现屏蔽的peer明显增多，不知道是否正常。 还有我一直建议能否将百分比精确到千分位，我已经注意到有些大种子（数个到数十个G）即使等待1%也是非常要命的。 还有个问题，我发现即使这样配置，也经常遇到一个8G的种子，在跑了1-2G及以上的流量才会被封禁。

...

可能可以观察一下一个周期的所需时间. 另外 3.0 版本中的相对进度屏蔽是被确认有 bug 的, 但目前没有已知报告证实它影响了屏蔽 (而且以前版本也一直都有这个 bug). 3.1 版本会在一些情况跳过 sleepTime, 进而改善一个周期所需时间.
但若是小于 1%, 则对于较小的 Torrent 来说可能是比较灾难的, 例如: 100MB 种子的 1% 仅仅只有 1MB. 所以默认设置是一个比较折中的设置, 在 100MB/1GB/10GB 中取了 1GB 的折中.
不过下一版本应该会允许更宽泛的设置.

此 Nightly Build (https://github.com/Simple-Tracker/qBittorrent-ClientBlocker/actions/runs/8504052439) 已作调整:

  1. 默认 StartMB 从 10MB 改为 20MB, 默认 AntiErrorRatio 从 5 改为 3;
  2. IPUpCheckPerTorrentRatio/BanByPUStartPrecent/BanByPUAntiErrorRatio/BanByRelativePUStartPrecent/BanByRelativePUAntiErrorRatio 均支持使用浮点数;
JockeyWang commented 4 months ago

目前我使用的config.json，更新到3.0版本后（同时QBEE更新到4.6.4.10）发现屏蔽的peer明显增多，不知道是否正常。 还有我一直建议能否将百分比精确到千分位，我已经注意到有些大种子（数个到数十个G）即使等待1%也是非常要命的。 还有个问题，我发现即使这样配置，也经常遇到一个8G的种子，在跑了1-2G及以上的流量才会被封禁。 ...

可能可以观察一下一个周期的所需时间. 另外 3.0 版本中的相对进度屏蔽是被确认有 bug 的, 但目前没有已知报告证实它影响了屏蔽 (而且以前版本也一直都有这个 bug). 3.1 版本会在一些情况跳过 sleepTime, 进而改善一个周期所需时间. 但若是小于 1%, 则对于较小的 Torrent 来说可能是比较灾难的, 例如: 100MB 种子的 1% 仅仅只有 1MB. 所以默认设置是一个比较折中的设置, 在 100MB/1GB/10GB 中取了 1GB 的折中. 不过下一版本应该会允许更宽泛的设置.

此 Nightly Build (https://github.com/Simple-Tracker/qBittorrent-ClientBlocker/actions/runs/8504052439) 已作调整:

  1. 默认 StartMB 从 10MB 改为 20MB, 默认 AntiErrorRatio 从 5 改为 3;
  2. IPUpCheckPerTorrentRatio/BanByPUStartPrecent/BanByPUAntiErrorRatio/BanByRelativePUStartPrecent/BanByRelativePUAntiErrorRatio 均支持使用浮点数;

好的，这个改动很不错。我个人参数调优的时候，觉得还是可以用一个较大的StartMB和一个严格的AntiErrorRatio比较合适。 我这边做种的小种子毕竟是少数，相对而言那堆几个G的种子一旦封的慢了，造成的影响会大得多。

Simple-Tracker commented 3 months ago

3.2b12 参照其它项目 (Ghost-chu/PeerBanHelper), 加入了下载速度及上传速度判断, 希望尽可能避免无效 Peer 信息.

Burgess-T commented 3 months ago

也遇到了这个问题，我的表现为：

[2024-04-13 21:49:06][CheckPeer_AddBlockPeer (Bad-Progress_Uploaded)] xxxx.247:15110 "-qB4400-"|"qBittorrent 4.4.0" (TorrentInfoHash: xxx, TorrentTotalSize: 35240.14 MB, Progress: 0.00%, Uploaded: 1112.08 MB).

由于上传速度不高，因此这1G的上传至少需要一个小时才能达到，意味着在一小时内这个用户的进度汇报都是正常的。猜测可能是对方重新下载导致进度归零，于是解封再次查看，发现进度正常： image 因此我认为这个是由于网络连接问题导致的进度归零，在连接恢复正常后即可回到正常进度。 另外，在下载冷门且较大的种子时这个问题会影响下载：由于下载速度慢，因此这类种子需要很长的下载时间，在这期间很可能有网络波动；且需要同样在下载的用户提供上传，误封会导致下载速度大幅减小。 能否添加下面两种判断方式：

  1. 当我方正从对方下载或已从对方下载指定大小，不会将对方封禁。（防止影响下载）
  2. 设置重复检测，例如：当对方连续两次都满足封禁要求时才将对方封禁。（防止网络波动影响）

qBittorrent-ClientBlocker 3.2b8 config:

    "banByProgressUploaded": true,
    "banByPUStartMB": 20,
    "banByPUStartPrecent": 2,
    "banByPUAntiErrorRatio": 3,
    "banByRelativeProgressUploaded": true,
    "banByRelativePUStartMB": 20,
    "banByRelativePUStartPrecent": 2,
    "banByRelativePUAntiErrorRatio": 3
Simple-Tracker commented 3 months ago

也遇到了这个问题，我的表现为：

[2024-04-13 21:49:06][CheckPeer_AddBlockPeer (Bad-Progress_Uploaded)] xxxx.247:15110 "-qB4400-"|"qBittorrent 4.4.0" (TorrentInfoHash: xxx, TorrentTotalSize: 35240.14 MB, Progress: 0.00%, Uploaded: 1112.08 MB).

由于上传速度不高，因此这1G的上传至少需要一个小时才能达到，意味着在一小时内这个用户的进度汇报都是正常的。猜测可能是对方重新下载导致进度归零，于是解封再次查看，发现进度正常： image 因此我认为这个是由于网络连接问题导致的进度归零，在连接恢复正常后即可回到正常进度。 另外，在下载冷门且较大的种子时这个问题会影响下载：由于下载速度慢，因此这类种子需要很长的下载时间，在这期间很可能有网络波动；且需要同样在下载的用户提供上传，误封会导致下载速度大幅减小。 能否添加下面两种判断方式：

  1. 当我方正从对方下载或已从对方下载指定大小，不会将对方封禁。（防止影响下载）
  2. 设置重复检测，例如：当对方连续两次都满足封禁要求时才将对方封禁。（防止网络波动影响）

qBittorrent-ClientBlocker 3.2b8 config:

    "banByProgressUploaded": true,
    "banByPUStartMB": 20,
    "banByPUStartPrecent": 2,
    "banByPUAntiErrorRatio": 3,
    "banByRelativeProgressUploaded": true,
    "banByRelativePUStartMB": 20,
    "banByRelativePUStartPrecent": 2,
    "banByRelativePUAntiErrorRatio": 3

就网络波动影响, 在 3.2 后期 Beta 中, 跟随同类项目加入了下载速度及上传速度检测, 若任意不为 0, 才允许进行封禁. 正从对方下载时不封禁: 合理的考虑, 将在下个版本加入. 已在上述实现, 因下载速度不为 0. 已从对方下载指定大小: 这可能会转变为一个设置项加入, 具体大小用户可选择, 默认计划为 100MB. 重复检测的问题是: 状态依赖意味着程序处理有一定开销且比较麻烦.

Simple-Tracker commented 3 months ago

就上述内容, 可测试 Nightly Build https://github.com/Simple-Tracker/qBittorrent-ClientBlocker/actions/runs/8678506537, 新增 IgnoreByDownloaded 选项.

L4cache commented 3 months ago

如果以上传量对种子体积的百分比与 peer 进度增量为依据呢？ 开销会增加，但是对用户来说多一个选项不会是坏事，用户自己根据需求以及硬件条件选择就行了，而且这种程度的开销影响到底有多大呢？

Simple-Tracker commented 3 months ago

如果以上传量对种子体积的百分比与 peer 进度增量为依据呢？ 开销会增加，但是对用户来说多一个选项不会是坏事，用户自己根据需求以及硬件条件选择就行了，而且这种程度的开销影响到底有多大呢？

开销无所谓, 问题是比较麻烦... 无状态改有状态意味着要改变许多内容, 这很困难. 而且, 你完全可以假设网络波动也可以有两个 Interval 那么长, 特别是 Interval 很短的情况下. 不过, 若是有人愿意帮助我们实现, 那我们很乐意(在保留原有功能的基础上)为用户增加一个全新的选项!