Hoe je de snelheid van een VPN test zodat de cijfers iets betekenen

Een snelheidstest meet nooit de VPN. Hij meet een pad, en het aanzetten van de tunnel vervangt een deel van dat pad voordat de eerste byte beweegt. Daarom laat de ene laptop een gezond cijfer zien tegen de ene site en een slecht cijfer tegen de andere, zonder dat er aan een van beide kanten iets is veranderd. Lees het resultaat als bewijs over een route, niet als een score voor een product.

Drie dingen bepalen of de vergelijking iets waard is: of beide runs hetzelfde doel raakten, of het toegangsnetwerk stil bleef en of je de vertraging naast het volume hebt genoteerd.

Wat de tunnel herschrijft voor de eerste byte

De client wikkelt elk pakket in nog een header, dus de bruikbare payload per pakket krimpt. De kosten zijn per pakket en niet per overdracht, wat betekent dat een groot bestand meer pakketten nodig heeft dan hetzelfde bestand zonder tunnel. Zulke overhead is te zien als pakketaantal, niet als een zichtbare instelling.

Daaruit volgen twee gevolgen. Een test van grote blokken voelt de kosten per pakket, terwijl een test van veel kleine verzoeken juist de retourtjes voelt. En als het ontdekken van de MTU van het pad ergens onderweg geblokkeerd is, blijft de tunnel op een kleinere pakketgrootte hangen en valt de doorvoer om een reden die niets met versleuteling te maken heeft.

Je kunt het plafond direct bekijken. Vraag onder Linux om de grootste payload die zonder fragmentatie doorkomt, en herhaal dat met de tunnel aan:

ping -M do -s 1472 -c 3 203.0.113.10

Als dat mislukt, ga dan naar 1,400 en probeer opnieuw. Een tunnel die maar 1,380 byte draagt, vertelt je dat er verderop in het pad iets knijpt, en geen enkele afstelling op de client tilt dat op.

Waarom de testserver verschuift als de tunnel opkomt

De meeste hulpmiddelen kiezen een server in de buurt op basis van het openbare adres dat ze zien. Met de tunnel aan hoort dat adres bij het uitgangsknooppunt, dus het hulpmiddel kan een host in een andere stad of een ander land kiezen. Je vergelijkt dan twee bestemmingen, en het verschil daartussen bevat de afstand van de uitgang tot de testhost.

Zet de server voor de eerste run vast op naam of ID en houd hem bij elke volgende run. Als het hulpmiddel hem niet vasthoudt, kies dan een doel dat je zelf beheert en stuur dat zelf aan: iperf3 -c test.example.net -R -t 20 houdt de bestemming vast en geeft je een getal dat je met dat van gisteren kunt vergelijken.

Verander één variabele, en de onderlaag is er niet één

Draadloos is de gebruikelijke verborgen verandering. De signaalsterkte verschuift als de laptop beweegt en de kanaalbezetting verschuift als een buur een gesprek begint, dus twee runs tien minuten uit elkaar via Wi-Fi zijn geen herhalingen van dezelfde test. Kabel, of een vaste positie met het signaalniveau opgeschreven, haalt het meeste van die ruis weg. Een notitie van het signaalniveau aan het begin en einde van elke run is meestal genoeg om te laten zien of twee runs bij elkaar horen.

Apparaatbelasting hoort in dezelfde mand. Een client die op één kern versleutelt, raakt zijn eigen plafond lang voor de verbinding, en een achtergrondsynchronisatie raakt het eerder. Houd de CPU in de gaten tijdens de run en noteer wat er nog meer open stond. Energie-instellingen kunnen hier ook bijten, want een laptop op accu kan de processor beperken lang voordat de verbinding ook maar in de buurt van druk is.

Houd de onderlaag stil in plaats van erover te middelen. Drie runs die overeenkomen zeggen meer dan tien die in verschillende kamers zijn gedaan.

Vertraging, verlies en ICMP beantwoorden verschillende vragen

Ping stuurt een kleine sonde naar een vast adres, en veel netwerken antwoorden op ICMP met lage prioriteit of negeren het volledig. Ontbrekende antwoorden beschrijven de sonde, niet de pakketten van de toepassing. Een retourtijd die onder belasting stijgt, betekent meestal dat een wachtrij volloopt, niet dat de route langer is geworden.

Om te weten of de tunnel vertraging toevoegt, vergelijk je één doel met en zonder de tunnel, of vergelijk je twee uitgangen die vanaf hetzelfde toegangsnetwerk bereikbaar zijn. Voer de sonde herhaaldelijk uit en kijk naar de spreiding, want een gemiddelde verbergt precies de variatie die een gesprek onbruikbaar maakt.

Ga terug naar de taak die traag aanvoelde

Een meting die verbetert terwijl het gesprek nog hapert heeft iets anders beantwoord. Voer de taak opnieuw uit waarmee het onderzoek begon, of dat nu een vergadering, een bestandsslijtage of een sessie op een extern bureaublad was. Als het getal beter werd en de taak niet, zat de flessenhals ergens waar de test nooit kwam, zoals de server achter de tunnel of de uploadlijn aan jouw kant.

Leg elke run vast met apparaat, toegangsnetwerk, eindpunt, protocol, doel en tijd. Een run die nooit verbinding maakte, is een bereikbaarheidsresultaat en geen doorvoer van nul, dus archiveer hem onder dat label in plaats van hem te verwijderen.

Een korte lijst voor de volgende vergelijking

Zet het doel vast en schrijf op waarom je het koos. Noteer de pakketgrootte die het pad toestaat, zodat een latere daling een verklaring heeft. Houd het toegangsnetwerk gelijk, noteer de CPU-belasting en doe drie runs voordat je een verschil gelooft.

Verander dan precies één ding en herhaal. De vergelijking die je kunt uitleggen, verslaat die met het grotere getal.