Hvorfor to VPN-hastighedstests på samme tunnel er uenige

To kørsler, én tunnel, og tallene afviger med en faktor tre. Tunnelen ændrede sig ikke mellem dem. Det, der ændrede sig, er målingen: et testsite, der vælger en server ud fra din tilsyneladende placering, et antal streams, der afgør, om én langsom start eller seks fylder røret, og en varighed, der er kort nok til at slutte, før ruten overhovedet bruges ordentligt. Hastighedstests er ikke forkerte, men de besvarer et snævrere spørgsmål end det, folk stiller dem.

En ny udgangsadresse ændrer testdestinationen

De fleste testsites vælger en måleserver automatisk, og de vælger den delvist ved at se på, hvor din forbindelse ser ud til at komme fra. Slå tunnelen til, og dit tilsyneladende land ændrer sig, så den valgte server ændrer sig, og sammenligningen spænder nu over to forskellige ruter til to forskellige værter.

Resultatet er slet ikke en VPN-måling. Det er en måling af din rute til en server, du ikke valgte, og forskellen mellem de to kørsler kan være domineret af den servers peering snarere end af noget, tunnelen gjorde.

Fastlås destinationen, før du ændrer noget andet. Hvert troværdigt værktøj lader dig vælge en server eksplicit, og når det ikke gør, navngiver resultatsiden normalt den, den brugte, hvilket er nok til at bemærke, at de to kørsler ikke kan sammenlignes. Bekræft, hvad sitet så, før du stoler på dets valg:

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

Hvis landet ændrede sig mellem kørslerne, ændrede alt, hvad testen valgte derefter, sig også. Skriv den observerede udgang ved siden af hvert resultat, og forvirringen forsvinder stort set.

Langsom start slutter, efter at de fleste korte tests er slut

En TCP-forbindelse starter ikke ved forbindelsens hastighed. Den starter med et lille overbelastningsvindue, fordobler det omtrent hver rundtur og når først rutens kapacitet efter flere rundture. En test på ti sekunder på en rute med høj latenstid kan tilbringe en betydelig del af sit liv i den opbygning.

Det er derfor, en tunnel med højere latenstid klarer sig dårligere i en kort test, end den fortjener, og derfor rapporterer en længere kørsel ofte et højere tal uden nogen konfigurationsændring. gennemstrømningsrammen RFC 6349 behandler dette eksplicit, og derfor kører seriøse målinger længe nok til at nå en stabil tilstand. En kørsel på fem sekunder på en satellit-rute måler acceleratoren, ikke vejen.

Se på forbindelsens faser i stedet for at stole på et enkelt tal. Curl rapporterer hver fase separat, så du kan se, om tid går til håndtrykket, opbygningen eller overførslen:

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ør den to gange i træk mod samme destination. Hvis anden kørsel er meget hurtigere, målte du opbygningen, ikke ruten, og enhver sammenligning, der kun brugte første kørsel, er mistænkelig.

Én stream og seks streams måler forskellige ting

En enkelt TCP-stream er begrænset af det vindue, den kan holde i luften, hvilket er omtrent rundturstiden ganget med hastigheden. På en lang rute overstiger det produkt, hvad én stream vil bruge, så én download underrapporterer den kapacitet, der findes. Seks parallelle streams udfylder hullet og giver et 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

Begge tal er sande. Enkelt-stream-tallet fortæller, hvad én download vil gøre, hvilket en browservindue normalt får. Det parallelle tal fortæller, hvad ruten kan bære samlet, hvilket en torrent eller en download i dele kan bruge. At citere det ene, som om det var det andet, er måden, en sund tunnel bliver udskiftet uden grund.

At sammenligne et parallelt resultat med et enkelt-stream-resultat er den mest almindelige måde, folk konkluderer, at en VPN halverede deres hastighed. Tilpas metoden, og sammenlign så. Sporet i den tredje kommando tilføjer den manglende kontekst: en rute med høj jitter vil give inkonsistente resultater i begge tilstande, og ingen mængde streams retter op på det.

Kryptering koster processortid, indkapsling koster bytes

To mekanismer kører på hver pakke, uanset hvor hurtig forbindelsen er. Kryptering bruger CPU pr. byte, og indkapsling tilføjer header-bytes, som forbindelsen stadig skal bære. Begge viser sig som et loft, og de har forskellige symptomer.

CPU-loftet vises som en plateau: gennemstrømningen holder op med at stige, uanset hvor mange streams du tilføjer, og maskinens processor er travl, mens forbindelsen ikke er. På en lille router eller en telefon er det ofte den reelle grænse, og derfor kan en hurtig linje stadig levere en beskeden tunnel.

Byte-omkostningen er mindre, men konstant. Ekstra headere betyder mindre nyttelast pr. pakke, og på en rute med en fast maksimal transmissionsenhed kan de også udløse fragmentering eller sort hul, som viser sig som en standsning ved store overførsler snarere end som et langsomt gennemsnit.

Disse tre forveksles ofte, fordi brugerne beskriver dem alle som «VPN'en er langsom». Kun det første reagerer på en større maskine, kun det andet reagerer på en mindre MTU, og kun det tredje reagerer på køstyring.

Sæt metoden i journalen

Et resultat, der er værd at gemme, angiver enheden, adgangsnettet, udgangen, måleserveren, retningen, antallet af streams og varigheden. Uden dem kan to tal ikke sammenlignes, og en sag, der indeholder ét tal, er i virkeligheden en stemning.

Gem også de dårlige kørsler. En serie, hvor én udgang hver gang giver en standsning, er langt mere informativ end et gennemsnit, og standsningerne er præcis det, gennemsnit skjuler.

Test derefter det, du faktisk bekymrer dig om. Hvis en stor download er målet, så download filen. Hvis et opkald er målet, mål latenstid under belastning i stedet for ledig gennemstrømning, fordi en tunnel kan score godt i en hastighedstest og stadig gøre hvert møde uhørligt.