实测有效，效果很不错，需要做种方升级为1.95 beta2版本，要是做种方为旧版本则不起效果还是为548的小包传输
下载方测试可以是任意版本的比特彗星。
不过下载接收方显示的MTU不准，，做种上传方的才准，抓包值为1457，可能这个地方显示的是本地对他人peer上传时候使用的MTU，那么双方显示不一致是正确的现象，可以改善语言界面一下，显示成 本地上传MTU = xxxx
不过还是有问题，速度跑不起来还是100多KB/s，调整到1457后最大的肉眼可见的改善就是UTP线程占用的CPU降低了。
统计里面观察都跑不到1000pkt，，感觉发的utp包不够激进，有没有办法在提高发包速率？
两台服务器用网络调试软件模拟UTP包重发，mtu设置548，测试30Mbps发送，接收方可以获取到30Mbps，可以确认不存在运营商QOS，应该是软件发的UTP包不够激进。
模拟测试200Mbps，也是正常的，CPU占用不高
而且UTP包能不能移出每秒UDP限制外面，不然做种几百个任务的时候容易引起UDP队列发送导致引起内存泄漏…或者弄个和DHT那样，达到限制后对外发出去的包就丢弃掉。因为看这个截图来说，mtu为548的情况，得需要5W的包才能承受200Mbps的速率。
mtu为1457的情况，只需要1.7W的包就能承受200Mbps的速率，UTP线程的CPU也降低到了1.5%。
1Gbps网卡承受能力为16W pps，等于说mtu为1457的情况200Mbps=1.7W，1000Mbps=8.5W，使用utp搓搓有余了。
等你下一个版本。。。改善下这个UTP上传不起来的情况。。感觉有点像前几年的tcp socket缓冲区一样的毛病，1.51版本优化过tcp socket缓冲区大小，估计也有个udp socket缓冲区吧
TCP是能跑200Mbps的。。虽然也还跑不满1Gbps，不知道是不是tcp缓冲区还是小了点。
目前版本 network.max_udp_pkt_per_sec 最大值10000，，，为了高速上传可能要改成100000，主要不知道上传UTP时候CPU占用情况怎么样，要等下一个版本出来后测试下才知道。因为比特彗星仅支持CPU单线程！不像网络调试工具，是可以利用所有CPU核心的。看来我前几个版本说的那个最完美的多线程方案还是太难实现了。。。