Hvorfor en download er hurtigere over VPN end direkte

Du starter en stor download, de første sekunder ser normale ud, og så stabiliserer hastigheden sig på cirka halvdelen af det, linjen burde levere. Du forbinder tunnelen, gentager den samme download, og den holder en højere hastighed hele filen igennem. Det er en reel måling og en vildledende konklusion på samme tid, for tunnelen gjorde ikke vejen hurtigere. Den flyttede bare din trafik væk fra en port, som noget undervejs begrænsede.

Kurvens form afslører det

Se på overførslen frem for det endelige tal. En begrænset vej starter normalt nær linjehastigheden, bruger sin burst-kvote og sætter sig derefter på grænsen, så gennemsnittet afhænger af, hvor længe du kiggede. En tunnel, der virkelig forbedrede vejen, ville vise en bedre hastighed fra første sekund og holde den. Plateauet er fingeraftrykket, og det er let at overse, hvis du kun noterer toppen.

To kørsler af den samme fil, en direkte og en gennem tunnelen, er nok til at se, om der findes et plateau.

Læg mærke til, hvornår plateauet starter, hvor længe det varer, og hvilken hastighed det holder. De tre værdier skiller en shaper fra en overbelastet vej, for overbelastning lader hastigheden vandre, mens en shaper fastlåser den til ét tal. Hvis den direkte kørsel gradvist bliver dårligere, og tunnelkørslen holder sig stabil, ser du på politik og ikke på fysik.

Tre sammenligninger, én variabel hver

Ændr én ting per kørsel, ellers lærer du intet. Hent den samme fil ad den almindelige webvej, derefter via et overførselsværktøj, der bruger en anden port, fra en vært med sammenlignelig kapacitet og på samme time. Hold klientmaskinen fast, for en bærbar computer, der flytter sig mellem netværk, tilføjer en variabel, du ikke kan styre.

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

Brug en fil, der allerede er komprimeret, for eksempel et diskbillede, så transportkomprimering ikke kan forklare forskellen. Hvis du så styrer serveren, flyt dens lytter til den port, du mistænker for at være formet, opdater klientprofilen, og gentag. Skulle tunnelen nu falde til den formede hastighed, følger grænsen porten og ikke tunnelen, og spørgsmålet er afgjort. Kør hver sammenligning to gange, og gem plateauets tal, ikke toppene.

Noter også timen, for en shaper kan være tidsbaseret, og en aftentest kan være uenig med en morgentest. To kørsler på samme time er mere værd end ti spredt over dagen.

Hvad denne måling ikke kan understøtte

Den viser ikke, at tunnelen er hurtigere generelt, at den komprimerer noget, eller at andre porte ikke er formet. Den beskriver én overførsel på én linje i løbet af én time. Grænser kan være per session, per abonnent eller tidsbaserede, og en operatør kan ændre dem uden at annoncere det.

Den viser heller ikke, at den direkte vej er defekt. En formet vej fungerer præcis som tilsigtet, den er blot begrænset af politik.

Forskellen betyder noget, når du skriver det ned. En defekt indbyder til en reparationssag, mens en politik indbyder til et spørgsmål om kontrakten eller en beslutning om at gå uden om den. At kalde et loft for en defekt giver en supportdialog, der starter fra det forkerte præmis. At kalde det politik lader dig stille et konkret spørgsmål, som har et konkret svar.

Gør fundet til en supportanmodning

Brug tallene, og lad konklusionen ligge. En anmodning om, at store overførsler over port 80 holder sig på omkring halvdelen af den forventede hastighed i disse timer, med plateauets tal vedlagt, er handlingsdygtig. En anmodning om, at VPN er hurtigere, er det ikke, for den læses som en påstand om tunnelen i stedet for en observation om linjen. Vedlæg begge kørsler og deres tidsstempler, og lad derefter operatøren beskrive politikken.

Skub ikke hver applikation ind i tunnelen bare for at jagte det tal.

Tunnelen koster dig stadig et ekstra hop, kryptering og et nyt sæt fejltilstande, mens den begrænsede port forbliver begrænset for alt andet, der bruger den. Når store overførsler skal færdiggøres pålideligt, før din egen note om, hvilken port der bærer grænsen. At flytte en lytter til port 80 støder også sammen med enhver webserver, der allerede er bundet dertil, og det giver et nyt nedbrud i stedet for en løsning.