Hvorfor en VPN-nedlasting kan slå den direkte forbindelsen din

Koble til tunnelen, start en stor nedlasting, og den går omtrent dobbelt så raskt som den samme filen klarte uten den. Det høres ut som reklame, men kan være en ekte måling på en hjemmelinje. Den vanlige årsaken er en hastighetsgrense knyttet til én port: tunnelen bærer overføringen din dit formingsenheten ikke ser, og linjens reelle kapasitet viser seg for første gang.

Det betyr at det interessante tallet ikke er hvor rask VPN-en var. Det er hvor mye av linjen du aldri fikk, og hvorfor.

En grense som følger porten, ikke ruten

En tilbyder kan begrense gjennomstrømningen per abonnent etter protokoll eller destinasjonsport, og port 80 er et yndet mål fordi så mye vanlig surfing bruker den. Grensen settes ofte ikke fra første pakke: overføringen starter nær linjehastigheten, brenner opp en burst-kvote og legger seg deretter på det begrensede tallet. De første sekundene ser sunne ut, resten av overføringen ikke.

Send de samme bytene over en annen port, og formingsenheten på 80 ser dem aldri. Tunnelen ser ut til å slå den direkte forbindelsen selv om den har lagt til et hopp, kryptering og sine egne kostnader. Det som ble bedre, er ikke ruten, men fraværet av en regel.

Det er også grunnen til at effekten er så jevn på tvers av filer og mål. Hvis grensen ligger på porten, oppfører alt som bæres på den porten seg likt, uansett filstørrelse og hvem verten er. Et mål som trekker til seg en annen regel, viser en annen kurve, og den forskjellen er diagnostisk i seg selv.

Mål platået, ikke toppen

En topp er den minst informative delen av en overføring, fordi hver forbindelse ser bra ut mens bufferne fylles. Noter hvor hastigheten faller til ro og hvor lenge den blir der.

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

Kjør paret rett etter hverandre på samme maskin, i samme time, mot verter på sammenlignbare nett. Én prøve beviser ingenting; formen på kurven over to kjøringer av hver er det som skiller en burst-kvote fra en stabil grense. Skriv ned hvor hastigheten flater ut, ikke hva det første sekundet viste, fordi burst er nettopp det en formingsenhet gir deg før den begynner å begrense. Et rolig platå som holder resten av overføringen ut, er tallet å sammenligne.

Hold filen allerede komprimert slik at transportkomprimering ikke kan tilbys som forklaring. En PDF eller et arkiv fjerner den variabelen, og hindrer også noen i å hevde at tunnelen komprimerte nyttelasten. Hvis begge overføringene bruker samme fil, er den eneste forskjellen som gjenstår ruten og porten. Noter verktøyet og porten ved siden av hvert tall, ellers er den andre kjøringen ikke sammenlignbar med den første.

Tre sammenligninger som isolerer årsaken

Gå gjennom dem i rekkefølge, og stopp så snart mønsteret er klart, fordi hver av dem utelukker en annen historie.

1. Gjenta den samme nedlastingen over den vanlige nettveien og over et overføringsverktøy på en annen port, fra en vert med sammenlignbar kapasitet.
2. Gjenta begge med en inkompressibel fil, slik at komprimering slutter å være en kandidat.
3. Hvis du selv driver tunnelserveren, bind den på nytt til port 80, juster klientprofilen slik at begge ender er enige, og overfør igjen. Hvis tunnelen nå ligger på den begrensede netthastigheten, følger begrensningen porten og ikke VPN-en.

Det tredje trinnet er det avgjørende, og det er også det folk hopper over fordi det krever en konfigurasjonsendring. Uten det har du vist at to ting er forskjellige, ikke at porten er årsaken.

Hva denne målingen ikke kan støtte

Den viser ikke at tunnelen er raskere generelt, at den komprimerer noe, eller at andre porter på linjen er ubegrensede. Den beskriver denne overføringen, på denne linjen, i denne timen. Grenser kan gjelde per økt, per abonnent eller etter tid på døgnet, og de kan endres uten varsel.

Den beviser heller ikke at den direkte veien er ødelagt. En begrenset vei virker fortsatt; den er begrenset med vilje, og bevisst politikk er ikke en feil som venter på reparasjon.

Og den rettferdiggjør absolutt ikke å rute alt gjennom tunnelen. Hver applikasjon på port 80 forblir begrenset, mens alt du omdirigerer nå avhenger av et ekstra hopp og en ekstra feilmodus.

Gjør funnet om til noe som kan handles på

Skriv observasjonen som en måling og ikke som en dom: store overføringer over port 80 legger seg nær halvparten av hastigheten den samme filen når på en annen port, i disse timene, på denne linjen, med disse prøvene vedlagt. Det er en støtteforespørsel noen kan undersøke.

«VPN-en er raskere» er det ikke. Det inviterer til et svar om krypteringskostnader, og det svaret er teknisk riktig mens det ikke forteller noen noe nyttig. Legg ved antall prøver, timen og porten, slik at leseren kan gjenskape mønsteret.

Hvis du bestemmer deg for å fortsette å bruke en annen port til store overføringer, noter forbeholdet i egne notater: å flytte en lytter til port 80 kolliderer med enhver webserver som allerede er bundet der, og feilen som følger, ser ut som en ødelagt tunnel og ikke som en portkonflikt.