Un MTU VPN mai mic este mai rapid? Comparați dovezile reale
Un MTU mai mic poate ocoli o limită a traseului și totuși poate costa debit. Comparați constrângerea reală, costul antetelor și volumul de lucru înainte de a păstra modificarea.
Un tunel aruncă transferurile mari dar lasă ping-ul să treacă, așa că sfatul vine repede: reduceți MTU. Corecția funcționează uneori, iar apoi este aplicată fiecărui profil din fiecare rețea. Exact atunci o reparație țintită devine o taxă permanentă pe performanță. Comparația de făcut este între limita reală a traseului și costul de a micșora fiecare pachet sub ea.
Ce se micșorează de fapt când coborâți MTU
Fiecare pachet poartă antete înainte de a purta datele dumneavoastră. Pe un traseu Ethernet de 1500 de octeți, IPv4 și TCP consumă 40 de octeți și lasă 1460 pentru încărcătură; încapsularea adaugă deasupra antete externe IP, UDP și de tunel, așa că bugetul intern de încărcătură scade din nou. Coborârea MTU a interfeței micșorează acel buget în mod deliberat.
Costul este proporțional cu numărul de pachete, nu cu numărul de octeți. Același fișier împărțit în mai multe pachete are nevoie de mai multe întreruperi, mai multe decizii de rutare și mai multă procesare pe pachet pe fiecare dispozitiv de pe traseu. Pe un router deja aproape de limita sa de pachete pe secundă, aceasta este o încetinire reală, nu o eroare de rotunjire. Costul apare chiar și atunci când transferul în sine reușește.
De aceea un MTU mai mic este o ocolire a unei constrângeri, nu o optimizare generală. Cumpără fiabilitate în fața unui traseu care nu poate duce cadrul mai mare și percepe suprataxă pentru fiecare pachet care nu avea nevoie de micșorare.
Când un MTU mai mic este corecția potrivită
Simptomul clasic este specific: strângerea de mână TCP se încheie, sosesc răspunsuri mici, iar o descărcare mare se blochează sau se resetează. Un ping cu bitul nu-fragmenta la 1472 de octeți eșuează în timp ce un ping de 1400 de octeți reușește, ceea ce indică un traseu care nu poate duce un pachet de dimensiune completă și nu livrează mesajul ICMP care i-ar spune expeditorului să micșoreze.
Descoperirea MTU a traseului depinde de acele mesaje ICMP de fragmentare necesară. Când un firewall le aruncă, expeditorul continuă să reîncerce pachetul mare și conexiunea pare blocată. Coborârea MTU pe partea de tunel evită reîncercarea, iar aceasta este o reparație legitimă pentru acea rețea.
Tehnologiile de acces impun și ele propriile limite: PPPoE se oprește de obicei la 1492, unele trasee mobile și DSL sunt mai jos, iar tunelurile imbricate scad suprataxa de două ori. Măsurați traseul real în loc să copiați un număr dintr-un ghid și țineți minte că IPv6 cere cel puțin 1280 de octeți de MTU pe orice legătură care îl transportă, cum specifică RFC 8200.
Comparați cele trei controale înainte de a schimba unul
MTU, MSS și fragmentarea sunt controale diferite la niveluri diferite, iar schimbarea celui greșit lasă simptomul pe loc.
| 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 |
Limitarea MSS este adesea cea mai puțin invazivă reparație, pentru că afectează doar TCP și lasă interfața liberă pentru alt trafic. Un MTU de interfață mai mic este mai larg și mai ușor de analizat, de aceea este obișnuit pe routerele de consum, dar percepe fiecărui protocol problema unui singur protocol.
Dezactivarea comportamentului nu-fragmenta ascunde simptomul permițând fragmentarea și de obicei înrăutățește latența, rupând totodată feedbackul care ar fi găsit dimensiunea corectă. Evitați-o ca reparație permanentă.
Măsurați compromisul, nu un singur număr
Găsiți limita traseului cu o sondă nu-fragmenta, pornind de sus și coborând până când sosește răspunsul:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Apoi comparați sarcina reală pe ambele setări: același transfer de fișier, același punct final și aceeași rețea. Notați timpul de finalizare și retransmisiile, de exemplu cu nstat -az TcpRetransSegs, și urmăriți procesorul dispozitivului dacă tunelul se termină pe un router mic. Un test sintetic scurt de debit poate rata blocajul care apare doar după câțiva megaocteți.
Contoarele de pachete vor crește după o reducere, pentru că același transfer folosește acum mai multe pachete. Este de așteptat și nu este dovada unui debit mai mare. Comparați datele de aplicație finalizate, numărul de retransmisii și receptivitatea, nu doar rata pachetelor.
Introduceți modificarea în etape și păstrați-o limitată
Notați valoarea inițială, schimbați un control și repetați măsurătoarea înainte de a o face permanentă. Dacă dovezile nu arată un beneficiu, restabiliți valoarea anterioară cu aceeași comandă de interfață pe care ați folosit-o ca să o setați:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Limitați rezultatul la rețeaua care avea nevoie de el. Un profil care trebuie să funcționeze pe un Wi-Fi de hotel, pe un hotspot mobil și într-o LAN de birou nu ar trebui să moștenească cea mai mică valoare cerută de oricare dintre ele, decât dacă clientul nu poate detecta traseul.
Valoarea corectă este cel mai mare MTU care supraviețuiește traseului, nu cel mai mic care face simptomul să dispară. Documentați traseul, rezultatul sondei și revenirea, și revedeți setarea când rețeaua de acces se schimbă.