Kvifor to VPN-hastigheitstestar i same tunnel ikkje stemmer overeins

To køyringar, éin tunnel, og tala avvik med ein faktor tre. Tunnelen endra seg ikkje mellom dei. Det som endra seg, er målinga: eit testnettstad som vel tenar ut frå kvar du ser ut til å vere, eit tal på straumar som avgjer om éin treg start eller seks fyller røyret, og ei varigheit som er kort nok til å ta slutt før ruta i det heile teke vert brukt ordentleg. Hastigheitstestar er ikkje feil, men dei svarar på eit smalare spørsmål enn det folk stiller dei.

Ein ny utgangsadresse endrar testdestinasjonen

Dei fleste testnettstadene vel ein måletenar automatisk, og dei vel han delvis ved å sjå på kvar tilkoplinga di ser ut til å kome frå. Slå på tunnelen og det tilsynelatande landet ditt endrar seg, så den valde tenaren endrar seg, og samanlikninga strekkjer seg no over to ulike ruter til to ulike vertar.

Resultatet er ikkje ei VPN-måling i det heile teke. Det er ei måling av ruta di til ein tenar du ikkje valde, og skilnaden mellom dei to køyringane kan dominerast av peering hjå den tenaren snarare enn av noko tunnelen gjorde.

Fest destinasjonen før du endrar noko anna. Kvart truverdige verktøy lèt deg velje tenar eksplisitt, og når det ikkje gjer det, namngjev resultatsida vanlegvis den som vart brukt, noko som er nok til å leggje merke til at dei to køyringane ikkje er samanliknbare. Stadfest kva nettstaden såg før du stolar på valet det tok:

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

Om landet endra seg mellom køyringane, endra alt testen valde etterpå seg òg. Skriv den observerte utgangen ved sida av kvart resultat, og forvirringa forsvinn stort sett.

Treg start er ferdig etter at dei fleste korte testane er over

Ei TCP-tilkopling startar ikkje ved linjehastigheita. Ho startar med eit lite overbelastningsvindauge, dobblar det om lag for kvar rundtur, og når først kapasiteten i ruta etter fleire rundturar. Ein test på ti sekund på ei rute med høg latenstid kan bruke ein betydeleg del av livet sitt i den opptrappinga.

Difor skårar ein tunnel med høgare latenstid dårlegare på ein kort test enn han fortener, og difor rapporterer ei lengre køyring ofte eit høgare tal utan noka konfigurasjonsendring. gjennomstrøymingsrammeverket RFC 6349 behandlar dette eksplisitt, og difor varer seriøse målingar lenge nok til å nå ein stabil tilstand. Ei køyring på fem sekund på ei satellittrute måler akseleratoren, ikkje vegen.

Sjå på fasane i tilkoplinga i staden for å stole på eitt tal. Curl rapporterer kvar fase separat, så du kan sjå om tida går til handtrykket, opptrappinga eller overføringa:

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øyr han to gonger etter kvarandre mot same destinasjon. Om den andre køyringa er mykje raskare, målte du opptrappinga, ikkje ruta, og kvar samanlikning som berre brukte den første, er mistenkeleg.

Éin straum og seks straumar måler ulike ting

Éin enkel TCP-straum vert avgrensa av vindauget han kan halde i lufta, som er om lag rundturstida gonga med raten. På ei lang rute overstig det produktet det éin straum vil bruke, så éi nedlasting rapporterer lågare enn kapasiteten som finst. Seks parallelle straumar fyller gapet og gjev eit 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åe tala er sanne. Talet for éin straum seier kva éi nedlasting vil gjere, som ei nettlesarfane vanlegvis får. Det parallelle talet seier kva ruta kan bere samla, som ein torrent eller ei nedlasting i delar kan bruke. Å sitere det eine som om det var det andre, er måten ein sunn tunnel vert bytt ut utan grunn.

Å samanlikne eit parallelt resultat med eit enkeltstraumresultat er den vanlegaste måten folk konkluderer med at ein VPN halverte hastigheita. Tilpass metoden, samanlikn så. Sporet i den tredje kommandoen legg til konteksten som manglar: ei rute med høg jitter gjev inkonsistente resultat i båe modusane, og ingen mengd straumar rettar på det.

Kryptering kostar prosessortid, innkapsling kostar byte

To mekanismar køyrer på kvar pakke uansett kor rask linja er. Kryptering brukar prosessor per byte, og innkapsling legg til header-byte som linja framleis må bere. Båe viser seg som eit tak, og dei har ulike symptom.

Prosessortaket viser seg som eit platå: gjennomstrøyminga sluttar å stige uansett kor mange straumar du legg til, og prosessoren i maskina er oppteken medan linja ikkje er det. På ein liten ruter eller ein telefon er det ofte den reelle grensa, og difor kan ei rask linje framleis gje ein beskjeden tunnel.

Bytekostnaden er mindre, men konstant. Ekstra headarar tyder mindre nyttelast per pakke, og på ei rute med fast maksimal overføringseining kan dei òg utløyse fragmentering eller eit svart hol som viser seg som ein stopp ved store overføringar snarare enn som eit tregt gjennomsnitt.

Desse tre vert ofte forveksla fordi brukarar skildrar dei alle som at VPN-en er treg. Berre den første reagerer på ei større maskin, berre den andre reagerer på ein mindre MTU, og berre den tredje reagerer på køstyring.

Set metoden i journalen

Eit resultat som er verdt å ta vare på, namngjev eininga, aksessnettet, utgangen, måletenaren, retninga, talet på straumar og varigheita. Utan dei kan to tal ikkje samanliknast, og ei sak som inneheld eitt tal, er eigenleg ei stemning.

Ta òg vare på dei dårlege køyringane. Ein serie der éin utgang gjev ein stopp kvar gong, er langt meir informativ enn eit gjennomsnitt, og stoppa er nettopp det gjennomsnittet skjuler.

Test så det du faktisk bryr deg om. Om ei stor nedlasting er målet, last ned fila. Om eit anrop er målet, mål latenstid under belastning i staden for ledig gjennomstrøyming, fordi ein tunnel kan skåre godt på ein hastigheitstest og likevel gjere kvart møte uhøyrbart.