详细的测试结果来了
比特彗星BT任务区块内存缓存有效期是多久过期
种子正在有速度传输数据时，130秒无人访问内存，就过期
种子无速度时，未连接到任何peer用户，持续保持当前已有的内存缓存，直到下一位来访者在开始丢弃这些过期的内存
测试长效上传时，是会正常过期缓存的（但是不知道缓存是多久，，，因为分布太分散了不方便观察）
长效1.95反馈 1.96新增的，发现有个问题。。。今天仔细看了下，长效下载的客户端居然不是顺序的，是和BT一样乱序的一个一个区块块进行下载，假设BT任务是512KB区块，那么长效下载就是每次下载512KB区块
我之前以为是顺序的12345678910这样顺序。。。。
所以现在的版本导致了长效上传做种方内存需求量增长很大，差不多要1:1文件大小的内存作为缓存，不过做种方长效上传，长效命中率基本为99.9%了
做种方占用4G内存
下载方进度只有10%，因为乱序请求导致了申请大量的16MB内存
一个5GB 512KB区块的BT任务，仅BT任务传输情况，做种方只要90MB的内存。仅长效上传需要4GB
所以2.0版本我们要做的，，，就是把长效上传缓存在改进一下，和BT任务的区块同步起来？HTTP任务在保留16MB的算法。
例如BT任务种子是512KB区块，那一次就是区512KB内存，，，等等，好像长效上传方并不知道对方下载的BT任务？而且是能跨A B多个种子互通的。。。脑壳痛，有没有什么高材生大佬支个招
下图为BT任务时候，可以观察到长效是随机取区块的
（明明是基于HTTP协议，原来长效下载速度有时候也很慢，，，原因是和BT任务一样512KB一个块这样传输）
要不然和上面说的，，，出个选项控制下长效最大服务人数，或者缓存时间缩短到10秒过期，还是等个大佬看看怎么解决吧
还是说2.0的长效上传，仅服务2.0及后续版本，方便和下载方客户端对接整合一些代码来实现同步区块缓存大小啥的，比如下载方通知上传服务端我当前正在用多大的区块下载
作为长效下载的时候，可以支持兼容以前版本
太小的区块下载速度又太慢，例如512KB区块下载速度只有500-1000K极限了，不适合现代网速，16MB区块刚好对应百兆网速，比较符合现今高速下载需求。但是这个客户端随机请求下载有点头疼。