Hvorfor en nedlasting er raskere over VPN enn direkte

Du starter en stor nedlasting, de første sekundene ser normale ut, og så stabiliserer hastigheten seg på omtrent halvparten av det linjen skal levere. Du kobler til tunnelen, gjentar den samme nedlastingen, og den holder en høyere hastighet gjennom hele filen. Det er en reell måling og en misvisende konklusjon samtidig, fordi tunnelen ikke gjorde veien raskere. Den flyttet bare trafikken din bort fra en port som noe underveis begrenset.

Formen på kurven avslører det

Se på overføringen i stedet for sluttallet. En begrenset vei begynner vanligvis nær linjehastigheten, bruker opp burst-kvoten og legger seg deretter på grensen, så gjennomsnittet avhenger av hvor lenge du så på. En tunnel som virkelig forbedret veien, ville vist en bedre hastighet fra første sekund og holdt den. Platået er fingeravtrykket, og det er lett å overse hvis du bare noterer toppen.

To kjøringer av samme fil, én direkte og én gjennom tunnelen, er nok til å se om det finnes et platå.

Legg merke til når platået starter, hvor lenge det varer og hvilken hastighet det holder. De tre verdiene skiller en shaper fra en overbelastet vei, for overbelastning lar hastigheten vandre mens en shaper fester den til ett tall. Hvis den direkte kjøringen gradvis blir dårligere og tunnelkjøringen holder seg stabil, ser du på politikk og ikke fysikk.

Tre sammenligninger, én variabel hver

Endre én ting per kjøring, ellers lærer du ingenting. Hent samme fil over den vanlige nettveien, deretter via et overføringsverktøy som bruker en annen port, fra en vert med sammenlignbar kapasitet og på samme time. Hold klientmaskinen fast, for en bærbar PC som flytter seg mellom nettverk legger til en variabel du ikke kan kontrollere.

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

Bruk en fil som allerede er komprimert, for eksempel et diskbilde, slik at transportkomprimering ikke kan forklare forskjellen. Deretter, hvis du kontrollerer serveren, flytt lytteren til porten du mistenker er formet, oppdater klientprofilen og gjenta. Skulle tunnelen nå falle til den formede hastigheten, følger grensen porten og ikke tunnelen, og spørsmålet er avgjort. Kjør hver sammenligning to ganger og ta vare på platåtallene, ikke toppene.

Noter også timen, for en shaper kan være tidsbasert, og en kveldstest kan være uenig med en morgentest. To kjøringer på samme time er verdt mer enn ti spredt over dagen.

Hva denne målingen ikke kan støtte

Den viser ikke at tunnelen er raskere generelt, at den komprimerer noe, eller at andre porter ikke er formet. Den beskriver én overføring på én linje i løpet av én time. Grensene kan være per sesjon, per abonnent eller tidsbaserte, og en operatør kan endre dem uten å varsle.

Den viser heller ikke at den direkte veien er defekt. En formet vei fungerer nøyaktig som tiltenkt, den er bare begrenset av politikk.

Den forskjellen betyr noe når du skriver det opp. En feil inviterer til en reparasjonssak, mens en politikk inviterer til et spørsmål om kontrakten eller en beslutning om å gå utenom den. Å kalle et tak for en feil gir en støttesamtale som starter fra feil premiss. Å kalle det politikk lar deg stille et konkret spørsmål som har et konkret svar.

Gjør funnet om til en støtteforespørsel

Bruk tallene og dropp konklusjonen. En forespørsel som sier at store overføringer over port 80 holder seg på rundt halvparten av forventet hastighet i disse timene, med platåtallene vedlagt, er handlingsdyktig. En forespørsel som sier at VPN er raskere, er det ikke, fordi den leses som en påstand om tunnelen i stedet for en observasjon om linjen. Legg ved begge kjøringene og tidsstemplene deres, og la deretter operatøren beskrive politikken.

Ikke dytt hver applikasjon inn i tunnelen bare for å jage det tallet.

Tunnelen koster deg fortsatt et ekstra hopp, kryptering og et nytt sett feilmoduser, mens den begrensede porten forblir begrenset for alt annet som bruker den. Når store overføringer må fullføres pålitelig, før din egen notat om hvilken port som bærer grensen. Å flytte en lytter til port 80 kolliderer også med enhver webserver som allerede er bundet til den, og det gir et nytt avbrudd i stedet for en løsning.