Waarom twee VPN-snelheidstests op dezelfde tunnel niet overeenkomen

Twee runs, één tunnel, en de cijfers verschillen een factor drie. De tunnel veranderde niet tussen beide. Wat veranderde, is de meting: een testsite die een server kiest op basis van je schijnbare locatie, een aantal streams dat bepaalt of één trage start of zes de buis vullen, en een duur die kort genoeg is om te eindigen voordat het pad überhaupt goed wordt gebruikt. Snelheidstests zijn niet fout, maar ze beantwoorden een engere vraag dan die mensen ze stellen.

Een nieuw exitadres verandert de testbestemming

De meeste testsites kiezen automatisch een meetserver, en ze kiezen die deels door te kijken waar je verbinding vandaan lijkt te komen. Zet de tunnel aan en je schijnbare land verandert, dus de gekozen server verandert, en de vergelijking bestrijkt nu twee verschillende routes naar twee verschillende hosts.

Het resultaat is helemaal geen VPN-meting. Het is een meting van jouw pad naar een server die je niet hebt gekozen, en het verschil tussen de twee runs kan worden bepaald door de peering van die server in plaats van door wat de tunnel deed.

Leg de bestemming vast voordat je iets anders verandert. Elk geloofwaardig gereedschap laat je expliciet een server kiezen, en als het dat niet doet, noemt de resultatenpagina meestal de gebruikte, wat genoeg is om te merken dat de twee runs niet vergelijkbaar zijn. Controleer wat de site zag voordat je op zijn keuze vertrouwt:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Is het land tussen de runs veranderd, dan is alles wat de test daarna koos ook veranderd. Schrijf de waargenomen exit naast elk resultaat en de verwarring verdwijnt grotendeels.

Trage start eindigt nadat de meeste korte tests voorbij zijn

Een TCP-verbinding begint niet op de lijnsnelheid. Ze begint met een klein congestievenster, verdubbelt dat ongeveer per retourvlucht, en bereikt pas na meerdere retourvluchten de capaciteit van het pad. Een test van tien seconden op een pad met hoge latentie kan een flink deel van zijn leven in die aanloop doorbrengen.

Daarom scoort een tunnel met meer latentie slechter op een korte test dan hij verdient, en daarom rapporteert een langere run vaak een hoger getal zonder enige configuratiewijziging. De doorvoerstructuur RFC 6349 behandelt dit expliciet, en daarom duren serieuze metingen lang genoeg om een stabiele toestand te bereiken. Een run van vijf seconden op een satellietpad meet de versneller, niet de weg.

Kijk naar de fasen van de verbinding in plaats van één getal te vertrouwen. Curl rapporteert elke fase apart, zodat je kunt zien of de tijd naar de handshake, de aanloop of de overdracht gaat:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Draai het twee keer achter elkaar naar dezelfde bestemming. Is de tweede run veel sneller, dan mat je de aanloop, niet het pad, en elke vergelijking die alleen de eerste run gebruikte, is verdacht.

Eén stream en zes streams meten verschillende dingen

Een enkele TCP-stream wordt beperkt door het venster dat hij in de lucht kan houden, ongeveer de retourvluchttijd keer de snelheid. Op een lang pad overtreft dat product wat één stream gebruikt, dus één download rapporteert minder dan de capaciteit die bestaat. Zes parallelle streams vullen de kloof en leveren een groter getal.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Beide getallen zijn waar. Het getal van één stream zegt wat één download doet, wat een browsertab meestal krijgt. Het parallelle getal zegt wat het pad in totaal kan dragen, wat een torrent of een download in delen kan benutten. Het ene citeren alsof het het andere is, is hoe een gezonde tunnel zonder reden wordt vervangen.

Een parallel resultaat vergelijken met een enkelvoudig resultaat is de meest voorkomende manier waarop mensen concluderen dat een VPN hun snelheid halveerde. Stem de methode af en vergelijk dan. Het spoor in de derde opdracht voegt de ontbrekende context toe: een pad met hoge jitter geeft in beide modi wisselvallige resultaten, en geen enkel aantal streams lost dat op.

Versleuteling kost processortijd, inkapseling kost bytes

Twee mechanismen werken op elk pakket, hoe snel de lijn ook is. Versleuteling verbruikt processor per byte, en inkapseling voegt headerbytes toe die de lijn alsnog moet dragen. Beide verschijnen als een plafond, en ze hebben verschillende symptomen.

Het processorplafond verschijnt als een plateau: de doorvoer stopt met stijgen hoeveel streams je ook toevoegt, en de processor van de machine is bezet terwijl de lijn dat niet is. Op een kleine router of een telefoon is dat vaak de echte grens, en daarom kan een snelle lijn nog steeds een bescheiden tunnel leveren.

De bytekosten zijn kleiner maar constant. Extra headers betekenen minder bruikbare lading per pakket, en op een pad met een vaste maximale transmissie-eenheid kunnen ze ook fragmentatie of een zwart gat uitlokken, dat zich uit als een hapering bij grote overdrachten en niet als een traag gemiddelde.

Deze drie worden vaak verward omdat gebruikers ze allemaal beschrijven als «de VPN is traag». Alleen de eerste reageert op een grotere machine, alleen de tweede reageert op een kleinere MTU, en alleen de derde reageert op wachtrijbeheer.

Zet de methode in het verslag

Een resultaat dat het waard is te bewaren noemt het apparaat, het toegangsnetwerk, de exit, de meetserver, de richting, het aantal streams en de duur. Zonder die kunnen twee getallen niet worden vergeleken, en een ticket met één getal is eigenlijk een stemming.

Bewaar ook de slechte runs. Een reeks waarin één exit elke keer een hapering veroorzaakt is veel informatiever dan een gemiddelde, en de haperingen zijn precies wat gemiddelden verbergen.

Test dan wat je echt belangrijk vindt. Is een grote download het doel, download het bestand. Is een gesprek het doel, meet latentie onder belasting in plaats van doorvoer in rust, want een tunnel kan goed scoren in een snelheidstest en toch elk overleg onverstaanbaar maken.