opentracker的stats界面everything下udp字段missmatch是什么意思，transaction ID和Connection

小樱

opentracker的stats界面everything下udp字段missmatch是什么意思，transaction ID和Connection

代表tracker服务器正在被udp攻击，tracker程序返回错误代码

1. Connection ID missmatch.

复制代码

客户端没有根据bep协议标准提前发送Transaction Id申请的情况下，使用了一个虚假伪造的Connection Id直接与tracker通讯，此时tracker检测到信息不正确就会拒绝访问，每发生一次则missmatch显示数值+1

overall 请求总数
connect 则代表接收到的Transaction次数
announce 就很好理解了，甚至不需要解释
scrape 只获取peer数量，而不获取peer用户列表
missmatch 被攻击次数

missmatch 其实还有一种可能性，Connection过期，客户端需要重新打开进程以便发Transaction请求申请新的Connection才能正常连接tracker
最明显的表现在，tracker服务器重启后，客户端还在用老的Connection与服务器通讯导致无法连接，客户端应该判断下返回代码为Connection ID missmatch.就重新发Transaction请求申请新Connection

tracker服务器管理者也可以把udp改成http来避免这种现象，不然客户端一直重试发很大的udp announce包引起tracker服务器网卡中下行流量＞上行流量
当前客户端内置Connection过期刷新时间我不知道是多久，至少重启客户端进程就立即刷新了

帖子补充
比特彗星在v2.21 Beta5 已修正，按照qbittorrent那样每1分钟重新发送Transaction申请一个新的Connection，虽然不是按照我的想法来更新，但是也算是修复因为tracker服务器重启后返回missmatch的问题了
副作用就是tracker服务器要承担大量的id申请请求，服务器为了兼容utorrent和其它客户端不会删除任何已知Connection，那必定导致数据库积累数量越来越多
beta5是学qbittorrent那样每次请求都重新申请Connection，超过1分钟则重新申请新的，这样就怕tracker服务器压力变大，毕竟tracker服务器统计的到比特彗星的用户量是qbittorrent的十几倍，频繁生成新的Connection容易增加开销占用服务器内存和性能，这样已经开发出来了。。那Connection就这样吧