Varför en VPN-nedladdning begränsas av serverns uppladdning

Klienten visar en snabb nedlänk, servern sitter på en fiberanslutning och överföringen kryper ändå. Talet folk jämför är oftast det som står på klientens abonnemang, medan paketet faktiskt först korsar serverns utgående åtkomstlänk. Den länken är budgeten som överföringen måste rymmas i. På en liten hemanslutning är det det minsta talet i banan.

Talet du läste var i fel riktning

En nedladdning mot en fjärrklient förbrukar uppladdningskapacitet i serverns ände av tunneln. Serverns annonserade nedladdningshastigheter beskriver motsatt riktning och säger ingenting om den här. Samma asymmetri vänder när klienten laddar upp, vilket är varför en riktning kan kännas bra medan den andra är oanvändbar.

Inkapslingskostnader och all konkurrerande trafik förbrukar en del av samma budget. Ingen av dem syns i ett hastighetstest som bara mäter klienten.

Skriv banan som en budget

Lista varje gräns paketet måste passera och ge var och en ett tal i samma enhet. Leverans från källan, bearbetning på servern, serverns upplänk, mellanbanan, klientens nedlänk och bearbetningen på klienten gäller alla. Den användbara hastigheten är den minsta av dem minus kostnader, och ingen inställning ovanför det taket ändrar resultatet. Skriv ner listan före mätningen, för den säger vilket tal du inte ska tro på.

Med en upplänk på servern på 20 Mbit/s och en nedlänk på klienten på 100 Mbit/s begränsar servern överföringen långt innan klienten märker det. Kostnader och varje samtidig överföring tar ytterligare en del, och en mättad upplänk fördröjer också bekräftelser, vilket gör en TCP-överföring långsammare än det råa taket. Ingen av de två effekterna syns i en abonnemangsjämförelse.

Håll megabit och megabyte isär och säg om varje tal mäter trafiken på den krypterade länken eller applikationens nyttolast. Att blanda de två är den vanligaste orsaken till att en budget verkar inte gå ihop. Märk varje tal med dess enhet och mätpunkt.

Där kortet faktiskt kostar dig

När åtkomstlänken är stor nog blir hårdvaran i ändpunkten synlig, och först då spelar processorn roll. Identifiera modellen, gränssnittens ordning och den implementering som används. En observation om en delad buss på ett tidigt kort beskriver inte varje senare revision.

Jämför enskilda bearbetningsvägar i stället för ett enda CPU-genomsnitt. En måttlig total belastning kan dölja en mättad kärna som gör allt arbete per paket, och klockfrekvens överförs inte mellan processor konstruktioner som en prestandapoäng. Pakethastigheten betyder lika mycket som genomströmningen, eftersom små paket kostar mer per byte än stora. Mät med de paketstorlekar din arbetsbelastning faktiskt använder.

Termiska gränser och effektgränser avgör också det varaktiga beteendet. En kort burst kan se utmärkt ut medan en överföring på tio minuter stryps, och därför är ett benchmark på några sekunder en dålig vägledning för en nattlig säkerhetskopiering.

Leverantörens prestandariktlinjer skiljer åtkomstbandbredd, CPU, paketbearbetning, transport och paketstorlek i olika begränsningar. Det är värt att läsa dem innan du byter chiffer, eftersom ett chifferbyte sällan flyttar en gräns som aldrig var begränsningen.

Mät innan du byter chiffer

Kör ett riktat test som rapporterar den hastighet som faktiskt uppnås genom tunneln och kör sedan samma test på det råa gränssnittet för jämförelse. Skillnaden mellan de två talen är kostnaden för tunneln, och det minsta av de två taken säger vilken gräns du ska angripa.

Håll säkerhetspolicyn intakt medan du jämför. Ett gammalt resultat med ett svagt chiffer eller ett överklockat kort är ingen plan för den nuvarande driftsättningen.

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

Spara de riktade resultaten bredvid ändpunktsobservationerna från samma körning. Nästa ändring bör rikta sig mot det uppmätta taket i stället för komponenten som ser minst ut på databladet.