其实也微乎其微，私有种子用户群毕竟小，影响不算特别大，建立ipv6成功后会通过 bittorrent.peer_dual_ip 返回自身ipv4给对方
不过这个返回有个前提是建立成功，在成功之前不知道对方2个ip地址中的另一个ip地址，此时可能因为端口未打开引起建立失败无法进行交换ip信息
虽然同时汇报A和AAAA是最终解决办法，但是tracker服务器并不承认一个peerid拥有2个地址，甚至可能因为双次请求拉黑名单
这样就有了个更好的办法，既然能判断port_type 绿灯，那可以检查TCP端口打开情况，可以加个高级选项（对于私有种子tracker优先使用ipv4，默认值不启用），如果ipv4已打开，那么强制使用A来发起到私有tracker，ipv4毕竟人人都有，如果ipv4阻塞则保持现状
其实除了 NexusPHP，其它的 Tracker 都可以同时记录多个 IP。
不过我看不少 NPHP 也有支持同一个 PeerID 一个 v4 一个 v6 槽位的。
很可能有这个情况，我这里有1个种子最近被刷了近百G上传。
在专家模式下查看长效做种文件会发现每次下载都不完全。
一段时间后查看发现只下载其中几个文件并且下载量远大于文件。
附上种子
[傲娇零次元资源组]PIXY社动画合集_20150114194056.rar_免费高速下载|百度网盘-分享无限制 (baidu.com)
谢谢持续改进
这个挺正常的吧，因为做种者不止你一个，你发的这个种子有27个做种者，别人不一定从你这拿数据，也会从其它人那同时获取
被利用的可能性不是没有，但是难度很大无限接近于0，需要逆向工程破解客户端认证加密算法，推导出可用的cookie加密信息，和与长效tracker通讯的私有tcp协议，这时候就能在其它BT客户端上利用上长效种子
抓包看了一下，长效种子的数据结构比较单纯，但我也没有逆向的技术
不过我尝试把抓到的请求包复制到其他机器上发送请求，成功刷到了流量……
以下是我在路由器上运行一个简单的死循环命令时的情况
while :; do echo $HEX | xxd -r -p | ncat -u 192.168.8.188 61128; done
其中 $HEX 为我抓到的 UDP 长效请求的荷载
甚至不需要向长效服务器查询，只要知道对方是 BitComet 且端口能被连接
我上面的荷载是抓包获取到的，但如果有逆向技术，应该可以根据文件来生成合法的请求
至于文件是否完整，如何还原这些也不重要，因为产生流量的目的已经达到
这方法甚至不需要魔改客户端，随便一个终端就能刷起来
另外有一个地方需要改进
当开启代理并勾选 “将代理用于其他网络流量” 时，长效种子的发布地址会变成代理的 IP
这次抓包才发现，原来我的长效一直都没有在上传……
有几个步骤，从torrent文件中获得长效hash值
如果文件元数据中未包含hash，则发起磁力链接向长效tracker查询hash，如果服务器已记录对应的磁力链接与hash则返回结果，未找到则返回未支持字样，等待后续有人下载完成后客户端主动进行长效做种上传准备，执行完整性校验后获得hash上传给长效tracker服务器
把hash值发给长效tracker服务器查询数据库获得ip用户列表
客户端在通过cookie验证信息与另一方客户端进行通讯打通连接，对方实现长效上传
刷流量的前提是知道对方ip，也就是要通过长效tracker取得列表，这点你在抓包的时候手动做了，实现一种"重放攻击"
由于长效tracker是私有协议算法，一般来说没办法实现自动化查询，除非按键精灵之类直接拉起比特彗星客户端添加下载，然后在抓进程内存实现捕获
如果提前知道ip，由于你没办法自己创建一个请求数据包，依旧没办法进行其他文件连接，只能连接到"重放"数据包的那个文件
不过对于这种手动重放攻击，确实是能实现对某个文件某个特定ip刷流量，就是不知道这个cookie验证信息是否是临时的有效期多久了，是客户端算法得出的cookie，还是长效tracker下发获得的cookie
反正总体来说，只要个逆向工程厉害的，就可以把qb对接上比特彗星的长效种子这样，并不是无法被利用，只是难度很大，概率无限接近于0（逆向厉害还对BT网络感兴趣的概率）
测试了确实是这个选项勾上后，连接长效tracker服务器的时候会走代理，可以把长效tracker放在使用代理连接tracker里面，然后服务器记录了你代理的ip，，别人自然连不上你没打开端口的代理ip，你就没上传了
要解决被重放数据包刷流量，，，这个估计基本没有什么改善的可能，重新设计协议也不见得好使
真要说重放的话，，，抓个DNS查询数据包，也能无限重放，不是很好判断是不是正常流量
据说设计AEAD加密来传输数据包就可以防重放，具体也不是太了解
从我抓包到尝试重放，中间隔了有一个多小时，我担心的是请求中根本没有动态的鉴权
（就在发帖时，我又运行了一下，仍然可以请求）
还有一点没有确认，就是同一个请求是否会对所有长效源生效
如果是，那么下载一个热门文件，筛选 BitComet 用户信息，再检测对方端口的连通性，再抓一个请求不断发起就可以达到刷流目的
这过程不需要查询长效服务器，也就不需要破解通信协议，难度就降低很多
若能从文件中生成合法请求，那甚至不需要依赖 BitComet
如果上面提到的报告确实的话，这个可能已经被恶意用户搞起了
编辑：
另外开了个虚拟机测试，连公网都没有连接，完全脱离了长效服务器
只要 BitComet 给文件添加到长效，就能用同一份请求刷出流量，基本确认是没有鉴权的
我寻思都这样了，，，别人其实也不会特别利用长效上传吧，代码中本来就写死了优先BT网络上传，长效会降低优先级和自动限速
而且长效主要是不启用任务也能实现上传，并且跨种子已文件形式，直接看BT网络的用户列表结果不一定会被找到ip和端口
试试tcp方式呢，就目前这个udp长效，局域网都几十传不动，刷流量的人可能都看不上眼
tcp是建立在http上实现的，所以速度巨快，我之前看过是明确要求cookie头才能连接的
这速度是因为我是在路由器上用 while 循环执行 ncat，写个程序跑应该可以提升效率
TCP 我没抓到，因为发布了我的代理 IP 上去，握手阶段就失败了
不过比起自己测试，还是直接让开发者来看看好了，毕竟他才是最了解的
（主要是因为懒）
我也不确定现阶段有没有被恶意利用，连我自己长效一直没上传都没察觉到
不过就算有，应该规模也不大
但无论如何这也是一个隐患，还是希望尽早应对
毕竟当初设计长效种子协议的时候，肯定也没想到现在这种情况
感谢回复
是这样的吗。因为半年前下载好后一直没什么上传流量，直到上个月才有上传并且那几天都是固定的时间段上传差不多1个总大小数据量。所以想看看是啥情况。
确实显示了 连接中、未连接、已封禁 的 peer
但是似乎有个很严重的问题，已连接 的 peer 是不是弄丢了……
目前 BitComet 2.10 正式版预览 并不能使用 PeerBanHelper
除了上述丢失 已连接 peer 信息外，PBH 目前版本可能未适配新增的 连接中、未连接、已封禁 peer
我看了一下，已连接的 Peers 是在的，但是因为 API 更改了，所以没有做适配（针对 PBH 的问题，请避免在 CometBBS 上反馈，占用 BitComet 宝贵的支持资源）。
WebUI 的网页从这个版本开始显著变卡，我现在一点开用户，整个页面都会陷入无响应的情况。
浏览器可能撑不住那么多的 DOM 节点，最好是虚拟列表。
1個讚
等个Linux版本和docker更新，不然没办法下载超过4G的文件
旧版本webgui没性能问题吧，等待连接列表支持失败自动删除的，一般情况下不会特别多
这个是 disconnected 的。
旧版（上个版本）没问题
虽然我指的是原来那套webgui。。
