Så testar du VPN-hastighet så att siffrorna betyder något
Lås testservern, håll underlaget stilla och läs fördröjning separat från genomströmning. Tunneln ändrar vägen innan den mäter något alls.
Ett hastighetstest mäter aldrig VPN:et. Det mäter en väg, och att slå på tunneln ersätter en del av den vägen innan den första byten rör sig. Därför visar en bärbar dator en frisk siffra mot en sida och en dålig mot en annan, utan att något har ändrats på någon av sidorna. Läs resultatet som bevis om en rutt, inte som en poäng för en produkt.
Tre saker avgör om jämförelsen är något värd: om båda körningarna träffade samma mål, om åtkomstnätet stod stilla och om du antecknade fördröjningen vid sidan av volymen.
Vad tunneln skriver om före den första byten
Klienten packar varje paket i ytterligare ett header, så den användbara lasten per paket krymper. Kostnaden är per paket och inte per överföring, vilket betyder att en stor fil behöver fler paket än samma fil skickad utan tunnel. Sådan overhead syns som paketantal, inte som en synlig inställning.
Två följder följer. Ett test byggt av stora block känner kostnaden per paket, medan ett test av många små förfrågningar i stället känner turerna fram och tillbaka. Och om upptäckten av banans MTU är blockerad någonstans på vägen, landar tunneln på en mindre paketstorlek och genomströmningen faller av en anledning som inte har något med chiffer att göra.
Du kan se taket direkt. I Linux ber du om den största last som går igenom utan fragmentering och upprepar sedan med tunneln på:
ping -M do -s 1472 -c 3 203.0.113.10
Om det misslyckas, gå ner till 1,400 och försök igen. En tunnel som bara bär 1,380 byte säger att något klämmer längre ner på vägen, och ingen mängd trimning på klienten lyfter det.
Varför testservern flyttar sig när tunneln kommer upp
De flesta verktyg väljer en närliggande server utifrån den offentliga adress de ser. Med tunneln uppe tillhör den adressen utgångsnoden, så verktyget kan välja en värd i en annan stad eller ett annat land. Du jämför då två destinationer, och avståndet mellan dem omfattar avståndet från utgången till testvärden.
Lås servern på namn eller ID före den första körningen och håll den för varje körning efteråt. Om verktyget inte håller den, välj ett mål du kontrollerar och kör det själv: iperf3 -c test.example.net -R -t 20 håller destinationen fast och ger dig en siffra du kan jämföra med gårdagens.
Ändra en variabel, och underlaget är inte en
Trådlöst är den vanliga dolda ändringen. Signalstyrkan flyttar sig när den bärbara flyttar sig och kanalbelastningen flyttar sig när en granne börjar ett samtal, så två körningar tio minuter isär på Wi-Fi är inte upprepningar av samma test. Kabel, eller en fast placering med signalnivån nedskriven, tar bort det mesta av det bruset. En anteckning om signalnivån i början och slutet av varje körning räcker oftast för att visa om två körningar hör ihop.
Enhetsbelastning hör i samma korg. En klient som krypterar på en kärna når sitt eget tak långt före länken, och en bakgrundssynkronisering når det tidigare. Håll koll på CPU under körningen och anteckna vad annat som var öppet. Ströminställningar kan också bita här, eftersom en bärbar dator på batteri kan begränsa processorn långt innan länken ens är nära att vara upptagen.
| 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 |
Håll underlaget stilla i stället för att medelvärdesbilda över det. Tre körningar som stämmer säger mer än tio tagna i olika rum.
Fördröjning, förlust och ICMP svarar på olika frågor
Ping skickar en liten sond till en fast adress, och många nät svarar på ICMP med låg prioritet eller ignorerar det helt. Saknade svar beskriver sonden, inte programmets paket. En rundtur som stiger under belastning betyder oftast att en kö fylls, inte att rutten blev längre.
För att ta reda på om tunneln lägger till fördröjning, jämför ett mål med och utan den, eller jämför två utgångar som nås från samma åtkomstnät. Kör sonden upprepade gånger och titta på spridningen, för ett medelvärde döljer just den variation som gör ett samtal oanvändbart.
Gå tillbaka till uppgiften som kändes långsam
Ett mått som förbättras medan samtalet fortfarande hackar har svarat på något annat. Kör om uppgiften som startade undersökningen, oavsett om det var ett möte, en fildelning eller en fjärrskrivbordssession. Om siffran blev bättre och uppgiften inte, satt flaskhalsen där testet aldrig nådde, som servern bakom tunneln eller din egen upplänk.
Logga varje körning med enhet, åtkomstnät, slutpunkt, protokoll, mål och tid. En körning som aldrig anslöt är ett nåbarhetsresultat och inte noll i genomströmning, så arkivera den under den etiketten i stället för att radera den.
En kort lista före nästa jämförelse
Lås målet och skriv ner varför du valde det. Anteckna den paketstorlek som vägen tillåter, så att ett senare fall har en förklaring. Håll åtkomstnätet identiskt, anteckna CPU-belastningen och gör tre körningar innan du tror på en skillnad.
Ändra sedan exakt en sak och upprepa. Den jämförelse du kan förklara slår den med den större siffran.