如果老板问你speedtest上下行测速差异大，你该怎么回答？

 在一个风和日丽的清晨，灵儿惬意地漂浮在Wi-Fi森林里。

突然遭遇老板夺命连环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测速结果受限于线程数和包大小。根据预测试评估结论而来，比如灵儿生活的Wi-Fi森林在忙时和闲时线程数差了一倍。

No2.Speedtest用于测试无线极限性能并不妥当。理由正如灵儿上面所述。

No3.Speedtest对于体验的参考意义在于能够大致表征出整体链路的情况，如果Speedtest测出来的结果可以支撑相关应用（具体的指标Speedtest官方文档有说明，灵儿就不啰嗦了），那么，就一定没问题。如果测试结果不理想时，不妨试试其他的测速软件。

小技能Get，如何让Speedtest测出高性能  

(1) 选择出口对应运营商最近测速服务器进行测试

跨运营商或者长路由链路带来的时延会影响Speedtest对链路质量的评估，进而影响到测速结果。

(2) 避开出口链路拥塞进行测试

出口链路拥塞影响协商报文大小及线程数，单窗口测速结果不符合预期时，在确认出口带宽充足的情况下，可以采用多窗口（相当于人为增加线程数）来逼近极限。