Varför en nedladdning är snabbare via VPN än direkt

Du startar en stor nedladdning, de första sekunderna ser normala ut och sedan stabiliseras hastigheten på ungefär hälften av vad linjen borde leverera. Du ansluter tunneln, upprepar samma nedladdning och den håller en högre hastighet genom hela filen. Det är en verklig mätning och en vilseledande slutsats samtidigt, eftersom tunneln inte gjorde vägen snabbare. Den flyttade bara din trafik från en port som något längs vägen begränsade.

Kurvans form avslöjar det

Titta på överföringen i stället för sluttalet. En begränsad väg börjar oftast nära linjens hastighet, gör slut på sin burst-kvot och lägger sig sedan på gränsen, så medelvärdet beror på hur länge du tittade. En tunnel som verkligen förbättrade vägen skulle visa bättre hastighet från första sekunden och behålla den. Platån är fingeravtrycket, och det är lätt att missa om du bara noterar toppen.

Två körningar av samma fil, en direkt och en genom tunneln, räcker för att se om det finns en platå.

Notera när platån börjar, hur länge den varar och vilken hastighet den håller. De tre värdena skiljer en shaper från en överbelastad väg, för överbelastning låter hastigheten vandra medan en shaper spikar den vid ett enda tal. Om den direkta körningen gradvis blir sämre och tunnelkörningen håller sig stabil ser du på politik och inte på fysik.

Tre jämförelser, en variabel var

Ändra en sak per körning, annars lär du dig inget. Hämta samma fil via den vanliga webbvägen, sedan via ett överföringsverktyg som använder en annan port, från en värd med jämförbar kapacitet och vid samma timme. Håll klientmaskinen fast, för en bärbar dator som rör sig mellan nätverk lägger till en variabel du inte kan styra.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Använd en fil som redan är komprimerad, till exempel en diskavbildning, så att transportkomprimering inte kan förklara skillnaden. Om du sedan styr servern flyttar du dess lyssnare till den port du misstänker är formad, uppdaterar klientprofilen och upprepar. Skulle tunneln nu falla till den formade hastigheten följer gränsen porten och inte tunneln, och frågan är avgjord. Kör varje jämförelse två gånger och behåll platåns siffror, inte topparna.

Notera också timmen, för en shaper kan vara tidsbaserad och ett kvällstest kan vara oense med ett morgontest. Två körningar vid samma timme är värda mer än tio utspridda över dagen.

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 inte är formade. Den beskriver en överföring på en linje under en timme. Gränserna kan vara per session, per abonnent eller tidsbaserade, och en operatör kan ändra dem utan att annonsera det.

Den visar inte heller att den direkta vägen är felaktig. En formad väg fungerar precis som avsett, den är bara begränsad av politik.

Skillnaden spelar roll när du skriver ihop det. Ett fel bjuder in till en reparationsanmälan, medan en politik bjuder in till en fråga om avtalet eller ett beslut att gå runt den. Att kalla en begränsning för ett fel ger ett supportärende som börjar från fel premiss. Att kalla den politik gör att du kan ställa en konkret fråga som har ett konkret svar.

Gör fyndet till en supportförfrågan

Använd siffrorna och lämna slutsatsen utanför. En förfrågan som säger att stora överföringar över port 80 ligger kvar på ungefär halva den förväntade hastigheten under de här timmarna, med platåns siffror bifogade, är genomförbar. En förfrågan som säger att VPN är snabbare är det inte, eftersom den läses som ett påstående om tunneln i stället för en observation om linjen. Bifoga båda körningarna och deras tidsstämplar och låt sedan operatören beskriva politiken.

Tvinga inte in varje program i tunneln bara för att jaga den siffran.

Tunneln kostar dig fortfarande ett extra hopp, kryptering och en ny uppsättning fellägen, medan den begränsade porten förblir begränsad för allt annat som använder den. När stora överföringar måste slutföras pålitligt, för din egen anteckning om vilken port som bär gränsen. Att flytta en lyssnare till port 80 krockar också med vilken webbserver som helst som redan är bunden till den, och det ger ett nytt avbrott i stället för en åtgärd.