Waarom een VPN-download uw directe verbinding kan verslaan

Verbind de tunnel, start een grote download, en hij gaat ongeveer twee keer zo snel als hetzelfde bestand zonder. Dat klinkt als reclame, maar het kan een echte meting op een thuisverbinding zijn. De gebruikelijke oorzaak is een snelheidslimiet die aan één poort hangt: de tunnel draagt uw overdracht naar een plek waar de shaper niet kijkt, en de werkelijke capaciteit van de lijn komt voor het eerst tevoorschijn.

Wat betekent dat het interessante getal niet is hoe snel de VPN was. Het is hoeveel van uw lijn u nooit kreeg, en waarom.

Een grens die de poort volgt, niet de route

Een accessprovider kan de doorvoer per abonnee beperken op basis van protocol of bestemmingspoort, en poort 80 is een geliefd doel omdat zoveel gewoon browsen die gebruikt. De limiet wordt vaak niet vanaf het eerste pakket toegepast: de overdracht begint bijna op lijnsnelheid, verbruikt een burst-vergoeding en zakt daarna naar het begrensde getal. De eerste seconden zien er gezond uit en de rest van de overdracht niet.

Stuur dezelfde bytes over een andere poort en de shaper op 80 ziet ze nooit. De tunnel lijkt de directe verbinding te verslaan, ook al heeft hij een hop, versleuteling en zijn eigen overhead toegevoegd. Wat verbeterde is niet het pad maar het ontbreken van een regel.

Daarom is het effect zo consistent over bestanden en bestemmingen. Als de limiet op de poort zit, gedraagt alles wat over die poort gaat zich hetzelfde, hoe groot het bestand ook is en wie de host ook is. Een bestemming die een andere regel aantrekt, toont een andere curve, en dat verschil is op zichzelf diagnostisch.

Meet het plateau, niet de piek

Een piek is het minst informatieve deel van een overdracht, omdat elke verbinding er goed uitziet terwijl de buffers vollopen. Noteer waar de snelheid tot rust komt en hoe lang die daar blijft.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Voer het paar direct achter elkaar uit op dezelfde machine, op hetzelfde uur, tegen hosts op vergelijkbare netwerken. Eén monster bewijst niets; de vorm van de curve over twee runs van elk is wat een burst-vergoeding van een stabiele limiet onderscheidt. Noteer waar de snelheid afvlakt in plaats van wat de eerste seconde liet zien, want de burst is precies wat een shaper u geeft voordat hij begint te begrenzen. Een rustig plateau dat de rest van de overdracht volhoudt, is het getal om te vergelijken.

Houd het bestand al gecomprimeerd zodat transportcompressie niet als verklaring kan worden aangeboden. Een PDF of een archief haalt die variabele weg, en voorkomt ook dat iemand beweert dat de tunnel de lading heeft samengeperst. Als beide overdrachten hetzelfde bestand gebruiken, is het enige overgebleven verschil het pad en de poort. Noteer het gereedschap en de poort naast elk getal, anders is de tweede run niet vergelijkbaar met de eerste.

Drie vergelijkingen die de oorzaak isoleren

Werk ze op volgorde af en stop zodra het patroon duidelijk is, want elk sluit een ander verhaal uit.

1. Herhaal dezelfde download via het gewone webpad en via een overdrachtsgereedschap op een andere poort, vanaf een host met vergelijkbare capaciteit.
2. Herhaal beide met een niet-comprimeerbaar bestand, zodat compressie geen kandidaat meer is.
3. Als u de tunnelserver zelf beheert, bind hem dan opnieuw aan poort 80, pas het clientprofiel aan zodat beide uiteinden het eens zijn, en draag opnieuw over. Als de tunnel nu op de begrensde websnelheid zit, volgt de beperking de poort en niet de VPN.

De derde stap is de beslissende, en het is ook degene die mensen overslaan omdat er een configuratiewijziging voor nodig is. Zonder die stap hebt u aangetoond dat twee dingen verschillen, niet dat de poort de oorzaak is.

Wat deze meting niet kan ondersteunen

Ze toont niet aan dat de tunnel in het algemeen sneller is, dat hij iets comprimeert, of dat andere poorten op de lijn onbeperkt zijn. Ze beschrijft deze overdracht, op deze lijn, op dit uur. Limieten kunnen per sessie, per abonnee of naar tijd van de dag gelden, en ze kunnen zonder kennisgeving veranderen.

Ze bewijst ook niet dat het directe pad stuk is. Een begrensd pad werkt nog steeds; het is met opzet begrensd, en bewust beleid is geen storing die op reparatie wacht.

En ze rechtvaardigt zeker niet om alles door de tunnel te leiden. Elke toepassing op poort 80 blijft begrensd, terwijl alles wat u omleidt nu van een extra hop en een extra faalwijze afhangt.

Maak van de bevinding iets uitvoerbaars

Schrijf de observatie als een meting en niet als een vonnis: grote overdrachten over poort 80 komen uit op ongeveer de helft van de snelheid die hetzelfde bestand op een andere poort haalt, op deze uren, op deze lijn, met deze monsters bijgevoegd. Dat is een supportverzoek dat iemand kan onderzoeken.

„De VPN is sneller“ is dat niet. Het nodigt uit tot een antwoord over versleutelingskosten, en dat antwoord is technisch juist terwijl het niemand iets nuttigs vertelt. Voeg het aantal monsters, het uur en de poort toe, zodat de lezer het patroon kan nabootsen.

Als u besluit een andere poort te blijven gebruiken voor grote overdrachten, noteer dan het voorbehoud in uw eigen administratie: een listener naar poort 80 verplaatsen botst met elke webserver die daar al aan gebonden is, en de resulterende storing ziet eruit als een kapotte tunnel in plaats van een poortconflict.