Slik tester du VPN-hastighet slik at tallene betyr noe
Fest testserveren, hold underlaget stille og les forsinkelse adskilt fra gjennomstrømning. Tunnelen endrer ruten før den måler noe som helst.
En hastighetstest måler aldri VPN-en. Den måler en rute, og når du slår på tunnelen, erstattes en del av den ruten før den første byten flytter seg. Derfor viser én bærbar en sunn figur mot ett nettsted og en dårlig mot et annet, uten at noe er endret på noen av sidene. Les resultatet som bevis om en rute, ikke som en poengsum for et produkt.
Tre ting avgjør om sammenligningen er noe verdt: om begge kjøringene traff samme mål, om aksessnettet sto stille, og om du noterte forsinkelsen sammen med volumet.
Hva tunnelen skriver om før den første byten
Klienten pakker hver pakke inn i enda et header, så den nyttige lasten per pakke krymper. Kostnaden er per pakke og ikke per overføring, noe som betyr at en stor fil trenger flere pakker enn den samme filen sendt uten tunnel. Slik overhead viser seg som pakkeantall, ikke som en synlig innstilling.
To konsekvenser følger. En test bygget av store blokker merker kostnaden per pakke, mens en test av mange små forespørsler i stedet merker rundturene. Og hvis oppdagelsen av banens MTU er blokkert et sted underveis, lander tunnelen på en mindre pakkestørrelse, og gjennomstrømningen faller av en grunn som ikke har noe med krypteringsalgoritmene å gjøre.
Du kan se taket direkte. På Linux ber du om den største lasten som kommer gjennom uten fragmentering, og gjentar så med tunnelen på:
ping -M do -s 1472 -c 3 203.0.113.10
Hvis det feiler, gå ned til 1,400 og prøv igjen. En tunnel som bare bærer 1,380 byte forteller deg at noe klemmer lenger ned på ruten, og ingen mengde tuning på klienten løfter det.
Hvorfor testserveren flytter seg når tunnelen kommer opp
De fleste verktøy velger en server i nærheten ut fra den offentlige adressen de ser. Med tunnelen oppe tilhører den adressen utgangsknuten, så verktøyet kan velge en vert i en annen by eller et annet land. Du sammenligner da to destinasjoner, og avstanden mellom dem omfatter avstanden fra utgangen til testverten.
Fest serveren på navn eller ID før den første kjøringen, og hold den for hver kjøring etterpå. Hvis verktøyet ikke holder den, velg et mål du kontrollerer og kjør det selv: iperf3 -c test.example.net -R -t 20 holder destinasjonen fast og gir deg et tall du kan sammenligne med gårsdagens.
Bytt én variabel, og underlaget er ikke én
Trådløst er den vanlige skjulte endringen. Signalstyrken flytter seg når den bærbare flytter seg, og kanalbelastningen flytter seg når en nabo starter en samtale, så to kjøringer ti minutter fra hverandre på Wi-Fi er ikke gjentakelser av samme test. Kabel, eller en fast plassering med signalnivået skrevet ned, fjerner det meste av den støyen. Et notat om signalnivået ved start og slutt av hver kjøring er vanligvis nok til å vise om to kjøringer hører sammen.
Enhetsbelastning hører i samme kurv. En klient som krypterer på én kjerne, treffer sitt eget tak lenge før koblingen, og en bakgrunnssynkronisering treffer det tidligere. Følg med på CPU under kjøringen og noter hva annet som var åpent. Strøminnstillinger kan også bite her, fordi en bærbar på batteri kan begrense prosessoren lenge før koblingen er i nærheten av å være opptatt.
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
Hold underlaget stille i stedet for å gjennomsnittliggjøre over det. Tre kjøringer som stemmer, sier mer enn ti tatt i forskjellige rom.
Forsinkelse, tap og ICMP svarer på forskjellige spørsmål
Ping sender en liten sondering til en fast adresse, og mange nettverk svarer på ICMP med lav prioritet eller ignorerer det helt. Manglende svar beskriver sonderingen, ikke applikasjonens pakker. En rundtur som stiger under belastning betyr vanligvis at en kø fylles, ikke at ruten ble lengre.
For å finne ut om tunnelen legger til forsinkelse, sammenlign ett mål med og uten den, eller sammenlign to utganger som kan nås fra samme aksessnett. Kjør sonderingen gjentatte ganger og se på spredningen, fordi et gjennomsnitt nettopp skjuler den variasjonen som gjør en samtale ubrukelig.
Gå tilbake til oppgaven som føltes treg
Et måltall som blir bedre mens samtalen fortsatt hakker har svart på noe annet. Kjør oppgaven som startet undersøkelsen på nytt, uansett om det var et møte, en fildeling eller en eksternt skrivebord-økt. Hvis tallet ble bedre og oppgaven ikke, satt flaskehalsen et sted testen aldri nådde, som serveren bak tunnelen eller din egen opplastingslinje.
Logg hver kjøring med enhet, aksessnett, endepunkt, protokoll, mål og tid. En kjøring som aldri ble koblet til, er et tilgjengelighetsresultat og ikke en gjennomstrømning på null, så arkiver den under den etiketten i stedet for å slette den.
En kort liste før neste sammenligning
Fest målet og skriv ned hvorfor du valgte det. Noter pakkestørrelsen ruten tillater, slik at et senere fall har en forklaring. Hold aksessnettet identisk, noter CPU-belastningen, og ta tre kjøringer før du tror på en forskjell.
Bytt så nøyaktig én ting og gjenta. Sammenligningen du kan forklare, slår den med det større tallet.