Kan en VPN være raskere enn den direkte tilkoblingen?

En overføring som krabber på kontortilkoblingen blir noen ganger raskt ferdig gjennom tunnelen, og den ekstra innkapslingen får det til å virke umulig. Det tilsynelatende paradokset kommer av å sammenligne feil ting. Tunnelen tilfører arbeid, og den endrer også hvilken nettverksvei trafikken følger, hvilken adresse destinasjonen ser og noen ganger hvilken server som i det hele tatt svarer. Et valg mellom de to rutene krever at disse tre effektene skilles før noen konklusjon om hastighet.

Tre ting tunnelen kan endre

Den første er transitt. Internett-ruting følger operatørens policy og forretningsforhold, ikke målt latenstid, så veien gjennom en VPN-leverandør kan krysse andre nettverk enn den direkte ruten. Det kan unngå en overbelastet utveksling eller lande på en med bedre peering, og det kan like gjerne være verre.

Den andre er destinasjonen. En endring av utgangsadresse endrer ofte DNS-svaret, og et innholdsnettverk kan gi deg en annen cache eller region. En del av forbedringen tilhører da den nye serveren og ikke tunnelen. Samme vertsnavn kan lande på en nærmere eller mindre belastet server uten at noe endres på klienten.

Den tredje er transportatferd. Innkapsling endrer den effektive pakkestørrelsen, og en tunnel som unngår et tapsutsatt midtsegment kan la en TCP-strøm vokse vinduet sitt i stedet for å trekke seg tilbake gang på gang. Ingen av disse er en universell akselerasjonsmekanisme; hver er en betingelse som må observeres. Å skille dem er det som gjør en kuriositet til et faktum.

Hva den ikke kan endre

Ingenting i tunnelen tilfører kapasitet til lenken mellom enheten og nettverket. En mettet Wi-Fi-kanal, en overbelastet siste mil eller et begrenset mobilabonnement begrenser begge veier likt, og en hastighetstest gjennom tunnelen kan ikke overstige den grensen. Den samme lenken bærer de innkapslede pakkene, så innkapsling kan bruke kapasitet, men aldri skape den. Det som endres, er hvor pakkene går etter at de forlater lenken. Derfor har et raskt tunnelresultat alltid en forklaring over det første hoppet.

Grenser på serversiden er like likegyldige. Hvis den eksterne verten tjener sakte, leverer en bedre vei bare det trege svaret mer effektivt, og brukeren venter fortsatt. En delt opprinnelse under last ser treg ut på begge veier i samme øyeblikk.

Sammenlign veiene riktig

Hold applikasjon, retning, varighet og samtidighet identiske, og endre bare veien. Kjør hver test mer enn én gang, på samme tid på dagen, og noter utgangsadressen og resolverens svar ved siden av gjennomstrømningen. En enkelt kjøring er et utvalg og ikke en måling, og en enkelt rask nedlasting kan være en cachetreff som ikke sier noe om ruten. Skriv ned betingelsene før resultatene, for tallene er vanskelige å tolke etterpå.

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 detaljen de fleste sammenligninger utelater, og det forklarer «forbedringene» som forsvinner når samme server tvinges gjennom. Hvis adressen er ulik mellom kjøringene, sammenlignet testen to destinasjoner og ikke to veier. Rapporter latenstid og tap ved siden av gjennomstrømningen, for en vei som er raskere samlet men legger til forsinkelse på hver interaktive forespørsel er ikke bedre for arbeidsbelastningen som klaget. Rundturtid betyr mer enn massiv hastighet for alt som spør og venter.

Når forskjellen er verdt å beholde

Hvis en godkjent tunnel pålitelig forbedrer en bestemt arbeidsbelastning, er det et legitimt driftsvalg: dokumenter arbeidsbelastningen, målingen og utgangen som ble brukt. En brukbar registrering navngir én vert, utgangsadressen tunnelen ga, resolverens svar og de samme tallene fra den direkte veien samme dag. Det er nok til at neste ingeniør kan gjenta sammenligningen i stedet for å ta diskusjonen på nytt. Det er fortsatt ikke bevis for at leverandøren begrenser noe, og det overføres ikke til andre applikasjoner eller andre timer.

Oppbevar målingen sammen med konfigurasjonen. Den svarer på neste spørsmål om forbedringen fortsatt finnes, og det er den eneste måten å vite om veien eller arbeidsbelastningen endret seg. En registrering uten dato kan ikke svare på det spørsmålet i det hele tatt.