|
在一个风和日丽的清晨，灵儿惬意地漂浮在wifi森林里。突然遭遇老板夺命连环call：灵儿！！网络怎么这么差，speedtest测出来上行差异怎么这么大！灵儿立马祭出speedtest测试：上行测速比下行测速低了如此之多，上下行严重不对等，为弄清背后的真相，爱做实验的灵儿决定一探真相。
在单流终端使用Speedtest测试下行37M上行16M的时候，灵儿用有线测试结果为下行40M上行15M。而与此同时，利用IXIA模拟Speedtest特性进行内网打流测试可达到上行58M下行58M，足以支撑测速所需带宽。
因此，排除掉无线环境对此问题的影响。灵儿心里暗暗的舒了一口气，不会被老板责罚无线环境被破坏了，但真相大白之前还是得继续实验。 受生命之泉限制（出口），无线网络能提供的可用带宽是受限的，那么会是受限于生命之泉所产生的现象吗？于是，灵儿长涉险来到独享生命之泉的暗巫师家继续实验（暗巫师独享出口带宽，灵儿好生羡慕~）。
使用Speedtest问题依然出现，下行48M时上行只有可怜兮兮的4M，而此时使用另一专业工具 iperf 测试，上行可以打满到50M。因此，可以得出结论问题受限于Speedtest本身。 真相浮出水平 问题开始变得清晰，于是灵儿一口气做了下面几个实验 (1) 相同服务器，不同的时间进行测速
(2) 相同时间点，不同测速服务器
综合来看，数据包大小和线程数直接影响到了测速结果，而决定使用多大的数据包和多少线程数则由网络坏境决定。跟踪两个服务器路由能大致看出网络情况。
Speedtest官方（Speedtest.net）对此的说明大致为：TCP测试模型下，根据预测试评估协商出实测阶段所使用的数据包大小和线程数，在此基础上完成测试；另一种传统Http测试模型，由于上行数据包大小不会随测试而改变，将更容易受到预测试评估影响，形成上行测速弱于下行测速的情况。
No1. Speedtest测速结果受限于线程数和包大小。根据预测试评估结论而来，比如灵儿生活的wifi森林在忙时和闲时线程数差了一倍。 No2.Speedtest用于测试无线极限性能并不妥当。理由正如灵儿上面所述。 No3.Speedtest对于体验的参考意义在于能够大致表征出整体链路的情况，如果Speedtest测出来的结果可以支撑相关应用（具体的指标Speedtest官方文档有说明，灵儿就不啰嗦了），那么，就一定没问题。如果测试结果不理想时，不妨试试其他的测速软件。 (1) 选择出口对应运营商最近测速服务器进行测试 跨运营商或者长路由链路带来的时延会影响Speedtest对链路质量的评估，进而影响到测速结果。 (2) 避开出口链路拥塞进行测试 出口链路拥塞影响协商报文大小及线程数，单窗口测速结果不符合预期时，在确认出口带宽充足的情况下，可以采用多窗口（相当于人为增加线程数）来逼近极限。 文章来源：锐捷无线百科 作者：地瓜
|
