Er en mindre VPN-MTU raskere? Sammenlign de faktiske bevisene
En lavere MTU kan omgå en grense i ruten og likevel koste gjennomstrømning. Sammenlign den reelle begrensningen, overheaden i hodene og arbeidsmengden før du beholder endringen.
En tunnel slipper store overføringer men lar ping passere, så rådet kommer raskt: senk MTU-en. Rettelsen virker noen ganger, og deretter brukes den på hver profil i hvert nettverk. Det er punktet der en målrettet reparasjon blir en permanent ytelsesskatt. Sammenligningen som må gjøres, er mellom rutens reelle grense og kostnaden ved å krympe hver pakke under den.
Hva som faktisk krymper når du senker MTU-en
Hver pakke bærer hoder før den bærer dataene dine. På en Ethernet-rute på 1500 byte bruker IPv4 og TCP 40 byte og lar 1460 være igjen til nyttelasten; innkapsling legger ytre IP-, UDP- og tunnelhoder på toppen, så det indre nyttelastbudsjettet faller igjen. Å senke grensesnittets MTU krymper budsjettet med vilje.
Kostnaden er proporsjonal med antall pakker, ikke med antall byte. Den samme filen delt i flere pakker trenger flere avbrudd, flere rutervalg og mer behandling per pakke på hver enhet langs ruten. På en ruter som allerede er nær grensen for pakker per sekund, er det en reell forsinkelse og ikke en avrundingsfeil. Kostnaden vises selv når overføringen selv lykkes.
Derfor er en mindre MTU en omvei rundt en begrensning, ikke en generell optimalisering. Den kjøper pålitelighet mot en rute som ikke kan bære den større rammen, og den krever overhead for hver pakke som ikke trengte reduksjonen.
Når en mindre MTU er den riktige rettelsen
Det klassiske symptomet er spesifikt: TCP-håndtrykket fullføres, små svar ankommer, og en stor nedlasting stopper eller tilbakestilles. En ping med don’t-fragment-biten på 1472 byte feiler mens en ping på 1400 byte lykkes, noe som peker på en rute som ikke kan bære en pakke i full størrelse og ikke leverer ICMP-meldingen som ville fortalt avsenderen å krympe.
Oppdagelsen av rutens MTU avhenger av disse ICMP-meldingene om nødvendig fragmentering. Når en brannmur slipper dem, fortsetter avsenderen å prøve den store pakken på nytt, og forbindelsen ser ut til å henge. Å senke MTU-en på tunnelsiden unngår gjentakelsen, og det er en legitim reparasjon for det nettverket.
Tilgangsteknologier setter også sine egne grenser: PPPoE stopper vanligvis ved 1492, noen mobil- og DSL-ruter er lavere, og nestede tunneler trekker fra overheaden to ganger. Mål den faktiske ruten i stedet for å kopiere et tall fra en veiledning, og husk at IPv6 krever minst 1280 byte MTU på hver lenke som bærer det, slik RFC 8200 fastsetter.
Sammenlign de tre kontrollene før du endrer én
MTU, MSS og fragmentering er forskjellige kontroller på forskjellige lag, og å endre den gale lar symptomet bli stående.
| 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 |
Å begrense MSS er ofte den minst inngripende reparasjonen, fordi den bare påvirker TCP og lar grensesnittet være fritt for annen trafikk. En lavere MTU på grensesnittet er bredere og lettere å tenke gjennom, derfor er den vanlig på forbrukerrutere, men den krever hver protokoll for problemet til én protokoll.
Å slå av don’t-fragment-atferden skjuler symptomet ved å tillate fragmentering, og det gjør vanligvis latenstiden verre samtidig som det bryter tilbakemeldingen som ville ha funnet riktig størrelse. Unngå det som en permanent rettelse.
Mål avveiningen i stedet for ett tall
Finn rutens grense med en don’t-fragment-sonde, start høyt og gå ned til svaret kommer:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Sammenlign deretter den reelle oppgaven på begge innstillingene: den samme filoverføringen, det samme endepunktet og det samme nettverket. Noter fullføringstid og gjentatte overføringer, for eksempel med nstat -az TcpRetransSegs, og følg med på enhetens CPU hvis tunnelen ender på en liten ruter. En kort syntetisk gjennomstrømningstest kan overse stansingen som først vises etter flere megabyte.
Pakketellere vil stige etter en reduksjon fordi den samme overføringen nå bruker flere pakker. Det er forventet og er ikke bevis på høyere gjennomstrømning. Sammenlign fullførte applikasjonsdata, antall gjentatte overføringer og responsiviteten, ikke bare pakkehastigheten.
Innfør endringen trinnvis og hold den avgrenset
Noter den opprinnelige verdien, endre én kontroll, og gjenta målingen før du gjør den permanent. Hvis bevisene ikke viser noen fordel, gjenopprett den forrige verdien med den samme grensesnittkommandoen som du brukte for å sette den:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Avgrens resultatet til nettverket som trengte det. En profil som må fungere på hotell-Wi-Fi, et mobilt hotspot og et kontor-LAN bør ikke arve den laveste verdien som noen av dem krever, med mindre klienten ikke kan oppdage ruten.
Den riktige verdien er den største MTU-en som overlever ruten, ikke den minste som får symptomet til å forsvinne. Dokumenter ruten, sondens resultat og tilbakerullingen, og vurder innstillingen på nytt når tilgangsnettverket endres.