Kan en VPN være hurtigere end den direkte forbindelse?

En overførsel, der kravler på kontorforbindelsen, bliver nogle gange hurtigt færdig gennem tunnelen, og den ekstra indkapsling får det til at se umuligt ud. Det tilsyneladende paradoks kommer af at sammenligne de forkerte ting. Tunnelen tilføjer arbejde, og den ændrer også hvilken netværksvej trafikken følger, hvilken adresse destinationen ser, og nogle gange hvilken server der overhovedet svarer. Et valg mellem de to ruter kræver, at de tre effekter skilles ad, før der konkluderes noget om hastighed.

Tre ting tunnelen kan ændre

Det første er transit. Internetrouting følger operatørens politik og forretningsforhold, ikke målt latenstid, så vejen gennem en VPN-udbyder kan krydse andre netværk end den direkte rute. Det kan undgå en overbelastet udveksling eller lande på en med bedre peering, og det kan lige så nemt være værre.

Det andet er destinationen. En ændring af udgangsadresse ændrer ofte DNS-svaret, og et indholdsnetværk kan give dig en anden cache eller region. En del af forbedringen tilhører så den nye server frem for tunnelen. Det samme værtsnavn kan lande på en nærmere eller mindre belastet server, uden at noget ændres på klienten.

Det tredje er transportadfærd. Indkapsling ændrer den effektive pakkestørrelse, og en tunnel, der undgår et tabsramt midterstykke, kan lade en TCP-strøm vokse sit vindue i stedet for at bakke gentagne gange. Ingen af disse er en universel accelerationsmekanisme; hver er en betingelse, der skal observeres. At skille dem ad er det, der gør en kuriositet til et faktum.

Hvad den ikke kan ændre

Intet i tunnelen tilføjer kapacitet til linket mellem enheden og netværket. En mættet Wi-Fi-kanal, et overbelastet sidste led eller et begrænset mobilt abonnement begrænser begge veje ens, og en hastighedstest gennem tunnelen kan ikke overstige det loft. Det samme link bærer de indkapslede pakker, så indkapsling kan bruge kapacitet, men aldrig skabe den. Det, der ændres, er, hvor pakkerne går hen, efter de forlader linket. Derfor har et hurtigt tunnelresultat altid en forklaring oven for det første hop.

Grænser på serversiden er lige så ligeglade. Hvis den fjerne vært betjener langsomt, leverer en bedre vej kun det langsomme svar mere effektivt, og brugeren venter stadig. En delt oprindelse under belastning ser langsom ud på begge veje i samme øjeblik.

Sammenlign vejene ordentligt

Hold applikation, retning, varighed og samtidighed identiske, og ændr kun vejen. Kør hver test mere end én gang på samme tid af dagen, og notér udgangsadressen og resolverens svar sammen med gennemstrømningen. En enkelt kørsel er en stikprøve, ikke en måling, og en enkelt hurtig download kan være et cache-hit, der intet siger om ruten. Skriv betingelserne ned før resultaterne, for tallene er svære at fortolke bagefter.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Resolverens svar er den detalje, de fleste sammenligninger udelader, og den forklarer de “forbedringer”, der forsvinder, når den samme server tvinges igennem. Hvis adressen er forskellig mellem kørslerne, sammenlignede testen to destinationer i stedet for to veje. Rapportér latenstid og tab ved siden af gennemstrømningen, for en vej, der er hurtigere samlet, men tilføjer forsinkelse til hver interaktiv anmodning, er ikke bedre for den arbejdsbyrde, der klagede. Rundtur-tid betyder mere end massiv hastighed for alt, der spørger og venter.

Hvornår forskellen er værd at beholde

Hvis en godkendt tunnel pålideligt forbedrer en bestemt arbejdsbyrde, er det et legitimt driftsvalg: dokumentér arbejdsbyrden, målingen og den anvendte udgang. En brugbar registrering nævner én vært, den udgangsadresse tunnelen gav, resolverens svar og de samme tal fra den direkte vej samme dag. Det er nok til, at den næste ingeniør kan gentage sammenligningen i stedet for at genoptage diskussionen. Det er stadig ikke bevis for, at udbyderen begrænser noget, og det overføres ikke til andre applikationer eller andre timer.

Opbevar målingen sammen med konfigurationen. Den svarer på det næste spørgsmål om, hvorvidt forbedringen stadig findes, og det er den eneste måde at vide, om vejen eller arbejdsbyrden ændrede sig. En registrering uden dato kan slet ikke svare på det spørgsmål.