某LTE运营商SpeedTest测速分析.doc

.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. Well explain that more below.8. The remaining slices are averaged together to determine the final result.* Deciding the number of threads: S 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 S 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 youre testing from an older browser to a host that doesnt, S 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 现场实测及分析现场使用*手机，在手机上安装抓包软件Shark.apk，在启动SpeedTest测速之前首先启动Shark进行抓包，以获取SpeedTest测速时的抓包数据。下面分别介绍一下距离*较近的三个SpeedTest服务器的测速原理：服务器*服务器*服务器*服务器测速周期=15秒下载业务量30MBytes*2线程30MBytes*2线程30MBytes*2线程GET请求信息GET /speedtest/random4000x4000.jpg HTTP/1.1Host: GET /speedtest/random4000x4000.jpg HTTP/1.1Host: GET /speedtest/random4000x4000.jpg HTTP/1.1Host: 4同时，还进行了下述实验：针对无线环境绝对良好以及无线环境一般的测试场景，分别使用SpeedTest和20线程的FileZilla进行了对比测试，具体结果如下（4类终端）：场景理论速率RSRPSINRSpeedTest平均测试结果FileZilla平均测试结果（20线程）无线环境绝对良好110Mbps高于-753080Mbps100Mbps无线环境绝对良好56Mbps高于-753053Mbps54Mbps无线环境一般110Mbps-82左右25左右48Mbps81Mbps无线环境一般56Mbps-82左右23左右31Mbps43Mbps无线环境一般90Mbps-82左右23左右44Mbps75Mbps由上述测试结果可知：只有在无线环境绝对良好且理论速率不高的情况下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个线程丢包对整体测试结果的影响1线程100%2线程50%10线程10%20线程5%其实，从10线程和20线程FileZilla的测试结果也可以佐证这一点。以下图为例，首先使用1个FileZilla（10线程）进行下载，在打开另外1个FileZilla（10线程）进行下载后，明显可以看到，速率变得更加稳定了，因为单个线程的丢包对所有线程的影响减小了，更不要说2个线程和20个线程的对比结果了：1.2 SpeedTest测速分析结论无线环境绝对良好且理论速率较低（小于60Mbps）的的测试场景：由于不存在丢包，支持SpeedTest测速；无线环境绝对良好但理论速率较高（大于60Mbps）的的测试场景：由于终端浏览器的限制，目前只能使用2线程（SpeedTest官网建议速率大于4Mbps的网络使用支持4线程的浏览器进