这个用户加速好像没用？我一台服务器下好后，任务列表不删除，另一台开始下载，，没收到那台服务器来的上传流量。
猜测估计是只有BT种子别人有相同的文件，从长效种子来那种才能来上传加速？
或者是因为和以前的比特彗星版本长效种子一样，有个间隔时间？下载完成后不能立即进行上传？
镜像地址功能倒是可以正常用，可以搜索到一大堆这个centos7的iso地址进行下载。
还有批量下载不能自己复制粘贴进去
并且批量下载的线程数都是1个，，手动添加明明是20个，这也是个毛病！(这个问题我知道了，，，批量下载里面的点开更多默认是1，，没有根据选项功能的数值设置，算个BUG吧)
而且有些下载地址，是支持断点续传的，IDM这些都能进行多线程下载，就提示这样了，，然后就不能多线程了
而且文件中途暂停或者出什么问题了，，，显示这个的话，进度就从0重新开始了！是下载地址服务器方面缺少什么回应头部吗
支持的例如：http://mirrors.huaweicloud.com/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1908.iso
http://mirrors.aliyun.com/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1908.iso
抓包对比看了下是少了Accept-Ranges: bytes头部，软件判定就不支持了，，，这个无所谓了，是网站管理员的话自己能加
GET /windows/kangle-3.5.18.1-x64.exe HTTP/1.1
Host: download.kangleweb.com
Connection: close
Accept: /
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Server: kangle/3.5.16
Date: Thu, 05 Dec 2019 22:08:31 GMT
Last-Modified: Mon, 18 Nov 2019 05:37:07 GMT
Content-Type: application/octet-stream
X-Cache: HIT from fs-20
Content-Length: 15893323
Connection: close
GET /centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1908.iso HTTP/1.1
Host: mirrors.huaweicloud.com
Connection: close
Accept: /
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Server: CloudWAF
Date: Mon, 09 Dec 2019 20:19:36 GMT
Content-Type: application/octet-stream
Content-Length: 4664066048
Connection: close
Set-Cookie: HWWAFSESID=c7f4d731a273006503; path=/
Set-Cookie: HWWAFSESTIME=1575922776460; path=/
Last-Modified: Wed, 11 Sep 2019 18:51:26 GMT
ETag: “5d79422e-116000000”
Accept-Ranges: bytes
GET /centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1908.iso HTTP/1.1
Host: mirrors.aliyun.com
Connection: close
Accept: /
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Server: Tengine
Content-Type: application/octet-stream
Content-Length: 4664066048
Connection: close
Date: Mon, 09 Dec 2019 20:27:22 GMT
Last-Modified: Wed, 11 Sep 2019 18:51:26 GMT
ETag: “5d79422e-116000000”
Expires: Mon, 09 Dec 2019 22:27:22 GMT
Cache-Control: max-age=7200
Via: cn1891.l1, cache13.cn1891, l2cn1828.l2, cache49.l2cn1828, osm-sh-ecs-1, cache49.l2cn1828[0,304-0,H], cache24.l2cn1828[4,0], vcache2.cn1892[144,200-0,H], vcache17.cn1892[190,0]
Accept-Ranges: bytes
Ali-Swift-Global-Savetime: 1571941598
Age: 29
X-Cache: HIT TCP_REFRESH_HIT dirn:1:285128692
X-Swift-SaveTime: Mon, 09 Dec 2019 20:27:51 GMT
X-Swift-CacheTime: 7171
Timing-Allow-Origin: *
EagleId: 249f61a515759232710702168e
谢谢反馈，问题已记录，后续修复。
之前是考虑到批量增加下载任务已经会创建多条连接了，每个任务连接数就默认为1了。现在新版批量下载对话框里的默认值已改为使用选项里的默认值。
HTTP协议如下：
The If-Range HTTP request header makes a range request conditional: if the condition is fulfilled, the range request will be issued and the server sends back a 206 Partial Content answer with the appropriate body. If the condition is not fulfilled, the full resource is sent back, with a 200 OK status.
This header can be used either with a Last-Modified validator, or with an ETag, but not with both.
The most common use case is to resume a download, to guarantee that the stored resource has not been modified since the last fragment has been received.
在单个请求中，Range头信息能够询问多个范围，这种特性称为"多部分范围（multipart ranges）"。请不要和分段下载（segmented downloading）混淆，几乎任何的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接（每个连接请求文档的不同范围）提高了下载速度。
多部分范围的想法并没有开启多个连接，但是他能够使客户端软件能够在单个请求/响应周期中请求某个文档的最前面的十个和最后面的十个字节。
这个Accept-Ranges: bytes无法多线程下载的问题记录了没，感觉是这两个东西搞混了，还是说现在代码就是检测断点续传的Accept-Ranges，没有的话，，多线程也不工作了
谢谢反馈，目前是判断服务器返回 Accept-Ranges: bytes 表明支持断点续传才进行多线程下载。
测试了一下，你给的服务器 download.kangleweb.com 是个特例，虽然没返回 Accept-Ranges，但也支持断点续传。下一版可以改进代码兼容这种情况。
还有这个线程，能不能考虑给大点，比如说128个！这样基本上可以扔掉IDM了，，
虽然IDM更高级一些还能让用户轻松支持自定义请求头部，cookie等等，，
当然现在比特彗星Chrome插件是坏的，，，下网盘是没戏了，会被防盗链拦截，cookie等等信息传递不到下载器上
好的，下一版上限从20改为200
暂时没功夫去弄
1.65新版已改进对http服务器断点续传的检测算法，欢迎试用
