Kan een VPN sneller zijn dan de directe verbinding?

Een overdracht die op de kantoorverbinding kruipt, is via de tunnel soms snel klaar, en de extra encapsulatie laat dat onmogelijk lijken. De schijnbare paradox komt van het vergelijken van de verkeerde dingen. De tunnel voegt werk toe, en hij verandert ook welk netwerkpad het verkeer volgt, welk adres de bestemming ziet en soms welke server überhaupt antwoordt. Een keuze tussen de twee routes vereist dat die drie effecten worden gescheiden voordat er iets over snelheid wordt geconcludeerd.

Drie dingen die de tunnel kan veranderen

Het eerste is transit. Internetrouting volgt het beleid van de operator en zakelijke relaties, niet de gemeten latency, dus de route via een VPN-aanbieder kan andere netwerken doorkruisen dan de directe route. Die kan een overbelast uitwisselpunt vermijden of op een beter gekoppeld punt uitkomen, en evengoed slechter zijn.

Het tweede is de bestemming. Een wijziging van uitgaand adres verandert vaak het DNS-antwoord, en een contentnetwerk kan je een andere cache of regio geven. Een deel van de verbetering hoort dan bij de nieuwe server en niet bij de tunnel. Dezelfde hostnaam kan op een dichterbij gelegen of minder belaste server uitkomen zonder dat er aan de client iets verandert.

Het derde is transportgedrag. Encapsulatie verandert de effectieve pakketgrootte, en een tunnel die een lossig middensegment vermijdt, kan een TCP-stroom zijn venster laten groeien in plaats van steeds terug te vallen. Niets hiervan is een universeel versnellingsmechanisme; elk is een voorwaarde die moet worden waargenomen. Ze scheiden is wat nieuwsgierigheid in een feit verandert.

Wat hij niet kan veranderen

Niets in de tunnel voegt capaciteit toe aan de verbinding tussen het apparaat en het netwerk. Een verzadigd Wi-Fi-kanaal, een overbelaste laatste kilometer of een gelimiteerd mobiel abonnement begrenzen beide routes op dezelfde manier, en een snelheidstest via de tunnel kan dat plafond niet overschrijden. Dezelfde verbinding draagt de ingekapselde pakketten, dus encapsulatie kan capaciteit verbruiken maar nooit creëren. Wat verandert, is waar de pakketten heen gaan nadat ze die verbinding verlaten. Daarom heeft een snel tunnelresultaat altijd een verklaring boven de eerste hop.

Grenzen aan de serverkant zijn even onverschillig. Als de externe host langzaam levert, levert een betere route de langzame reactie alleen efficiënter, en de gebruiker wacht nog steeds. Een gedeelde oorsprong onder belasting ziet er op hetzelfde moment op beide routes traag uit.

Vergelijk de routes goed

Houd de applicatie, richting, duur en gelijktijdigheid identiek en verander alleen de route. Voer elke test meer dan eens uit, op hetzelfde tijdstip van de dag, en noteer het uitgaande adres en het antwoord van de resolver naast de doorvoer. Eén run is een steekproef en geen meting, en één snelle download kan een cachehit zijn die niets over de route zegt. Schrijf de omstandigheden op vóór de resultaten, want de cijfers zijn achteraf moeilijk te interpreteren.

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

Het antwoord van de resolver is het detail dat de meeste vergelijkingen weglaten, en het verklaart de “verbeteringen” die verdwijnen als dezelfde server wordt geforceerd. Als het adres tussen runs verschilt, heeft de test twee bestemmingen vergeleken in plaats van twee routes. Rapporteer latency en verlies naast de doorvoer, want een route die in totaal sneller is maar elke interactieve aanvraag vertraging toevoegt, is niet beter voor de werklast die klaagde. De retourtijd is belangrijker dan de bulksnelheid voor alles wat vraagt en wacht.

Wanneer het verschil de moeite waard is om te behouden

Als een goedgekeurde tunnel een specifieke werklast betrouwbaar verbetert, is dat een legitieme operationele keuze: documenteer de werklast, de meting en de gebruikte uitgang. Een bruikbaar record noemt één host, het uitgaande adres dat de tunnel opleverde, het antwoord van de resolver en dezelfde cijfers van de directe route op dezelfde dag. Dat is genoeg voor de volgende engineer om de vergelijking te herhalen in plaats van haar opnieuw te betwisten. Het is nog steeds geen bewijs dat de aanbieder iets knijpt, en het geldt niet voor andere applicaties of andere uren.

Bewaar het meetrecord bij de configuratie. Het beantwoordt de volgende vraag of de verbetering nog bestaat, en dat is de enige manier om te weten of de route of de werklast is veranderd. Een record zonder datum kan die vraag helemaal niet beantwoorden.