Sådan tester du VPN-hastighed, så tallene betyder noget
Lås testserveren, hold underlaget stille og læs forsinkelse adskilt fra gennemstrømning. Tunnelen ændrer ruten, før den måler noget som helst.
En hastighedstest måler aldrig VPN'en. Den måler en rute, og når du tænder tunnelen, erstattes en del af den rute, før den første byte flytter sig. Derfor viser én bærbar en sund figur mod ét websted og en dårlig mod et andet, uden at noget er ændret på nogen af siderne. Læs resultatet som bevis om en rute, ikke som en score for et produkt.
Tre ting afgør, om sammenligningen er noget værd: om begge kørsler ramte samme mål, om adgangsnettet stod stille, og om du noterede forsinkelse sammen med volumen.
Hvad tunnelen omskriver før den første byte
Klienten pakker hver pakke ind i endnu et header, så den brugbare nyttelast pr. pakke skrumper. Omkostningen er pr. pakke og ikke pr. overførsel, hvilket betyder, at en stor fil kræver flere pakker end den samme fil sendt uden tunnel. Sådan overhead viser sig som pakkeantal, ikke som en synlig indstilling.
Der følger to konsekvenser. En test bygget af store blokke mærker omkostningen pr. pakke, mens en test af mange små forespørgsler i stedet mærker rundturene. Og hvis opdagelsen af stiens MTU er blokeret et sted undervejs, lander tunnelen på en mindre pakkestørrelse, og gennemstrømningen falder af en grund, der intet har med krypteringsalgoritmerne at gøre.
Du kan se loftet direkte. På Linux beder du om den største nyttelast, der overlever uden fragmentering, og gentager så med tunnelen tændt:
ping -M do -s 1472 -c 3 203.0.113.10
Hvis det fejler, gå ned til 1,400 og prøv igen. En tunnel, der kun bærer 1,380 byte, fortæller dig, at noget klemmer længere nede ad ruten, og ingen mængde tuning på klienten løfter det.
Hvorfor testserveren flytter sig, når tunnelen kommer op
De fleste værktøjer vælger en nærliggende server ud fra den offentlige adresse, de ser. Med tunnelen oppe tilhører den adresse udgangsknoden, så værktøjet kan vælge en vært i en anden by eller et andet land. Du sammenligner så to destinationer, og afstanden mellem dem omfatter afstanden fra udgangen til testværten.
Lås serveren fast på navn eller ID før den første kørsel, og hold den til hver kørsel derefter. Hvis værktøjet ikke vil holde den, så vælg et mål, du selv kontrollerer, og kør det selv: iperf3 -c test.example.net -R -t 20 holder destinationen fast og giver dig et tal, du kan sammenligne med i går.
Skift én variabel, og underlaget er ikke én
Trådløst er den sædvanlige skjulte ændring. Signalstyrken flytter sig, når den bærbare flytter sig, og kanalbelægningen flytter sig, når en nabo starter en samtale, så to kørsler ti minutter fra hinanden på Wi-Fi er ikke gentagelser af samme test. Kabel, eller en fast placering med signalniveauet skrevet ned, fjerner det meste af den støj. En note om signalniveauet ved start og slutning af hver kørsel er som regel nok til at vise, om to kørsler hører sammen.
Enhedsbelastning hører i samme spand. En klient, der krypterer på én kerne, rammer sit eget loft længe før linket, og en baggrundssynkronisering rammer det før. Hold øje med CPU under kørslen, og noter hvad der ellers var åbent. Strømindstillinger kan også bide her, fordi en bærbar på batteri kan begrænse processoren længe før linket er i nærheden af at være travlt.
| 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 at gennemsnitliggøre over det. Tre kørsler, der stemmer, siger mere end ti taget i forskellige rum.
Forsinkelse, tab og ICMP besvarer forskellige spørgsmål
Ping sender en lille sondering til en fast adresse, og mange netværk svarer på ICMP med lav prioritet eller ignorerer det helt. Manglende svar beskriver sonderingen, ikke applikationens pakker. En rundtursti, der stiger under belastning, betyder som regel, at en kø fyldes, ikke at ruten er blevet længere.
For at finde ud af, om tunnelen tilføjer forsinkelse, så sammenlign ét mål med og uden den, eller sammenlign to udgange, der kan nås fra samme adgangsnet. Kør sonderingen gentagne gange, og se på spredningen, fordi et gennemsnit netop skjuler den variation, der gør en samtale ubrugelig.
Gå tilbage til den opgave, der føltes langsom
Et benchmark, der forbedres, mens samtalen stadig hakker har svaret på noget andet. Kør opgaven, der startede undersøgelsen, igen, uanset om det var et møde, en fildeling eller en fjernskrivebordssession. Hvis tallet blev bedre, og opgaven ikke, sad flaskehalsen et sted, testen aldrig nåede, såsom serveren bag tunnelen eller dit uplink.
Log hver kørsel med enhed, adgangsnet, endepunkt, protokol, mål og tid. En kørsel, der aldrig blev forbundet, er et tilgængelighedsresultat frem for en gennemstrømning på nul, så arkivér den under den etiket i stedet for at slette den.
En kort liste før den næste sammenligning
Fastlæg målet, og skriv ned, hvorfor du valgte det. Notér den pakkestørrelse, ruten tillader, så et senere fald har en forklaring. Hold adgangsnettet identisk, notér CPU-belastning, og tag tre kørsler, før du tror på en forskel.
Skift så præcis én ting, og gentag. Den sammenligning, du kan forklare, slår den med det større tal.