Hvorfor en VPN-nedlasting begrenses av serverens opplasting

Klienten viser en rask nedlastingslinje, serveren sitter på en fiberforbindelse, og overføringen krabber likevel. Tallet folk sammenligner, er vanligvis det som står på klientens abonnement, mens pakken faktisk først krysser serverens utgående tilgangslinje. Den linjen er budsjettet overføringen må passe inn i. På en liten hjemmeforbindelse er det det minste tallet i banen.

Tallet du leste var i feil retning

En nedlasting mot en ekstern klient bruker opplastingskapasitet i serverenden av tunnelen. De annonserte nedlastingshastighetene til serveren beskriver motsatt retning og sier ingenting om denne. Den samme asymmetrien snur når klienten laster opp, og derfor kan én retning føles fin mens den andre er ubrukelig.

Innkapslingskostnader og all konkurrerende trafikk bruker en del av det samme budsjettet. Ingen av dem er synlige i en hastighetstest som bare måler klienten.

Skriv banen som et budsjett

List opp hver grense pakken må krysse, og gi hver av dem et tall i samme enhet. Levering fra kilden, behandling på serveren, serverens opplastingslinje, mellombanen, klientens nedlastingslinje og behandlingen på klienten gjelder alle. Den brukbare hastigheten er den minste av dem minus kostnader, og ingen justering over det taket endrer resultatet. Skriv ned listen før du måler, fordi den forteller deg hvilket tall du ikke skal tro på.

Med en opplastingslinje på serveren på 20 Mbit/s og en nedlastingslinje på klienten på 100 Mbit/s begrenser serveren overføringen lenge før klienten merker det. Kostnader og enhver samtidig overføring tar en ytterligere del, og en mettet opplastingslinje forsinker også kvitteringer, noe som gjør en TCP-overføring tregere enn det rå taket. Ingen av de to effektene vises i en abonnementssammenligning.

Hold megabit og megabyte fra hverandre, og si om hvert tall måler trafikk på den krypterte linjen eller nyttelasten til applikasjonen. Å blande de to er den vanligste grunnen til at et budsjett ser ut til å ikke gå opp. Merk hvert tall med enheten og målepunktet.

Hvor hovedkortet faktisk koster deg

Når tilgangslinjen er stor nok, blir maskinvaren i endepunktet synlig, og først da betyr prosessoren noe. Identifiser modellen, oppsettet av grensesnitt og implementasjonen som brukes. En observasjon om en delt buss på et tidlig hovedkort beskriver ikke hver senere revisjon.

Sammenlign individuelle behandlingsbaner i stedet for ett enkelt CPU-gjennomsnitt. En moderat total belastning kan skjule én mettet kjerne som gjør alt arbeidet per pakke, og klokkefrekvens overføres ikke mellom prosessordesign som en ytelsesscore. Pakkehastigheten betyr like mye som gjennomstrømningen, fordi små pakker koster mer per byte enn store. Mål med pakkestørrelsene arbeidsbelastningen din faktisk bruker.

Termiske og effektmessige grenser avgjør også den vedvarende oppførselen. En kort byge kan se utmerket ut mens en overføring på ti minutter strupes, og derfor er en benchmark på noen sekunder en dårlig veileder for en nattlig sikkerhetskopi.

Leverandørens ytelsesveiledning skiller tilgangsbåndbredde, CPU, pakkebehandling, transport og pakkestørrelse i ulike begrensninger. Det er verdt å lese den før du endrer et chiffer, fordi en chifferendring sjelden flytter en grense som aldri var begrensningen.

Mål før du endrer et chiffer

Kjør en retningsbestemt test som rapporterer hastigheten som faktisk oppnås gjennom tunnelen, og kjør deretter den samme testen på det rå grensesnittet for sammenligning. Forskjellen mellom de to tallene er kostnaden ved tunnelen, og det minste av de to takene forteller deg hvilken grense du skal angripe.

Hold sikkerhetspolicyen intakt mens du sammenligner. Et gammelt resultat oppnådd med et svakt chiffer eller et overklokket hovedkort er ikke en plan for den nåværende utrullingen.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Lagre de retningsbestemte resultatene ved siden av endepunktsobservasjonene fra samme kjøring. Den neste endringen bør rette seg mot det målte taket i stedet for komponenten som ser minst ut på databladet.