Waarom een VPN-download beperkt wordt door de upload van de server

De client toont een snelle downlink, de server zit op een glasvezelverbinding en de overdracht kruipt toch. Het getal dat mensen vergelijken is meestal dat op het abonnement van de client, terwijl het pakket in werkelijkheid eerst de uitgaande toegangslink van de server oversteekt. Die link is het budget waarbinnen de overdracht moet passen. Op een kleine thuisverbinding is het het kleinste getal in het pad.

Het getal dat u las, stond in de verkeerde richting

Een download naar een externe client verbruikt uploadcapaciteit aan de serverkant van de tunnel. De geadverteerde downloadsnelheden van de server beschrijven de tegenovergestelde richting en zeggen niets over deze. Dezelfde asymmetrie keert om wanneer de client uploadt, waardoor de ene richting goed kan aanvoelen terwijl de andere onbruikbaar is.

Inkapselingskosten en al het concurrerende verkeer verbruiken een deel van hetzelfde budget. Geen van beide is zichtbaar in een snelheidstest die alleen de client meet.

Schrijf het pad als een budget

Som elke grens op die het pakket moet oversteken en geef elk een getal in dezelfde eenheid. Levering vanaf de bron, verwerking op de server, de uplink van de server, het tussenliggende pad, de downlink van de client en de verwerking op de client gelden allemaal. De bruikbare snelheid is de kleinste daarvan minus kosten, en geen enkele afstelling boven dat plafond verandert de uitkomst. Schrijf de lijst op voordat u meet, want die zegt u welk getal u niet moet geloven.

Met een uplink van de server van 20 Mbit/s en een downlink van de client van 100 Mbit/s beperkt de server de overdracht lang voordat de client het merkt. Kosten en elke gelijktijdige overdracht nemen een extra deel, en een verzadigde uplink vertraagt ook bevestigingen, wat een TCP-overdracht onder het ruwe plafond brengt. Geen van de twee effecten verschijnt in een abonnementsvergelijking.

Houd megabits en megabytes apart en zeg of elk getal het verkeer van de versleutelde link of de toepassingspayload meet. Die twee door elkaar halen is de meest voorkomende reden dat een budget niet lijkt te kloppen. Label elk getal met zijn eenheid en zijn meetpunt.

Waar het bord u echt geld kost

Zodra de toegangslink groot genoeg is, wordt de hardware van het eindpunt zichtbaar, en pas dan doet de processor ertoe. Identificeer het model, de indeling van de interfaces en de gebruikte implementatie. Een observatie over een gedeelde bus van een vroeg bord beschrijft niet elke latere revisie.

Vergelijk afzonderlijke verwerkingspaden in plaats van één CPU-gemiddelde. Een matige totale belasting kan één verzadigde kern verbergen die al het werk per pakket doet, en klokfrequentie gaat niet als prestatiescore over tussen processorontwerpen. De pakketsnelheid is even belangrijk als de doorvoer, omdat kleine pakketten per byte meer kosten dan grote. Meet met de pakketgroottes die uw werklast werkelijk gebruikt.

Thermische en vermogensgrenzen bepalen ook het gedrag op de lange termijn. Een korte uitbarsting kan er uitstekend uitzien terwijl een overdracht van tien minuten afknijpt, en daarom is een benchmark van een paar seconden een slechte gids voor een nachtelijke back-up.

De prestatie-richtlijnen van de leverancier scheiden toegangsbandbreedte, CPU, pakketverwerking, transport en pakketgrootte in afzonderlijke beperkingen. Het loont ze te lezen voordat u een cijfer wijzigt, want een cijferwijziging verschuift zelden een grens die nooit de beperking was.

Meet voordat u een cijfer wijzigt

Voer een gerichte test uit die de snelheid rapporteert die daadwerkelijk door de tunnel wordt gehaald, en voer daarna dezelfde test uit op de ruwe interface ter vergelijking. Het verschil tussen die twee getallen is de kosten van de tunnel, en het kleinste van de twee plafonds zegt u welke grens u moet aanvallen.

Houd het beveiligingsbeleid intact terwijl u vergelijkt. Een oud resultaat met een zwak cijfer of een overgeklokt bord is geen plan voor de huidige uitrol.

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

Bewaar de gerichte resultaten naast de eindpuntwaarnemingen van dezelfde run. De volgende wijziging moet zich richten op het gemeten plafond in plaats van op de component die op het specblad het kleinst lijkt.