某LTE运营商SpeedTest测速分析

1.1 SpeedTest测速分析

1.1..1 SpeedTest测速原理介绍

首先，从SpeedTest官网（）找到了SpeedTest下载测速的原理，具体如下：

1. Your computer downloads small binary files from the web server to the client,

and we measure that download to estimate the connection speed.

2. Based off this result, we choose how much data to download for the real test.

Our goal is to pick the right amount of data that you can download in 10

seconds, ensuring we get enough for an accurate result but not take too

long.

3. We prevent caches from throwing off results by appending random strings

to each download.

4. Once we start downloading, we use up to four HTTP threads* to saturate

your connection and get an accurate measurement.

5. Throughput samples are received at up to 30 times per second.

6. These samples are then aggregated into 20 slices (each being 5% of the

samples).

7. The fastest 10% and slowest 30% of the slices are then discarded. We'll

explain that more below.

8. The remaining slices are averaged together to determine the final result.

* Deciding the number of threads: will use up to four http threads

during the download and upload portions of the test. However, it will only use

more than two threads if they are needed to accurately measure the speed, so as

to minimize the effect of HTTP overhead on lower-speed connections. After the

pre-test, if the connection speed is at least 4 megabits per second, then

will use four threads. Otherwise, it will default to two threads.

However, there is a hurdle on older browsers: on Internet Explorer 7 and earlier

(as well as Firefox 2 and earlier), the browser strictly adheres to the HTTP

specification of only two threads per hostname. So for those older browsers, in

order to scale up to four threads we must open the third and fourth thread to a

secondary URL provided by the host that points to the same server. This way, we

can work around the limitations of those older browsers and still measure

higher-speed connections accurately. Most of our hosts do have a working

secondary URL, but if you're testing from an older browser to a host that doesn't,

will be limited to two threads at maximum. This is one reason why

we recommend that all visitors use up-to-date browsers.

解读关键点：

1. 测量结果中最快的10%和最慢的30%采样点不计入评估结果

2. 大部分的浏览器都只能支持双线程，而如果速率达到4Mbps，建议使用支持4线程的浏览器

1.1..2 现场实测及分析

现场使用**手机，在手机上安装抓包软件，在启动SpeedTest测速之前首先启动Shark进行抓包，以获取SpeedTest测速时的抓包数据。下面分别介绍一下距离**较近的三个SpeedTest服务器的测速原理：

服务器

测速周期

下载业务量 30MBytes*2线程

GET

/speedtest/

GET请求信息 HTTP/1.1

Host:

**服务器 **服务器

<=15秒

30MBytes*2线程

GET

/speedtest/

HTTP/1.1

Host:

30MBytes*2线程

GET

/speedtest/

HTTP/1.1

Host:

**服务器

同时，还进行了下述实验：针对无线环境绝对良好以及无线环境一般的测试场景，分别使用SpeedTest和20线程的FileZilla进行了对比测试，具体结果如下（4类终端）：

场景

无线环境绝对良好

无线环境绝对良好

无线环境一般

无线环境一般

无线环境一般

理论速率

110Mbps

56Mbps

110Mbps

56Mbps

90Mbps

RSRP

高于-75

高于-75

-82左右

-82左右

-82左右

SINR

30

30

25左右

23左右

23左右

SpeedTest平均测试结果

80Mbps

53Mbps

48Mbps

31Mbps

FileZilla平均测试结果（20线程）

100Mbps

54Mbps

81Mbps

43Mbps

44Mbps 75Mbps

由上述测试结果可知：只有在无线环境绝对良好且理论速率不高的情况下SpeedTest的测试结果才可以与FileZilla（20线程）的测试结果匹配。而另外两种测试场景：无线环境绝对良好且理论速率很高、无线环境一般（不管理论速率高不高），都存在SpeedTest测试结果差于FileZilla（20线程）的情况。下面针对这两种场景为什么会出现SpeedTest测试结果差于FileZilla（20线程）进行分析，具体如下：

无线环境绝对良好且理论速率很高

由于目前安卓浏览器的限制，虽然TDL的速率超过了4Mbps，但是在**手机上，没有启用4线程进行测试，而是使用2线程，对于速率较高的测试场景，会出现无法进行饱和测试的问题。通过下图可以很好的说明：

备注：丢包率=0%，乱序率=0%，双流室分小区，E频段，时隙配比10:2:2，4类终端理论速率约为100Mbps

另外，通过上述典型数据还可以发现另外一个现象：由于2个线程（下载的业务量是相同的）速率的差异，两个线程不会是同时结束，也就是说，最后只剩1个线程的测试结果不具有参考性。但是，显然SpeedTest开发人员已经注意到了这点，通过不考虑最差的30%采样点的方式进行了有效规避，所以，对于双线程不是同时启动和结束的问题，可以忽略。

无线环境一般（不管理论速率高不高）

线程的数量与测试结果的好坏有直接关系，线程数量越多（20个以上则影响不大），单个线程出现丢包引起速率陡降的问题对所有线程的影响越小，具体如下：

线程数量

1线程

2线程

10线程

20线程

其中1个线程丢包对整体测试结果的影响

100%

50%

10%

5%

其实，从10线程和20线程FileZilla的测试结果也可以佐证这一点。以下图为例，首先使用1个FileZilla（10线程）进行下载，在打开另外1个FileZilla（10线程）进行下载后，明显可以看到，速率变得更

加稳定了，因为单个线程的丢包对所有线程的影响减小了，更不要说2个线程和20个线程的对比结果了：

1.2 SpeedTest测速分析结论

无线环境绝对良好且理论速率较低（小于60Mbps）的的测试场景：由于不存在丢包，支持SpeedTest测速；

无线环境绝对良好但理论速率较高（大于60Mbps）的的测试场景：由于终端浏览器的限制，目前只能使用2线程（SpeedTest官网建议速率大于4Mbps的网络使用支持4线程的浏览器进行测速）进行测速，会出现无法进行饱和测试的问题，造成测速结果不稳定；

无线环境一般（不管理论速率高不高）的测试场景：并行测试的线程数量越少，因为无线原因的影响，单个线程出现速率陡降时对整体测速结果的影响越大。以在手机上使用SpeedTest测速为例，使用的是2线程，其中1个线程出现速率陡降对整体测速结果的影响达到50%。所以，在这种场景下，SpeedTest的测速结果大概只有FileZilla多线程测试结果的一半。