下载测速是否应当使用多线程？

[1265578519]

功能需求

对于多线程测速，可能需要用到的人比较少。可以先摆烂。。。遇到个感兴趣的大佬可以pr合并后发版

通过head获取文件大小，例子，先探测 -url 参数的下载地址是否支持多线程

curl -r 0-0 -i https://cdn.cloudflare.steamstatic.com/steam/apps/5952/movie_max.webm

可得知206状态响应，并且响应文件大小 Content-Range: bytes 0-0/17884993

此时可多线程测速，暴力多线程就是同时执行多条汇聚测速结果，不考虑对方网站消耗流量，测速一次可能超出文件大小几倍流量

curl -r 0- https://cdn.cloudflare.steamstatic.com/steam/apps/5952/movie_max.webm -o test

优雅点就是分割文件，例如默认四线程的情况，就砍4刀。判断17884993大于等于10M，每个线程启用2MB
此时多线程的四个请求分别为

curl -r 0-2097152 https://cdn.cloudflare.steamstatic.com/steam/apps/5952/movie_max.webm -o part1
curl -r 2097153-4194304 https://cdn.cloudflare.steamstatic.com/steam/apps/5952/movie_max.webm -o part2
curl -r 4194305-6291456 https://cdn.cloudflare.steamstatic.com/steam/apps/5952/movie_max.webm -o part3
curl -r 6291457- https://cdn.cloudflare.steamstatic.com/steam/apps/5952/movie_max.webm -o part4

合并文件，无需考虑，因为测速的话这些肯定不会写硬盘，也应该直接在内存中丢弃

cat part1 part2 part3 part4 >> test.out
md5sum test.out    #54b116d6f3d37039dac72c2e54bf89af，test.out与test结果一致

预期目标

下载测速是否应当使用多线程？以便得到最佳的测速结果，，，因为用途是用cf来反代去下载网盘文件，都是多线程的，测速结果和实际网盘下载时候的速度结果不一致。

[XIU2]

一般来说，单线程更能反映实际使用环境（及一般情况下大部分人都是单线程），而多线程更能反映最高速度。
或者说是，单线程决定速度下限，多线程决定速度上限。

不过该功能，我不是很感兴趣（用不上）。。。

[flower-elf]

我和楼上作者的想法其实是一样的
单线程更能反映你的实际使用环境，并且能够直观的体现出连接的质量
而且单线程的测速情况很多时候都比多线程要差得多，既然他很差，你可以使用多线程去弥补
但如果使用多线程来进行测速，测出来的结果是很好看，不过当你实际使用的时候，其实效果会非常的差。我想没有人愿意这样子的

一个最简单的例子，你多线程测出来的IP跑满了你的带宽，假设你的带宽是100Mbps
然后当你实际使用的时候，肯定会发现实际速度远远低于这个值。给人的心理落差完全不同
如果只使用单线程，测出来的结果是很差，但是当你实际使用的时候，往往不会说差到哪里去，甚至会更好（因为主流浏览器目前会在下载时尝试使用多线程，即使他需要手动开启）这个时候你心里头也会舒服一点

我宁愿一个东西测出来代表的是最差情况，而不是最好的情况，因为理想情况基本上是达不到的

[cwcpu]

希望可以多线程同时测多个IP地址，单个IP地址还是单线程

[wengzhenquan]

希望可以多线程同时测多个IP地址，单个IP地址还是单线程

希望可以多线程同时测多个IP地址，单个IP地址还是单线程

希望可以多线程同时测多个IP地址，单个IP地址还是单线程

别想了，这种测出来的网速完全没有参考意义。
你家里的带宽总量是固定的，分成两个下载任务后，两个下载任务都跑不满你宽带，下载测速不真实