老板问你speedtest上下行差异大 怎么答?

2016-09-05 14:50 出处:PConline原创 作者:佚名 责任编辑:sunziyi

  在一个风和日丽的清晨,灵儿惬意地漂浮在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) 避开出口链路拥塞进行测试

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

  文章来源:锐捷无线百科  作者:地瓜

网络设备论坛帖子排行

最高点击 最高回复 最新
最新资讯离线随时看 聊天吐槽赢奖品