The speed test algorithm has been developed and improved over time so that it provides accurate and consistent results across all devices, platforms and operating systems. It is important to state that the same algorithm is used in all cases but with different implementations as required by each platform.
The process involves:
Connections are made to at least 3 of our servers closest to the device and preliminary tests are made to select the most suitable Measurement Server to give the most accurate results. The choice of server is dependent on a number of factors including response times, geo-location and network type of the device.
The geo-location and network type is provided directly from the device’s operating system.
The process for choosing the correct Measurement Server is managed by the Speedtest controller and the result is passed to the application. An accurate ping test is also used to provide the user with ping response data.
Our Speedchecker uses the TCP protocol instead of ICMP to determine the ping time as it provides results closer to the real word , as ICMP is often throttled.
Alternatively, we also offer customers to report HTTP latency, the method can be customized using config parameters. HTTP latency is typically at least 2x higher than TCP as it has more overhead. We use XHR ping which requires no special server technology and produces slower results than TCP because we are measuring times to transfer larger amounts of data including opening a socket before measuring latency. This resembles the normal behaviour of a web browser, while using TCP will produce faster results.
Ping is the name of the tool measuring latency using the ICMP protocol, which can be useful for network diagnostics and many latency related issues. It has its own protocol and its header structure is solely oriented as a diagnostic tool. Using it has many advantages especially when diagnosing network connections. It is classified as a layer 3 protocol and is excellent in measuring and diagnosing at that level. It can be somewhat useful for measuring applications, but one has to take into account that it measures in the network layer. Another disadvantage is that it gets typically blocked in servers because of its abuse potential and also disabling it doesn't sacrifice web services for example.
A very good argument for using TCP or HTTP in our measurements is that, unlike ICMP, it's the same protocol used in web applications and therefore we are measuring the whole protocol stack, from layer 7 including everything else to the bottom of the stack. For real world applications it is much more useful because it will reflect the latency experienced by exactly the same process that will affect web development decisions. For example, HTTP is subject to problems in TCP connections and ICMP isn't. In other words, a server can ping very well, but because of other problems in higher layers, the application can still have problems that happen somewhere else and you can't see this just by pinging.
Websocket is not supported on all devices or servers. By default, we maintain an up-to-date list of all servers capabilities and if the best server for a given user does not support Websocket, we perform testing on HTTP fallback. In some cases, e.g. CDN POPs do not offer websocket connections and therefore HTTP fallback is the only way to test against particular CDN.
All the modern browsers support Websockets, as you can see on this compatibility chart: https://caniuse.com/#feat=websockets
If the user browser is out of date and does not support Websockets, the test will run on HTTP fallback.
Websocket protocol is widely supported by most of the modern browsers and allows us to test more accurately by leveraging full duplex communication between server and client. Unlike in HTTP protocol Websocket server is able to push data to the client without a prior request from the client. This is especially useful in upload measurement. Moreover, data can be sent on open Websocket (and therefore TCP connection) to lower the overhead of establishing connections and introducing more noise to bandwidth measurements.
Our websocket measurement (both for download and upload) uses by default port 8088 (since port 80 is busy with HTTP fallback) and establishes several TCP connections between client (user) and server (best server established during Ping measurement phase)
Client controls the measurement phase by selecting optimal number of websocket connections. Once connections are established (default 4), it sends initial chunks of data (size between 4kB and 1MB) to establish approximate client connection speed. If connection speed is not saturated fully, client will increase number of websocket connections (up to 8) to increase the saturation and correctly determine maximum possible connection speed. The test runs for variable period of time (default 20 seconds).
To avoid short bursts influencing final measured speed, our algorithm removes top/bottom of the samples to ensure that the most representative samples are included in average speed calculation. Websocket is used both for download and upload measurement with only difference of sending data in different directions.
A few small files are downloaded from the chosen Measurement Server (established in the Ping phase) to quickly estimate the speed of the connection. The results of this test are used to estimate the optimum file size for the final speed test file.
Based on extensive lab testing we realized that splitting the download into 4 equal parts gives the most accurate real-life results. Using just one large file for testing does not accurately reflect real life results but splitting the file into too many parts is equally inaccurate. The download files are already stored in all the possible sizes on each Measurement Server (in 4 equal parts) ready for download.
These 4-part files are requested by our application via 4 separate threads. The download requests and the servicing of these downloads are carried out using the device’s own HTTP Protocol. Our application monitors each of these downloads via the 4 threads (see diagram) and uses the progress to generate download profiles. The file needs to be big enough to take more than 2 seconds to download to ensure the accurate results
It is during the downloading that the algorithm is busy refining the estimate to ensure the most accurate results. This refinement includes, but is not limited to:
The algorithm works the same way for testing Upload speeds as it does for download tests with the following exceptions: