Kan ett VPN vara snabbare än den direkta anslutningen?

En överföring som kryper på kontorsanslutningen blir ibland snabbt klar genom tunneln, och den extra inkapslingen får det att verka omöjligt. Den skenbara paradoxen kommer av att jämföra fel saker. Tunneln tillför arbete, och den ändrar också vilken nätverksväg trafiken följer, vilken adress destinationen ser och ibland vilken server som överhuvudtaget svarar. Ett val mellan de två vägarna kräver att dessa tre effekter separeras innan någon slutsats om hastigheten.

Tre saker tunneln kan ändra

Den första är transit. Internets routing följer operatörens policy och affärsrelationer, inte uppmätt latens, så vägen genom en VPN-leverantör kan korsa andra nät än den direkta vägen. Det kan undvika en överbelastad utbytespunkt eller hamna på en med bättre peering, och det kan lika gärna vara sämre.

Den andra är destinationen. En ändrad utgångsadress ändrar ofta DNS-svaret, och ett innehållsnätverk kan ge dig ett annat cache eller en annan region. En del av förbättringen tillhör då den nya servern och inte tunneln. Samma värdnamn kan hamna på en närmare eller mindre belastad server utan att något ändras på klienten.

Den tredje är transportbeteende. Inkapsling ändrar den effektiva paketstorleken, och en tunnel som undviker ett förlustdrabbat mittsegment kan låta ett TCP-flöde växa sitt fönster i stället för att backa om och om igen. Ingen av dessa är en universell accelerationsmekanism; var och en är ett villkor som måste observeras. Att skilja dem åt är det som gör en kuriositet till ett faktum.

Vad den inte kan ändra

Ingenting i tunneln tillför kapacitet till länken mellan enheten och nätet. En mättad Wi-Fi-kanal, en överbelastad sista mil eller ett begränsat mobilabonnemang begränsar båda vägarna lika, och ett hastighetstest genom tunneln kan inte överskrida det taket. Samma länk bär de inkapslade paketen, så inkapsling kan göra av med kapacitet men aldrig skapa den. Det som ändras är vart paketen tar vägen efter att de lämnat länken. Därför har ett snabbt tunnelresultat alltid en förklaring ovanför det första hoppet.

Gränser på serversidan är lika likgiltiga. Om den fjärran värden betjänar långsamt levererar en bättre väg bara det långsamma svaret effektivare, och användaren väntar fortfarande. En delad ursprungskälla under last ser långsam ut på båda vägarna i samma ögonblick.

Jämför vägarna ordentligt

Håll program, riktning, varaktighet och samtidighet identiska och ändra bara vägen. Kör varje test mer än en gång, vid samma tid på dygnet, och anteckna utgångsadressen och resolverns svar bredvid genomströmningen. En körning är ett stickprov och inte en mätning, och en enda snabb nedladdning kan vara en cacheträff som inte säger något om vägen. Skriv ner villkoren före resultaten, för siffrorna är svåra att tolka efteråt.

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

Resolverns svar är detaljen som de flesta jämförelser utelämnar, och det förklarar de “förbättringar” som försvinner när samma server tvingas fram. Om adressen skiljer sig mellan körningarna har testet jämfört två destinationer och inte två vägar. Rapportera latens och förlust bredvid genomströmningen, för en väg som är snabbare totalt men lägger till fördröjning på varje interaktiv begäran är inte bättre för den arbetsbelastning som klagade. Runturtiden betyder mer än masshastigheten för allt som frågar och väntar.

När skillnaden är värd att behålla

Om en godkänd tunnel pålitligt förbättrar en viss arbetsbelastning är det ett legitimt driftval: dokumentera arbetsbelastningen, mätningen och den utgång som användes. En användbar post namnger en värd, den utgångsadress tunneln gav, resolverns svar och samma siffror från den direkta vägen samma dag. Det räcker för nästa ingenjör att upprepa jämförelsen i stället för att ta diskussionen igen. Det är fortfarande inte bevis för att leverantören begränsar något, och det överförs inte till andra program eller andra timmar.

Spara mätningen tillsammans med konfigurationen. Den svarar på nästa fråga om förbättringen finns kvar, och det är det enda sättet att veta om vägen eller arbetsbelastningen ändrades. En post utan datum kan inte svara på den frågan alls.