Waarom een download sneller gaat via de VPN dan direct

Je start een grote download, de eerste seconden zien er normaal uit en dan stabiliseert de snelheid op ongeveer de helft van wat de lijn zou moeten leveren. Je verbindt de tunnel, herhaalt dezelfde download en hij houdt een hogere snelheid voor het hele bestand. Dat is een echte meting en tegelijk een misleidende conclusie, want de tunnel heeft het pad niet sneller gemaakt. Hij heeft je verkeer alleen weggehaald bij een poort die iets onderweg beperkte.

De vorm van de curve verraadt het

Kijk naar de overdracht in plaats van het eindcijfer. Een begrensd pad begint meestal bijna op lijnsnelheid, verbruikt zijn burst-toelage en zakt daarna naar de limiet, dus het gemiddelde hangt af van hoe lang je keek. Een tunnel die het pad echt verbeterde, zou vanaf de eerste seconde een betere snelheid laten zien en die vasthouden. Het plateau is de vingerafdruk, en je mist het makkelijk als je alleen de piek vastlegt.

Twee runs van hetzelfde bestand, één direct en één via de tunnel, zijn genoeg om te zien of er een plateau is.

Let op wanneer het plateau begint, hoe lang het duurt en welke snelheid het houdt. Die drie waarden scheiden een shaper van een overbelast pad, want overbelasting laat de snelheid zwerven terwijl een shaper hem aan één getal vastzet. Als de directe run geleidelijk slechter wordt en de tunnelrun stabiel blijft, kijk je naar beleid en niet naar natuurkunde.

Drie vergelijkingen, elk één variabele

Verander één ding per run, anders leer je niets. Haal hetzelfde bestand via het gewone webpad, dan via een overdrachtshulpmiddel dat een andere poort gebruikt, vanaf een host met vergelijkbare capaciteit en op hetzelfde uur. Houd de clientmachine vast, want een laptop die tussen netwerken beweegt voegt een variabele toe die je niet kunt beheersen.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Gebruik een bestand dat al gecomprimeerd is, zoals een schijfkopie, zodat transportcompressie het verschil niet kan verklaren. Als je de server beheert, verplaats dan zijn luisteraar naar de poort die je verdenkt van begrenzing, werk het clientprofiel bij en herhaal. Zou de tunnel nu naar de begrensde snelheid zakken, dan volgt de limiet de poort en niet de tunnel, en de vraag is beslecht. Voer elke vergelijking twee keer uit en bewaar de plateaucijfers, niet de pieken.

Noteer ook het uur, want een shaper kan tijdsgebaseerd zijn en een avondtest kan het oneens zijn met een ochtendtest. Twee runs op hetzelfde uur zijn meer waard dan tien verspreid over de dag.

Wat deze meting niet kan ondersteunen

Ze toont niet dat de tunnel in het algemeen sneller is, dat hij iets comprimeert of dat andere poorten niet begrensd zijn. Ze beschrijft één overdracht op één lijn gedurende één uur. Limieten kunnen per sessie, per abonnee of tijdsgebaseerd zijn, en een operator kan ze wijzigen zonder het aan te kondigen.

Ze toont ook niet dat het directe pad defect is. Een begrensd pad werkt precies zoals bedoeld, het is alleen door beleid beperkt.

Dat onderscheid is belangrijk als je het opschrijft. Een defect vraagt om een reparatieticket, terwijl een beleid vraagt om een vraag over het contract of om een besluit eromheen te werken. Een limiet een defect noemen levert een supportgesprek op dat van de verkeerde premisse vertrekt. Het beleid noemen laat je een concrete vraag stellen die een concreet antwoord heeft.

Maak van de bevinding een supportverzoek

Gebruik de cijfers en laat de conclusie weg. Een verzoek dat stelt dat grote overdrachten via poort 80 in deze uren op ongeveer de helft van de verwachte snelheid blijven, met de plateaucijfers bijgevoegd, is uitvoerbaar. Een verzoek dat zegt dat de VPN sneller is, is dat niet, want het leest als een bewering over de tunnel in plaats van een waarneming over de lijn. Voeg beide runs en hun tijdstempels toe, en laat de operator dan het beleid beschrijven.

Duw niet elke toepassing de tunnel in om alleen dat cijfer na te jagen.

De tunnel kost je nog steeds een extra hop, versleuteling en een nieuwe set faalmodi, terwijl de beperkte poort beperkt blijft voor al het andere dat hem gebruikt. Wanneer grote overdrachten betrouwbaar moeten eindigen, houd je eigen notitie bij van welke poort de limiet draagt. Een luisteraar naar poort 80 verplaatsen botst ook met elke webserver die er al aan gebonden is, en dat levert een nieuwe storing op in plaats van een oplossing.