Varför två VPN-hastighetstester i samma tunnel inte stämmer överens

Två körningar, en tunnel, och siffrorna skiljer sig med en faktor tre. Tunneln ändrades inte mellan dem. Det som ändrades är mätningen: en testsajt som väljer server utifrån var du verkar befinna dig, ett antal strömmar som avgör om en långsam start eller sex fyller röret, och en varaktighet som är kort nog att ta slut innan vägen ens används ordentligt. Hastighetstester är inte fel, men de svarar på en snävare fråga än den folk ställer dem.

En ny utgångsadress ändrar testets destination

De flesta testsajter väljer en mätserver automatiskt, och de väljer den delvis genom att titta på varifrån din anslutning verkar komma. Slå på tunneln och ditt skenbara land ändras, så den valda servern ändras, och jämförelsen spänner nu över två olika vägar till två olika värdar.

Resultatet är inte alls en VPN-mätning. Det är en mätning av din väg till en server du inte valde, och skillnaden mellan de två körningarna kan domineras av den serverns peering snarare än av något tunneln gjorde.

Lås destinationen innan du ändrar något annat. Varje trovärdigt verktyg låter dig välja server uttryckligen, och när det inte gör det namnger resultatsidan oftast den som användes, vilket räcker för att märka att de två körningarna inte är jämförbara. Bekräfta vad sajten såg innan du litar på dess val:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Om landet ändrades mellan körningarna ändrades också allt testet valde därefter. Skriv den observerade utgången bredvid varje resultat och förvirringen försvinner till stor del.

Långsam start är klar efter att de flesta korta tester är över

En TCP-anslutning börjar inte vid länkens hastighet. Den börjar med ett litet överbelastningsfönster, fördubblar det ungefär varje tur och retur, och når först vägens kapacitet efter flera turer. Ett test på tio sekunder på en väg med hög latens kan tillbringa en betydande del av sitt liv i den upptrappningen.

Det är därför en tunnel med högre latens presterar sämre i ett kort test än den förtjänar, och därför rapporterar en längre körning ofta ett högre tal utan någon konfigurationsändring. RFC 6349:s genomströmningsramverk behandlar detta uttryckligen, och därför pågår seriösa mätningar länge nog att nå ett stabilt tillstånd. En körning på fem sekunder på en satellitväg mäter acceleratorn, inte vägen.

Titta på anslutningens faser i stället för att lita på ett enda tal. Curl rapporterar varje fas separat, så du kan se om tiden går till handskakningen, upptrappningen eller överföringen:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Kör den två gånger i rad mot samma destination. Om den andra körningen är mycket snabbare mätte du upptrappningen, inte vägen, och varje jämförelse som bara använde den första är misstänkt.

En ström och sex strömmar mäter olika saker

En enda TCP-ström begränsas av det fönster den kan hålla i luften, vilket är ungefär tur-och-retur-tiden multiplicerad med hastigheten. På en lång väg överstiger den produkten vad en ström kommer att använda, så en enda nedladdning rapporterar mindre än den kapacitet som finns. Sex parallella strömmar fyller gapet och ger ett större tal.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Båda talen är sanna. Talet för en ström säger vad en nedladdning gör, vilket en webbläsarflik vanligtvis får. Det parallella talet säger vad vägen kan bära totalt, vilket en torrent eller en nedladdning i delar kan utnyttja. Att citera det ena som om det vore det andra är hur en frisk tunnel byts ut utan anledning.

Att jämföra ett parallellt resultat med ett enkelströmsresultat är det vanligaste sättet folk drar slutsatsen att en VPN halverade deras hastighet. Jämka metoden och jämför sedan. Spåret i det tredje kommandot lägger till den kontext som saknas: en väg med hög jitter ger inkonsekventa resultat i båda lägena, och ingen mängd strömmar åtgärdar det.

Kryptering kostar processortid, inkapsling kostar byte

Två mekanismer arbetar på varje paket oavsett hur snabb länken är. Kryptering förbrukar processor per byte, och inkapsling lägger till rubrikbyte som länken ändå måste bära. Båda visar sig som ett tak, och de har olika symtom.

Processortaket visar sig som en platå: genomströmningen slutar öka hur många strömmar du än lägger till, och maskinens processor är upptagen medan länken inte är det. På en liten router eller en telefon är det ofta den verkliga gränsen, och därför kan en snabb linje ändå ge en blygsam tunnel.

Bytekostnaden är mindre men konstant. Extra rubriker betyder mindre nyttolast per paket, och på en väg med fast maximal överföringsenhet kan de också utlösa fragmentering eller ett svart hål som visar sig som ett stopp vid stora överföringar snarare än som ett långsamt medelvärde.

Dessa tre förväxlas ofta eftersom användare beskriver dem alla som att VPN:en är långsam. Bara den första reagerar på en större maskin, bara den andra reagerar på en mindre MTU, och bara den tredje reagerar på köhantering.

Skriv in metoden i protokollet

Ett resultat som är värt att spara namnger enheten, åtkomstnätet, utgången, mätservern, riktningen, antalet strömmar och varaktigheten. Utan dem kan två tal inte jämföras, och ett ärende som innehåller ett enda tal är egentligen ett humör.

Spara också de dåliga körningarna. En serie där en utgång ger ett stopp varje gång är långt mer informativ än ett medelvärde, och stoppen är precis vad medelvärden döljer.

Testa sedan det du faktiskt bryr dig om. Om en stor nedladdning är målet, ladda ner filen. Om ett samtal är målet, mät latens under last i stället för genomströmning i vila, för en tunnel kan prestera bra i ett hastighetstest och ändå göra varje möte ohörbart.