Hvorfor to VPN-hastighetstester i samme tunnel ikke stemmer overens

To kjøringer, én tunnel, og tallene avviker med en faktor tre. Tunnelen endret seg ikke mellom dem. Det som endret seg, er målingen: et testnettsted som velger server ut fra hvor du ser ut til å være, et antall strømmer som avgjør om én treg start eller seks fyller røret, og en varighet som er kort nok til å ta slutt før ruten i det hele tatt brukes ordentlig. Hastighetstester er ikke feil, men de svarer på et smalere spørsmål enn det folk stiller dem.

En ny utgangsadresse endrer testdestinasjonen

De fleste testnettsteder velger en måleserver automatisk, og de velger den delvis ved å se på hvor tilkoblingen din ser ut til å komme fra. Slå på tunnelen og det tilsynelatende landet ditt endres, så den valgte serveren endres, og sammenligningen strekker seg nå over to ulike ruter til to ulike verter.

Resultatet er ikke en VPN-måling i det hele tatt. Det er en måling av ruten din til en server du ikke valgte, og forskjellen mellom de to kjøringene kan domineres av peering hos den serveren snarere enn av noe tunnelen gjorde.

Fest destinasjonen før du endrer noe annet. Hvert troverdig verktøy lar deg velge server eksplisitt, og når det ikke gjør det, navngir resultatsiden vanligvis den som ble brukt, noe som er nok til å legge merke til at de to kjøringene ikke er sammenlignbare. Bekreft hva nettstedet så før du stoler på valget det tok:

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

Hvis landet endret seg mellom kjøringene, endret alt testen valgte etterpå seg også. Skriv den observerte utgangen ved siden av hvert resultat, og forvirringen forsvinner stort sett.

Treg start er ferdig etter at de fleste korte testene er over

En TCP-tilkobling starter ikke ved linjehastigheten. Den starter med et lite overbelastningsvindu, dobler det omtrent for hver rundtur, og når først kapasiteten i ruten etter flere rundturer. En test på ti sekunder på en rute med høy latenstid kan tilbringe en betydelig del av livet sitt i den opptrappingen.

Derfor skårer en tunnel med høyere latenstid dårligere på en kort test enn den fortjener, og derfor rapporterer en lengre kjøring ofte et høyere tall uten noen konfigurasjonsendring. gjennomstrømningsrammeverket RFC 6349 behandler dette eksplisitt, og derfor varer seriøse målinger lenge nok til å nå en stabil tilstand. En kjøring på fem sekunder på en satellittrute måler akseleratoren, ikke veien.

Se på fasene i tilkoblingen i stedet for å stole på ett tall. Curl rapporterer hver fase separat, så du kan se om tiden går til håndtrykket, opptrappingen eller overfø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

Kjør den to ganger etter hverandre mot samme destinasjon. Hvis den andre kjøringen er mye raskere, målte du opptrappingen, ikke ruten, og enhver sammenligning som bare brukte den første, er mistenkelig.

Én strøm og seks strømmer måler forskjellige ting

Én enkelt TCP-strøm begrenses av vinduet den kan holde i luften, som er omtrent rundturstiden ganget med raten. På en lang rute overstiger det produktet det én strøm vil bruke, så én nedlasting rapporterer lavere enn kapasiteten som finnes. Seks parallelle strømmer fyller gapet og gir et større tall.

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

Begge tallene er sanne. Tallet for én strøm sier hva én nedlasting vil gjøre, som en nettleserfane vanligvis får. Det parallelle tallet sier hva ruten kan bære samlet, som en torrent eller en nedlasting i deler kan bruke. Å sitere det ene som om det var det andre, er måten en sunn tunnel blir byttet ut uten grunn.

Å sammenligne et parallelt resultat med et enkeltstrømsresultat er den vanligste måten folk konkluderer med at en VPN halverte hastigheten. Tilpass metoden, sammenlign så. Sporet i den tredje kommandoen legger til konteksten som mangler: en rute med høy jitter gir inkonsistente resultater i begge modusene, og ingen mengde strømmer retter på det.

Kryptering koster prosessortid, innkapsling koster byte

To mekanismer kjører på hver pakke uansett hvor rask linjen er. Kryptering bruker prosessor per byte, og innkapsling legger til header-byte som linjen fortsatt må bære. Begge viser seg som et tak, og de har ulike symptomer.

Prosessortaket vises som et platå: gjennomstrømningen slutter å stige uansett hvor mange strømmer du legger til, og maskinens prosessor er opptatt mens linjen ikke er det. På en liten ruter eller en telefon er det ofte den reelle grensen, og derfor kan en rask linje fortsatt gi en beskjeden tunnel.

Bytekostnaden er mindre, men konstant. Ekstra headere betyr mindre nyttelast per pakke, og på en rute med fast maksimal overføringsenhet kan de også utløse fragmentering eller svart hull som viser seg som en stopp ved store overføringer snarere enn som et tregt gjennomsnitt.

Disse tre forveksles ofte fordi brukere beskriver dem alle som at VPN-en er treg. Bare den første reagerer på en større maskin, bare den andre reagerer på en mindre MTU, og bare den tredje reagerer på køstyring.

Sett metoden i journalen

Et resultat som er verdt å ta vare på, navngir enheten, aksessnettet, utgangen, måleserveren, retningen, antall strømmer og varigheten. Uten dem kan to tall ikke sammenlignes, og en sak som inneholder ett tall, er egentlig en stemning.

Ta også vare på de dårlige kjøringene. En serie der én utgang gir en stopp hver gang, er langt mer informativ enn et gjennomsnitt, og stoppene er nettopp det gjennomsnitt skjuler.

Test så det du faktisk bryr deg om. Hvis en stor nedlasting er målet, last ned filen. Hvis et anrop er målet, mål latenstid under belastning i stedet for ledig gjennomstrømning, fordi en tunnel kan skåre godt på en hastighetstest og likevel gjøre hvert møte uhørbart.