Är ett mindre VPN-MTU snabbare? Jämför de faktiska bevisen
Ett lägre MTU kan kringgå en gräns i vägen och ändå kosta genomströmning. Jämför den verkliga begränsningen, overheaden i rubrikerna och arbetsbelastningen innan du behåller ändringen.
En tunnel släpper stora överföringar men låter ping passera, så rådet kommer snabbt: sänk MTU:n. Åtgärden fungerar ibland, och sedan tillämpas den på varje profil i varje nätverk. Det är punkten där en riktad reparation blir en permanent prestandaskatt. Jämförelsen som måste göras är mellan vägens verkliga gräns och kostnaden för att krympa varje paket under den.
Vad som faktiskt krymper när du sänker MTU:n
Varje paket bär rubriker innan det bär dina data. På en Ethernet-väg på 1500 byte förbrukar IPv4 och TCP 40 byte och lämnar 1460 för nyttolasten; inkapslingen lägger yttre IP-, UDP- och tunnelrubriker ovanpå, så den inre nyttolastbudgeten faller igen. Att sänka gränssnittets MTU krymper den budgeten med avsikt.
Kostnaden är proportionell mot antalet paket, inte mot antalet byte. Samma fil uppdelad i fler paket kräver fler avbrott, fler routingbeslut och mer bearbetning per paket på varje enhet längs vägen. På en router som redan ligger nära sin gräns för paket per sekund är det en verklig fördröjning och inte ett avrundningsfel. Kostnaden syns även när själva överföringen lyckas.
Därför är ett mindre MTU en omväg runt en begränsning, inte en allmän optimering. Det köper tillförlitlighet mot en väg som inte kan bära den större ramen, och det tar betalt i overhead för varje paket som inte behövde minskningen.
När ett mindre MTU är rätt åtgärd
Det klassiska symptomet är specifikt: TCP-handskakningen slutförs, små svar anländer och en stor nedladdning stannar eller återställs. En ping med don’t-fragment-biten på 1472 byte misslyckas medan en ping på 1400 byte lyckas, vilket pekar på en väg som inte kan bära ett paket i full storlek och inte levererar det ICMP-meddelande som skulle säga åt avsändaren att krympa.
Upptäckten av vägens MTU beror på dessa ICMP-meddelanden om nödvändig fragmentering. När en brandvägg kastar dem fortsätter avsändaren att försöka med det stora paketet och anslutningen verkar hänga. Att sänka MTU:n på tunnelsidan undviker upprepningen, och det är en legitim reparation för det nätverket.
Även accesstekniker sätter sina egna gränser: PPPoE stannar vanligtvis vid 1492, vissa mobil- och DSL-vägar är lägre, och kapslade tunnlar drar av overheaden två gånger. Mät den verkliga vägen i stället för att kopiera en siffra från en guide, och kom ihåg att IPv6 kräver minst 1280 byte MTU på varje länk som bär det, som RFC 8200 anger.
Jämför de tre reglagen innan du ändrar ett
MTU, MSS och fragmentering är olika reglage på olika lager, och att ändra det felaktiga låter symptomet stå kvar.
| 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 |
Att begränsa MSS är ofta den minst ingripande reparationen, eftersom den bara påverkar TCP och lämnar gränssnittet fritt för annan trafik. Ett lägre gränssnitts-MTU är bredare och lättare att resonera om, därför är det vanligt på konsumentroutrar, men det tar betalt av varje protokoll för ett enda protokolls problem.
Att stänga av don’t-fragment-beteendet döljer symptomet genom att tillåta fragmentering, och det gör vanligtvis latensen värre samtidigt som det bryter den återkoppling som skulle ha hittat rätt storlek. Undvik det som permanent åtgärd.
Mät avvägningen i stället för en enda siffra
Hitta vägens gräns med en don’t-fragment-sond, börja högt och gå nedåt tills svaret kommer:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Jämför sedan den verkliga uppgiften på båda inställningarna: samma filöverföring, samma slutpunkt och samma nätverk. Anteckna sluttid och omsändningar, till exempel med nstat -az TcpRetransSegs, och håll koll på enhetens CPU om tunneln slutar på en liten router. Ett kort syntetiskt genomströmningstest kan missa stoppet som först visar sig efter flera megabyte.
Paketräknarna kommer att öka efter en minskning eftersom samma överföring nu använder fler paket. Det är väntat och det är inte bevis på högre genomströmning. Jämför slutförda applikationsdata, antalet omsändningar och responsen, inte bara paketfrekvensen.
Inför ändringen stegvis och håll den avgränsad
Anteckna det ursprungliga värdet, ändra ett reglage och upprepa mätningen innan du gör den permanent. Om bevisen inte visar någon fördel, återställ det tidigare värdet med samma gränssnittskommando som du använde för att ställa in det:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Avgränsa resultatet till nätverket som behövde det. En profil som måste fungera på hotel-Wi-Fi, en mobil hotspot och ett kontors-LAN bör inte ärva det lägsta värde som något av dem kräver, om inte klienten kan upptäcka vägen.
Det rätta värdet är det största MTU som överlever vägen, inte det minsta som får symptomet att försvinna. Dokumentera vägen, sondens resultat och återställningen, och se över inställningen när åtkomstnätverket ändras.