Mätmotorn i Bredbandskollen skickar all trafik igenom Flash. Vi använder förutom HTTP även Flash egen socket-funktion (se http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html) för att skicka och ta emot trafik. Så istället för att enbart skicka/begära trafiken med HTTP igenom webbläsaren så skapar vi en riktig socket i operativsystemet och går därmed förbi webbläsaren. För att socket-funktionen ska kunna användas krävs att servern kan svara på förfrågningar om s.k. policyfiler som anger vilka portar den tillåter Flash att ansluta sig till. Dessa förfrågningar görs i första hand mot port 843, men ifall klienten inte kan nå den porten sker förfrågan till port 80.


Dessa två metoder att mäta kan också köras tvingande via ”Avancerad mätning” i startvyn. Här kan man också manuellt välja vilken server vi vill mäta mot. I den vanliga mätningen väljs automatiskt den mätserver som står geografiskt närmast dig.


Mätmotorn gör i tur och ordning en svarstidsmätning (1), en nedladdningsmätning (2) och en uppladdningsmätning (3).


1) Vid svarstidsmätningen skickas 20 tcp-förfrågningar från klienten till servern. Detta sker sekventiellt på ett och samma tcp-koppel. Tiden mäts från det att frågan skickas på klienten tills svaret kommer från servern. Snittsvarstid räknas av de 15 snabbaste mätningarna.


På vissa plattformar är den interna svarstiden i FlashPlayer hög och då fungerar denna metod dåligt. Vi mäter därför svarstiden på ytterligare ett sätt, där logiken huvudsakligen ligger i servern. Sedan använder vi resultatet från den metod som fungerar bäst.


Den serverbaserade svarstidsmätningen bygger på att Flash hämtar en fil via HTTP-API:et. Servern dirigerar om till en dynamiskt genererad sida. När webbläsaren hämtar den, svarar servern med en textfil som anger hur lång tid det tog för klienten att följa omdirigeringen. Detta görs 10 gånger. De fem lägsta resultaten räknas bort. Slutresultatet är snittet av de kvarvarande mätresultaten.


2) Nedladdningsmätningen sker genom att ett antal samtidiga HTTP-förfrågningar sker från klienten till servern. Serven börjar då skicka data till klienten under tio sekunder. Klienten räknar ut i vilken hastighet data har tagits emot. En "mellantid" tas efter drygt två sekunder. Om hastigheten fram till mellantiden var lägre än den totala hastigheten, så baseras slutresultatet enbart på den del av mätningen som skedde efter mellantiden.


Hur många samtidiga HTTP-förfrågningar som görs beror på hur snabb anslutning man har. Normalt börjar mätningen med 12 samtidiga hämtningar. Efter cirka två sekunder av mätningen kan detta antal ökas eller minskas beroende på hur snabb överföringen varit dittills.


Normalt görs HTTP-förfrågningarna via socket-funktionen i Flash. För vissa klienter fungerar inte det, och då används den mindre effektiva mätmetoden där hämtningen sker via webbläsaren. En vanlig orsak till att detta inträffar är att klienten inte kan hämta policyfilen från servern på port 843 p.g.a. filter av nättrafiken. En annan orsak kan vara att någon lokal säkerhetsmekanism hos klienten, t.ex. SELinux, förhindrar Flash från att använda socket-funktionen.


Om nedladdningsmätningen via socket påbörjas men misslyckas, så görs den om via webbläsaren istället (en s.k. http-mätning). En orsak till att den misslyckas kan vara att någon lokal mekanism, t.ex. ett antivirusprogram eller en felkonfigurerad proxyserver, försöker fånga upp all data som hämtats innan den skickas vidare till webbläsaren och Flash.


3) Fyra samtidiga HTTP POST-förfrågningar görs till servern för mätning av uppladdningshastigheten. När servern är redo skickas data från klient till server i upp till tio sekunder. Servern lägger samman data från de fyra samtidiga uppladdningarna och räknar ut i vilken hastighet data har tagits emot varje 0,3 sekund. Dessa resultat skickas tillbaka till klienten på ett separat tcp-koppel. En "mellantid" tas efter drygt två sekunder. Om hastigheten fram till mellantiden var lägre än den totala hastigheten, så baseras slutresultatet enbart på den del av mätningen som skedde efter mellantiden.


Skälet till att hastigheten mäts i servern är att man i Flash inte på något tillförlitligt sätt kan se hur mycket data som faktiskt nått fram till servern i ett visst ögonblick. Man kan bara veta hur mycket data som flyttats från de interna buffertarna i Flash till operativsystemets buffertar.


Felkällor


1. Vi mäter svarstiden i webbläsaren, dvs. på applikationsnivå, och inte på operativsystemsnivå. Dessutom tar vi inte enbart det lägsta värdet utan snittet av ett antal mätningar. Därför visar vi ett högre värde på svarstiden än vad anslutningen rent tekniskt klarar.


2. Vi mäter snitthastigheten under 8-10 sekunder. Om man har en instabil anslutning, t.ex. för att man mäter via Wi-Fi, så kommer det resultat som visas att vara lägre än anslutningens topphastighet.


3. På vissa plattformar är Flashplayer dåligt optimerad, och då kan resultatet bli lägre än det borde vara. Om mätningen sker via webbläsaren p.g.a. att Flash:s socketfunktion inte kunde användas, så blir resultatet ofta 5-10% för lågt på anslutningar upp till 100Mbps och betydligt sämre på snabbare anslutningar.


4. Uppladdningsmätningen använder minst 50 MB mer minne än nedladdningsmätningen. På datorer med för lite internminne kan detta leda till ett lågt slutresultat.