Waarom een VPN traag aanvoelt tijdens uploaden: wachtrijvertraging

Een back-up begint te uploaden, de overdrachtsteller ziet er gezond uit, en het videogesprek verandert in pap. De verbinding heeft geen gebrek aan bandbreedte in de zin die dat getal suggereert; pakketten wachten ergens in een wachtrij en de interactieve staan achter bulkgegevens. Dat is wachtrijvertraging, gewoonlijk bufferbloat genoemd. Een VPN kan zijn eigen wachtrij toevoegen, maar veroorzaakt het probleem zelden alleen.

Bandbreedte en vertraging zijn verschillende metingen

Doorvoer beantwoordt hoeveel data per seconde beweegt, terwijl vertraging beantwoordt hoe lang één pakket nodig heeft om het pad over te steken. Een verzadigde verbinding kan een grote achterstand vasthouden en toch goede doorvoer melden, omdat de wachtrij met lijnsnelheid leegloopt zodra de uitbarsting voorbij is. Interactief verkeer lijdt het eerst, omdat een gesprek elke paar milliseconden een pakket nodig heeft, niet uiteindelijk een groot bestand. Alleen een speedtestresultaat meten verbergt dus het symptoom dat je deed kijken.

Let ook op de richting onder belasting. Een volle uploadbuffer kan al het andere vertragen terwijl de downloadcapaciteit ongebruikt blijft.

Meet de retourtijd onder belasting

Neem een basislijn op een rustige verbinding en herhaal dan dezelfde meting terwijl één gecontroleerde overdracht loopt. Vergelijk de twee runs in plaats van de absolute getallen.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

De eerste opdracht bemonstert de retourtijd, en de tweede maakt een aanhoudende upload zonder een speedtestdienst nodig te hebben. Een basislijn die vlak blijft, gevolgd door een belaste run die met honderden milliseconden stijgt, is het patroon waarnaar je moet zoeken. Sommige netwerken verlagen de prioriteit van ICMP, dus behandel ping als een aanwijzing en bevestig met de eigen latentieweergave van de toepassing. Houd de test kort op verbindingen met een datalimiet, want een herhaalbaar contrast telt meer dan een lange verzadiging.

Verplaats de wachtrij naar waar de flessenhals is

Wachtrijbeheer helpt alleen op het apparaat dat de achterstand echt vasthoudt. Inspecteer wat de interface doet voordat je regels toevoegt.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

De opdracht show rapporteert de huidige discipline plus tellers voor achterstand en drops, wat je vertelt of deze interface de flessenhals is of alleen verkeer doorlaat. De worteldiscipline vervangen door een eerlijk wachtrijalgoritme geeft korte stromen hun eigen beurt in plaats van één FIFO die met bulkgegevens wordt gedeeld. Pas het toe op de WAN-interface van de router wanneer de router de flessenhals is, niet uit gewoonte op het tunnelapparaat. Bewaar de vorige configuratie en test zowel de responsiviteit onder belasting als de overdrachtssnelheid opnieuw, want een iets lagere bulksnelheid is een goede ruil voor bruikbare gesprekken.

Wat de tunnel verandert en wat hij verbergt

Een VPN voegt versleuteling en een extra hop toe, en verbergt ook afzonderlijke stromen voor apparatuur buiten de tunnel. Dat maakt uit wanneer een apparaat stroomopwaarts prioriteit per toepassing biedt, omdat het versleutelde pakketten ziet in plaats van de oorspronkelijke gesprekken. Een router die de tunnel zelf beëindigt, heeft een ander zicht en andere werklast en kan erbinnen classificeren. Geen van beide opstellingen verwijdert de wachtrij op de toegangsverbinding, waar de vertraging zich meestal ophoopt.

Als de vertraging de belasting niet volgt, stop dan met het afstellen van wachtrijen en kijk elders: Wi-Fi-omstandigheden, problemen met pakketgrootte of één slechte uitgang. Wachtrijinstellingen die zonder meting worden toegepast, verplaatsen alleen het raadsel.