Er ein mindre VPN-MTU snøggare? Samanlikn dei faktiske prova
Ein lågare MTU kan omgå ei grense i ruta og likevel koste gjennomstrøyming. Samanlikn den reelle avgrensinga, overheaden i hovuda og arbeidsmengda før du held på endringa.
Ein tunnel slepp store overføringar men lèt ping passere, så rådet kjem snøgt: senk MTU-en. Rettingsarbeidet verkar av og til, og deretter vert det brukt på kvar profil i kvart nettverk. Det er punktet der ein målretta reparasjon vert ein permanent ytingsskatt. Samanlikninga som må gjerast, er mellom den reelle grensa for ruta og kostnaden ved å krympe kvar pakke under henne.
Kva som faktisk krympar når du senkar MTU-en
Kvar pakke ber hovud før ho ber dataa dine. På ei Ethernet-rute på 1500 byte brukar IPv4 og TCP 40 byte og lèt 1460 vere att til nyttelasta; innkapsling legg ytre IP-, UDP- og tunnelhovud på toppen, så det indre nyttelastbudsjettet fell igjen. Å senke MTU-en på grensesnittet krympar budsjettet med vilje.
Kostnaden er proporsjonal med talet på pakkar, ikkje talet på byte. Den same fila delt i fleire pakkar treng fleire avbrot, fleire ruterval og meir handsaming per pakke på kvar eining langs ruta. På ein ruter som alt er nær grensa for pakkar per sekund, er det ei reell forseinking og ikkje ein avrundingsfeil. Kostnaden syner seg sjølv når overføringa sjølv lukkast.
Difor er ein mindre MTU ein omveg rundt ei avgrensing, ikkje ei generell optimalisering. Han kjøper pålitelegheit mot ei rute som ikkje kan bere den større ramma, og han krev overhead for kvar pakke som ikkje trong reduksjonen.
Når ein mindre MTU er den rette rettinga
Det klassiske symptomet er spesifikt: TCP-handtrykket vert fullført, små svar kjem inn, og ei stor nedlasting stoppar eller vert nullstilt. Ein ping med don’t-fragment-biten på 1472 byte feilar medan ein ping på 1400 byte lukkast, noko som peikar på ei rute som ikkje kan bere ein pakke i full storleik og ikkje leverer ICMP-meldinga som ville sagt til avsendaren å krympe.
Oppdaginga av MTU-en for ruta er avhengig av dei ICMP-meldingane om nødvendig fragmentering. Når ein brannmur slepp dei, held avsendaren fram med å prøve den store pakka på nytt, og sambandet ser ut til å henge. Å senke MTU-en på tunnelsida unngår gjentakinga, og det er ein legitim reparasjon for det nettverket.
Tilgangsteknologiar set òg eigne grenser: PPPoE stoppar vanlegvis ved 1492, nokre mobil- og DSL-ruter er lågare, og nøsta tunnelar trekkjer frå overheaden to gonger. Mål den faktiske ruta i staden for å kopiere eit tal frå ei rettleiing, og hugs at IPv6 krev minst 1280 byte MTU på kvar lenke som ber det, slik RFC 8200 fastset.
Samanlikn dei tre kontrollane før du endrar éin
MTU, MSS og fragmentering er ulike kontrollar på ulike lag, og å endre den gale lèt symptomet stå.
| 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 |
Å avgrense MSS er ofte den minst inngripande reparasjonen, fordi han berre påverkar TCP og lèt grensesnittet vere fritt for annan trafikk. Ein lågare MTU på grensesnittet er breiare og lettare å tenkje gjennom, difor er han vanleg på forbrukarrutarar, men han krev kvar protokoll for problemet til éin protokoll.
Å slå av don’t-fragment-åtferda løyner symptomet ved å tillate fragmentering, og det gjer vanlegvis latenstida verre samstundes som det bryt tilbakemeldinga som ville ha funne rett storleik. Unngå det som ei permanent retting.
Mål avveginga i staden for eitt tal
Finn grensa for ruta med ein don’t-fragment-sonde, start høgt og gå ned til svaret kjem:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Samanlikn deretter den reelle oppgåva på båe innstillingane: den same filoverføringa, det same endepunktet og det same nettverket. Noter fullføringstid og gjentekne overføringar, til dømes med nstat -az TcpRetransSegs, og fylg med på CPU-en til eininga om tunnelen endar på ein liten ruter. Ein kort syntetisk gjennomstrøymingstest kan oversjå stansen som først syner seg etter fleire megabyte.
Pakketeljarar vil stige etter ein reduksjon fordi den same overføringa no brukar fleire pakkar. Det er venta og er ikkje prov på høgare gjennomstrøyming. Samanlikn fullførte applikasjonsdata, talet på gjentekne overføringar og responsiviteten, ikkje berre pakkefarten.
Før inn endringa trinnvis og hald henne avgrensa
Noter den opphavlege verdien, endre éin kontroll, og gjer målinga om att før du gjer henne permanent. Viss prova ikkje syner nokon fordel, set den førre verdien attende med den same grensesnittkommandoen som du brukte for å setje han:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Avgrens resultatet til nettverket som trong det. Ein profil som må fungere på hotell-Wi-Fi, ein mobil hotspot og eit kontor-LAN bør ikkje arve den lågaste verdien som nokon av dei krev, med mindre klienten ikkje kan oppdage ruta.
Den rette verdien er den største MTU-en som overlever ruta, ikkje den minste som får symptomet til å forsvinne. Dokumenter ruta, resultatet av sonden og tilbakerullinga, og vurder innstillinga på nytt når tilgangsnettverket endrar seg.