Hvorfor et VPN-download begrænses af serverens upload

Klienten viser et hurtigt downlink, serveren sidder på en fiberforbindelse, og overførslen kravler stadig. Det tal, folk sammenligner, er normalt det, der står på klientens plan, mens pakken faktisk først krydser serverens udgående adgangslinje. Den linje er det budget, overførslen skal passe ind i. På en lille hjemmeforbindelse er det det mindste tal på vejen.

Det tal, du læste, var den forkerte retning

Et download mod en fjern klient bruger uploadkapacitet i serverenden af tunnelen. De annoncerede downloadhastigheder for serveren beskriver den modsatte retning og siger intet om denne. Den samme asymmetri vender, når klienten uploader, og derfor kan den ene retning føles fin, mens den anden er ubrugelig.

Indkapslingsomkostninger og enhver konkurrerende trafik bruger en del af samme budget. Ingen af dem er synlige i en hastighedstest, der kun måler klienten.

Skriv vejen som et budget

List hver grænse, pakken skal krydse, og giv hver en talværdi i samme enhed. Levering fra kilden, serverbehandling, serverens uplink, mellemvejen, klientens downlink og klientens behandling gælder alle. Den brugbare hastighed er den mindste af dem minus omkostninger, og ingen tuning over det loft ændrer resultatet. Skriv listen ned før målingen, fordi den fortæller dig, hvilket tal du ikke skal tro på.

Med et server-uplink på 20 Mbit/s og et klient-downlink på 100 Mbit/s begrænser serveren overførslen længe før, klienten bemærker det. Omkostninger og enhver samtidig overførsel tager endnu en bid, og et mættet uplink forsinker også kvitteringer, hvilket gør en TCP-overførsel langsommere end det rå loft. Ingen af de to effekter vises i en plansammenligning.

Hold megabit og megabyte adskilt, og sig, om hvert tal måler krypteret linjetrafik eller applikationsnyttelast. At blande de to er den mest almindelige grund til, at et budget ser ud til ikke at gå op. Mærk hvert tal med dets enhed og målepunkt.

Hvor bundkortet faktisk koster dig

Når adgangslinjen er stor nok, bliver endpoint-hardwaren synlig, og først da betyder processoren noget. Identificér modellen, grænsefladeopstillingen og den anvendte implementering. En observation om et tidligt bundkorts delte bus beskriver ikke enhver senere revision.

Sammenlign individuelle behandlingsveje i stedet for et enkelt CPU-gennemsnit. En moderat samlet belastning kan skjule én mættet kerne, der udfører alt arbejdet pr. pakke, og urfrekvens overføres ikke mellem processordesigns som en ydelsesscore. Pakkehastigheden betyder lige så meget som gennemstrømningen, fordi små pakker koster mere pr. byte end store. Mål med de pakkestørrelser, din arbejdsbyrde faktisk bruger.

Termiske og effektmæssige grænser bestemmer også den vedvarende adfærd. En kort byge kan se fremragende ud, mens en ti minutters overførsel throttler, og derfor er en benchmark på få sekunder en dårlig rettesnor for en natlig sikkerhedskopiering.

Leverandørens ydelsesvejledning adskiller adgangsbåndbredde, CPU, pakkebehandling, transport og pakkestørrelse i forskellige begrænsninger. Det er værd at læse den, før du ændrer en cipher, fordi en cipherændring sjældent flytter en grænse, der aldrig var grænsen.

Mål, før du ændrer en cipher

Kør en retningsbestemt test, der rapporterer den hastighed, der faktisk opnås gennem tunnelen, og kør derefter den samme test på den rå grænseflade til sammenligning. Forskellen mellem de to tal er omkostningen ved tunnelen, og det mindste af de to lofter fortæller dig, hvilken grænse du skal angribe.

Hold sikkerhedspolitikken intakt, mens du sammenligner. Et gammelt resultat opnået med en svag cipher eller et overclocket bundkort er ikke en plan for den nuværende udrulning.

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

Gem de retningsbestemte resultater ved siden af endpoint-observationerne fra samme kørsel. Den næste ændring bør sigte mod det målte loft snarere end den komponent, der ser mindst ud på databladet.