Mätmotorn i Bredbandskollen skickar all trafik igenom Flash. Vi använder förutom HTTP även Flash egen socket-funktion (see http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html) to send and receive traffic. So instead of just sending/requesting HTTP traffic through the browser, we create a proper socket in the operating system and thereby eliminate the need to run the traffic though the browser. For the socket function to be used it is required for the server to respond to requests for so-called policy files. These files specify which ports Flash is allowed to connect to. These requests are made primarily on port 843, but in case the client cannot reach this port, requests are made request to port 80 instead.
These two measurement methods can also be run explicitly via "Advanced measurement" in the start view. You can also select which server you want to measure against. In the standard measurement, Bredbandskollen automatically selects the test server that is geographically closest to you.
The test engine performs, in sequence, a response time measurement (1), a download measurement (2) and a upload measurement (3).
1) During response time measurement, 20 tcp requests are sent from the client to the server. This is done sequentially on a single tcp leash. The time is measured from the time the query is sent until the answer is returned from the server. An average response time is calculated by the 15 fastest measurements.
On some platforms, the internal response time of FlashPlayer is high and then this method works poorly. Therefore, we measure the response time in yet another way, where the logic is mainly located in the server. After these two measurements we use the result from the method that works best.
The server-side response time measurement is based on Flash downloading a file via the HTTP API. The server redirects to a dynamically generated webpage. When the browser loads this page, the server will respond with a text file that specifies the amount of time it took for the client to follow the redirect. This is done 10 times. The five slowest results are removed and the end result is calculated as the average of the remaining five.
2) The download speed measurement is done by a number of simultaneous HTTP requests from the client to the server. The server then starts sending data to the client for a period of 10 seconds. The client calculates the speed at which data has been received. An "intermediate time" is taken after just over two seconds. If the average speed up until the meantime was lower than the overall speed, the final speed is based only on that part of the test that took place after the interim time.
How many concurrent HTTP requests that are made will depend on the speed of your connection. Normally the measurement starts with 12 concurrent downloads. After about two seconds, this number is increased or decreased depending on how fast the transfer has been so far.
Normally, the HTTP requests are made via the socket function in Flash. For some clients this will not work and the less effective method of measuring via the browser is used instead. A common reason for this is that the client cannot download the policy file from the server on port 843 due to filtered network traffic. Another reason could be a local security mechanism on the client, for example. SELinux, that prevents Flash from using the socket function.
If the download measurement via sockets starts but fails, it is restarted via the web browser instead (a so called http measurement). One reason for the failure could be a local mechanism, for example an antivirus program or a misconfigured proxy server, trying to capture all data retrieved before being sending it on to the browser and Flash.
3) Four concurrent HTTP POST requests are made to the server to measure the upload speed. When the server is ready, data will be sent from the client to the server for up to ten seconds. The server adds the data from the four concurrent uploads and calculates the speed at which data is received once every 0.3 seconds. These results are sent back to the client on a separate tcp leash. An "intermediate time" is taken after just over two seconds. If the speed up until the intermediate time was lower than the overall speed, the final upload speed is based only on that part of the test that took place after the intermediate time was taken.
The reason that the speed is measured in the server is that Flash does not have any reliable way to tell how much data actually got through to the server at a certain moment. Bredbandskollen can only see how much data is moved from the internal buffers in Flash to the buffers of the operating system.
1. We measure the response time of the browser, i.e. at the application level and not at the operating system level. We are not only using the lowest value, but an average of several measuremets. That is why we show a higher value for the response time than the connection is capable of.
2. We measure the average speed for 8-10 seconds. If you have an unstable connection, e.g. if you measure via Wi-Fi, the results shown will appear to be lower than the possible top speed.
3. The Flashplayer is badly optimized on some platforms and the speed may be slower than it should be. If the measurent is done via the browser and not via the Flash socket function the result is often 5-10% lower on connections up to 100Mbps and significantly worse on faster connections.
4. The upload test uses 50 MB more memory than the download test. On computers with little memory, this can lead to a low upload speed result.