Varför en VPN-nedladdning kan slå din direkta anslutning

Anslut tunneln, starta en stor nedladdning och den går ungefär dubbelt så snabbt som samma fil klarade utan den. Det låter som reklam, men kan vara en verklig mätning på en hemmaanslutning. Den vanliga orsaken är en hastighetsgräns knuten till en port: tunneln bär din överföring dit formaren inte tittar, och linjens verkliga kapacitet visar sig för första gången.

Vilket betyder att det intressanta talet inte är hur snabb VPN var. Det är hur mycket av din linje du aldrig fick, och varför.

En gräns som följer porten, inte vägen

En leverantör kan begränsa genomströmningen per abonnent efter protokoll eller målport, och port 80 är ett favoritmål eftersom så mycket vanligt surfande använder den. Gränsen sätts ofta inte från första paketet: överföringen börjar nära linjens hastighet, bränner en burst-kvot och lägger sig sedan på det begränsade värdet. De första sekunderna ser friska ut, resten av överföringen inte.

Skicka samma byte över en annan port och formaren på 80 ser dem aldrig. Tunneln ser ut att slå den direkta anslutningen trots att den lagt till ett hopp, kryptering och sina egna kostnader. Det som blev bättre är inte vägen utan frånvaron av en regel.

Det är också därför effekten är så jämn över filer och mål. Om gränsen sitter på porten beter sig allt som bärs på den porten likadant, hur stor filen än är och vem värden än är. Ett mål som drar till sig en annan regel visar en annan kurva, och den skillnaden är diagnostisk i sig.

Mät platån, inte toppen

En topp är den minst informativa delen av en överföring, eftersom varje anslutning ser bra ut medan dess buffertar fylls. Notera var hastigheten faller till ro och hur länge den stannar där.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Kör paret direkt efter varandra på samma maskin, vid samma timme, mot värdar i jämförbara nät. Ett prov bevisar ingenting; kurvans form över två körningar av varje är det som skiljer en burst-kvot från en stabil gräns. Skriv ned var hastigheten planar ut, inte vad den första sekunden visade, eftersom bursten är precis vad en formare ger dig innan den börjar begränsa. En lugn platå som håller resten av överföringen ut är talet att jämföra.

Håll filen redan komprimerad så att transportkomprimering inte kan erbjudas som förklaring. En PDF eller ett arkiv tar bort den variabeln och hindrar också någon från att hävda att tunneln pressade nyttolasten. Om båda överföringarna använder samma fil är den enda kvarvarande skillnaden vägen och porten. Notera verktyget och porten bredvid varje siffra, annars är den andra körningen inte jämförbar med den första.

Tre jämförelser som isolerar orsaken

Gå igenom dem i ordning och stanna så snart mönstret är klart, eftersom var och en utesluter en annan historia.

1. Upprepa samma nedladdning över den vanliga webbvägen och via ett överföringsverktyg på en annan port, från en värd med jämförbar kapacitet.
2. Upprepa båda med en inkompressibel fil, så att komprimering slutar vara kandidat.
3. Om du själv driver tunnelservern, bind om den till port 80, justera klientprofilen så att båda ändar är överens och överför igen. Om tunneln nu sitter på den begränsade webhastigheten följer begränsningen porten och inte VPN.

Det tredje steget är det avgörande, och det är också det folk hoppar över eftersom det kräver en konfigurationsändring. Utan det har du visat att två saker skiljer sig, inte att porten är orsaken.

Vad den här mätningen inte kan stödja

Den visar inte att tunneln är snabbare i allmänhet, att den komprimerar något eller att andra portar på linjen är obegränsade. Den beskriver den här överföringen, på den här linjen, vid den här timmen. Gränser kan gälla per session, per abonnent eller efter tid på dygnet, och de kan ändras utan varsel.

Den bevisar inte heller att den direkta vägen är trasig. En begränsad väg fungerar fortfarande; den är begränsad med avsikt, och medveten policy är inte ett fel som väntar på reparation.

Och den rättfärdigar absolut inte att routa allt genom tunneln. Varje program på port 80 förblir begränsat, medan allt du leds om nu hänger på ett extra hopp och ett extra felläge.

Gör fyndet till något som går att agera på

Skriv observationen som en mätning och inte som en dom: stora överföringar över port 80 lägger sig nära hälften av den hastighet som samma fil når på en annan port, vid de här timmarna, på den här linjen, med de här proven bifogade. Det är en supportförfrågan som någon kan utreda.

”VPN är snabbare” är det inte. Det bjuder in ett svar om krypteringskostnader, och det svaret är tekniskt korrekt samtidigt som det inte säger någon något användbart. Bifoga antalet prov, timmen och porten, så att läsaren kan återskapa mönstret.

Om du bestämmer dig för att fortsätta använda en annan port för stora överföringar, notera förbehållet i dina egna anteckningar: att flytta en lyssnare till port 80 krockar med vilken webbserver som helst som redan är bunden där, och felet som följer ser ut som en trasig tunnel snarare än en portkonflikt.