Is een kleinere VPN-MTU sneller? Vergelijk het echte bewijs
Een lagere MTU kan een padlimiet omzeilen en toch doorvoer kosten. Vergelijk de echte beperking, de overhead van headers en de werklast voordat u de wijziging houdt.
Een tunnel laat grote overdrachten vallen maar laat ping door, dus het advies komt snel: verlaag de MTU. De oplossing werkt soms, en dan wordt hij op elk profiel op elk netwerk toegepast. Dat is het punt waarop een gerichte reparatie een permanente prestatietaks wordt. De vergelijking die gemaakt moet worden, is tussen de echte limiet van het pad en de kosten om elk pakket daaronder te verkleinen.
Wat er werkelijk krimpt als u de MTU verlaagt
Elk pakket draagt headers voordat het uw gegevens draagt. Op een Ethernet-pad van 1500 byte verbruiken IPv4 en TCP 40 byte en laten 1460 over voor de payload; encapsulatie voegt buitenste IP-, UDP- en tunnelheaders toe, dus het binnenste payloadbudget daalt opnieuw. Het verlagen van de interface-MTU verkleint dat budget bewust.
De kosten zijn evenredig met het aantal pakketten, niet met het aantal bytes. Hetzelfde bestand in meer pakketten vraagt meer onderbrekingen, meer routeringsbeslissingen en meer verwerking per pakket op elk apparaat langs het pad. Op een router die al dicht bij zijn limiet van pakketten per seconde zit, is dat een echte vertraging en geen afrondingsfout. De kosten zijn zichtbaar zelfs wanneer de overdracht zelf slaagt.
Daarom is een kleinere MTU een omweg om een beperking heen, geen algemene optimalisatie. Hij koopt betrouwbaarheid tegen een pad dat het grotere frame niet kan dragen, en rekent overhead voor elk pakket dat de verkleining niet nodig had.
Wanneer een kleinere MTU de juiste oplossing is
Het klassieke symptoom is specifiek: de TCP-handshake voltooit, kleine antwoorden komen aan, en een grote download stokt of wordt gereset. Een ping met de don’t-fragment-bit op 1472 byte mislukt terwijl een ping van 1400 byte slaagt, wat wijst op een pad dat geen pakket van volledige grootte kan dragen en het ICMP-bericht niet aflevert dat de afzender zou vertellen te verkleinen.
De ontdekking van de pad-MTU hangt af van die ICMP-berichten over noodzakelijke fragmentatie. Als een firewall ze weggooit, blijft de afzender het grote pakket herhalen en lijkt de verbinding te hangen. De MTU aan de tunnelkant verlagen voorkomt de herhaling, en dat is een legitieme reparatie voor dat netwerk.
Toegangstechnologieën stellen ook hun eigen grenzen: PPPoE stopt meestal bij 1492, sommige mobiele en DSL-paden zijn lager, en geneste tunnels trekken de overhead twee keer af. Meet het echte pad in plaats van een getal uit een gids te kopiëren, en onthoud dat IPv6 minstens 1280 byte MTU vereist op elke verbinding die het draagt, zoals RFC 8200 bepaalt.
Vergelijk de drie knoppen voordat u er één verandert
MTU, MSS en fragmentatie zijn verschillende knoppen op verschillende lagen, en de verkeerde veranderen laat het symptoom staan.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS beperken is vaak de minst ingrijpende reparatie, omdat het alleen TCP raakt en de interface vrijlaat voor ander verkeer. Een lagere interface-MTU is breder en eenvoudiger te beredeneren, daarom is die gangbaar op consumentenrouters, maar hij rekent elk protocol het probleem van één protocol aan.
Het don’t-fragment-gedrag uitschakelen verbergt het symptoom door fragmentatie toe te staan, en het maakt de latentie meestal slechter terwijl het de feedback breekt die de juiste grootte zou hebben gevonden. Vermijd het als blijvende oplossing.
Meet de afweging in plaats van één getal
Vind de limiet van het pad met een don’t-fragment-probe, begin hoog en zak tot het antwoord komt:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Vergelijk daarna de echte taak op beide instellingen: dezelfde bestandsoverdracht, hetzelfde eindpunt en hetzelfde netwerk. Noteer de voltooiingstijd en hertransmissies, bijvoorbeeld met nstat -az TcpRetransSegs, en houd de CPU van het apparaat in het oog als de tunnel op een kleine router eindigt. Een korte synthetische doorvoertest kan de stilstand missen die pas na enkele megabytes optreedt.
Pakkettellers zullen stijgen na een verlaging omdat dezelfde overdracht nu meer pakketten gebruikt. Dat is te verwachten en het is geen bewijs van hogere doorvoer. Vergelijk voltooide applicatiegegevens, het aantal hertransmissies en de responsiviteit, niet alleen de pakketfrequentie.
Voer de wijziging in stappen door en houd hem beperkt
Noteer de oorspronkelijke waarde, verander één knop en herhaal de meting voordat u hem permanent maakt. Als het bewijs geen voordeel laat zien, herstel dan de vorige waarde met hetzelfde interfacecommando dat u gebruikte om hem in te stellen:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Beperk het resultaat tot het netwerk dat het nodig had. Een profiel dat moet werken op een hotel-Wi-Fi, een mobiele hotspot en een kantoor-LAN zou niet de laagste waarde moeten erven die een van die netwerken vereist, tenzij de client het pad niet kan detecteren.
De juiste waarde is de grootste MTU die het pad overleeft, niet de kleinste die het symptoom laat verdwijnen. Documenteer het pad, het resultaat van de probe en het terugdraaien, en herzie de instelling wanneer het toegangsnetwerk verandert.