Kvifor ei VPN-nedlasting kan slå den direkte sambindinga di

Kopla til tunnelen, start ei stor nedlasting, og ho går om lag dobbelt så fort som den same fila klarte utan han. Det høyrest ut som reklame, men kan vere ei ekte måling på ei heimelinje. Den vanlege årsaka er ei fartsgrense knytt til éi port: tunnelen ber overføringa di dit formaren ikkje ser, og den reelle kapasiteten til linja viser seg for første gong.

Det tyder at det interessante talet ikkje er kor snøgg VPN-en var. Det er kor mykje av linja du aldri fekk, og kvifor.

Ei grense som følgjer porten, ikkje ruta

Ein tilbydar kan avgrense gjennomstrøyminga per abonnent etter protokoll eller målport, og port 80 er eit ynda mål fordi så mykje vanleg surfing brukar han. Grensa vert ofte ikkje sett frå første pakke: overføringa startar nær linjefarten, brenn opp ein burst-kvote og legg seg deretter på det avgrensa talet. Dei første sekunda ser sunne ut, resten av overføringa ikkje.

Send dei same byta over ei anna port, og formaren på 80 ser dei aldri. Tunnelen ser ut til å slå den direkte sambindinga sjølv om han har lagt til eit hopp, kryptering og sine eigne kostnader. Det som vart betre, er ikkje ruta, men fråveret av ei regel.

Det er også grunnen til at verknaden er så jamn over filer og mål. Viss grensa ligg på porten, gjer alt som vert bore på den porten det same, uansett filstorleik og kven verten er. Eit mål som dreg til seg ei anna regel, viser ei anna kurve, og den skilnaden er diagnostisk i seg sjølv.

Mål platået, ikkje toppen

Ein topp er den minst informative delen av ei overføring, fordi kvar sambinding ser bra ut medan bufferane fyllest. Noter kvar farten fell til ro og kor lenge han blir der.

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

Køyr paret rett etter kvarandre på same maskin, i same time, mot vertar på samanliknbare nett. Éin prøve beviser ingenting; forma på kurva over to køyringar av kvar er det som skil ein burst-kvote frå ei stabil grense. Skriv ned kvar farten flatar ut, ikkje kva det første sekundet viste, fordi burst er nettopp det ein formar gjev deg før han byrjar å avgrense. Eit roleg platå som held resten av overføringa ut, er talet å samanlikne.

Hald fila allereie komprimert slik at transportkomprimering ikkje kan verta bode som forklaring. Ein PDF eller eit arkiv fjernar den variabelen, og hindrar òg nokon i å hevde at tunnelen komprimerte nyttelasta. Viss båe overføringane brukar same fil, er den einaste skilnaden som står att ruta og porten. Noter verktyet og porten ved sida av kvart tal, elles er den andre køyringa ikkje samanliknbar med den første.

Tre samanlikningar som isolerer årsaka

Gå gjennom dei i rekkjefølgje, og stoppa så snart mønsteret er klart, fordi kvar av dei utelukkar ei anna historie.

1. Gjenta den same nedlastinga over den vanlege nettvegen og over eit overføringsverkty på ei anna port, frå ein vert med samanliknbar kapasitet.
2. Gjenta båe med ei inkompressibel fil, slik at komprimering sluttar å vere ein kandidat.
3. Viss du sjølv driv tunnelserveren, bind han på nytt til port 80, juster klientprofilen slik at båe endar er samde, og overfør igjen. Viss tunnelen no ligg på den avgrensa nettfarten, følgjer avgrensinga porten og ikkje VPN-en.

Det tredje trinnet er det avgjerande, og det er òg det folk hoppar over fordi det krev ei konfigurasjonsendring. Utan det har du vist at to ting er ulike, ikkje at porten er årsaka.

Kva denne målinga ikkje kan støtte

Ho viser ikkje at tunnelen er snøggare generelt, at han komprimerer noko, eller at andre portar på linja er ugrensa. Ho skildrar denne overføringa, på denne linja, i denne timen. Grenser kan gjelde per økt, per abonnent eller etter tid på døgnet, og dei kan endrast utan varsel.

Ho beviser heller ikkje at den direkte vegen er øydelagd. Ein avgrensa veg verkar framleis; han er avgrensa med vilje, og medviten politikk er ikkje ein feil som ventar på reparasjon.

Og han rettferdiggjer absolutt ikkje å rute alt gjennom tunnelen. Kvar applikasjon på port 80 vert verande avgrensa, medan alt du omdirigerer no avheng av eit ekstra hopp og ein ekstra feilmodus.

Gjer funnet om til noko ein kan handle på

Skriv observasjonen som ei måling og ikkje som ein dom: store overføringar over port 80 legg seg nær helvta av farten den same fila når på ei anna port, i desse timane, på denne linja, med desse prøvene vedlagde. Det er ei støtteførespurnad nokon kan undersøkje.

«VPN-en er snøggare» er det ikkje. Det inviterer til eit svar om krypteringskostnader, og det svaret er teknisk riktig medan det ikkje fortel nokon noko nyttig. Legg ved talet på prøver, timen og porten, slik at lesaren kan gjenskape mønsteret.

Viss du vel å halde fram med å bruke ein annan port til store overføringar, noter atterhaldet i eigne notat: å flytte ein lyttar til port 80 kolliderer med kvar webserver som allereie er bunden der, og feilen som følgjer, ser ut som ein øydelagd tunnel og ikkje som ein portkonflikt.