Hvorfor en VPN-download kan slå din direkte forbindelse

Forbind tunnelen, start en stor download, og den kører med omtrent det dobbelte af den hastighed, den samme fil klarede uden den. Det lyder som reklame, men det kan være en ægte måling på en privat linje. Den sædvanlige årsag er en hastighedsgrænse knyttet til én port: tunnelen bærer din overførsel et sted, hvor shaperen ikke kigger, og linjens reelle kapacitet viser sig for første gang.

Hvilket betyder, at det interessante tal ikke er, hvor hurtig VPN’en var. Det er, hvor meget af din linje du aldrig fik, og hvorfor.

En grænse, der følger porten, ikke ruten

En adgangsudbyder kan begrænse gennemstrømningen pr. abonnent efter protokol eller destinationsport, og port 80 er et yndet mål, fordi så meget almindelig browsing bruger den. Grænsen anvendes ofte ikke fra den første pakke: overførslen begynder nær linjehastighed, brænder en burst-kvote af og sætter sig derefter på det begrænsede tal. De første sekunder ser sunde ud, og resten af overførslen gør ikke.

Send de samme bytes over en anden port, og shaperen på 80 ser dem aldrig. Tunnelen ser ud til at slå den direkte forbindelse, selvom den har tilføjet et hop, kryptering og sine egne omkostninger. Det, der blev bedre, er ikke ruten, men fraværet af en regel.

Det er også derfor, effekten er så ensartet på tværs af filer og destinationer. Hvis grænsen ligger på porten, opfører alt, der bæres på den port, sig ens, uanset filstørrelse og hvem værten er. En destination, der tiltrækker en anden regel, viser en anden kurve, og den forskel er diagnostisk i sig selv.

Mål plateauet, ikke toppen

En top er den mindst informative del af en overførsel, fordi hver forbindelse ser god ud, mens dens buffere fyldes. Noter, hvor hastigheden falder til ro, og hvor længe den bliver der.

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

Kør parret lige efter hinanden på samme maskine, i samme time, mod værter på sammenlignelige netværk. En enkelt prøve beviser intet; kurvens form over to kørsler af hver er det, der skelner en burst-kvote fra en stabil grænse. Skriv ned, hvor hastigheden flader ud, i stedet for hvad det første sekund viste, for burst er netop det, en shaper giver dig, før den begynder at begrænse. Et roligt plateau, der holder resten af overførslen ud, er tallet at sammenligne.

Hold filen allerede komprimeret, så transportkomprimering ikke kan tilbydes som forklaring. En PDF eller et arkiv fjerner den variabel og forhindrer også nogen i at hævde, at tunnelen har presset nyttelasten. Hvis begge overførsler bruger samme fil, er den eneste forskel tilbage ruten og porten. Noter værktøjet og porten ved siden af hvert tal, ellers er den anden kørsel ikke sammenlignelig med den første.

Tre sammenligninger, der isolerer årsagen

Gå dem igennem i rækkefølge, og stop, så snart mønstret er klart, fordi hver af dem udelukker en anden historie.

1. Gentag den samme download over den almindelige webvej og over et overførselsværktøj på en anden port, fra en vært med sammenlignelig kapacitet.
2. Gentag begge med en inkompressibel fil, så komprimering holder op med at være en kandidat.
3. Hvis du selv driver tunnelserveren, så bind den igen til port 80, juster klientprofilen, så begge ender er enige, og overfør igen. Hvis tunnelen nu ligger på den begrænsede webhastighed, følger begrænsningen porten og ikke VPN’en.

Det tredje trin er det afgørende, og det er også det, folk springer over, fordi det kræver en konfigurationsændring. Uden det har du vist, at to ting er forskellige, ikke at porten er årsagen.

Hvad denne måling ikke kan understøtte

Den viser ikke, at tunnelen er hurtigere generelt, at den komprimerer noget, eller at andre porte på linjen er ubegrænsede. Den beskriver denne overførsel, på denne linje, i denne time. Grænser kan anvendes pr. session, pr. abonnent eller efter tid på dagen, og de kan ændre sig uden varsel.

Den beviser heller ikke, at den direkte vej er brudt. En begrænset vej virker stadig; den er begrænset med vilje, og bevidst politik er ikke en fejl, der venter på en reparation.

Og den retfærdiggør bestemt ikke at rute alt gennem tunnelen. Hver applikation på port 80 forbliver begrænset, mens alt, hvad du omdirigerer, nu afhænger af et ekstra hop og en ekstra fejlmåde.

Gør fundet til noget, der kan handles på

Skriv observationen som en måling i stedet for en dom: store overførsler over port 80 sætter sig nær halvdelen af den hastighed, den samme fil når på en anden port, i disse timer, på denne linje, med disse prøver vedlagt. Det er en supportanmodning, som nogen kan undersøge.

„VPN’en er hurtigere“ er det ikke. Det inviterer til et svar om krypteringsomkostninger, og det svar er teknisk korrekt, mens det ikke fortæller nogen noget brugbart. Vedlæg antallet af prøver, timen og porten, så læseren kan genskabe mønstret.

Hvis du beslutter at fortsætte med at bruge en anden port til store overførsler, så noter forbeholdet i dine egne optegnelser: at flytte en lytter til port 80 kolliderer med enhver webserver, der allerede er bundet der, og den resulterende fejl ser ud som en brudt tunnel snarere end en portkonflikt.