Ĉu pli malgranda VPN-MTU estas pli rapida? Komparu la realajn pruvojn
Pli malalta MTU povas eviti limon de la vojo kaj tamen kosti trairon. Komparu la realan limigon, la superkoston de la kaplinioj kaj la laborŝarĝon antaŭ ol konservi la ŝanĝon.
Tunelo faligas grandajn transigojn sed trapasigas ping, do la konsilo venas rapide: malaltigu la MTU-on. La riparo foje funkcias, kaj poste ĝi aplikiĝas al ĉiu profilo en ĉiu reto. Ĝuste tiam celita riparo fariĝas daŭra imposto sur la rendimento. La komparo farinda estas inter la reala limo de la vojo kaj la kosto malgrandigi ĉiun paketon sub ĝin.
Kio efektive malgrandiĝas kiam vi malaltigas la MTU-on
Ĉiu paketo portas kapliniojn antaŭ ol ĝi portas viajn datumojn. Sur Ethernet-vojo de 1500 bajtoj, IPv4 kaj TCP konsumas 40 bajtojn kaj lasas 1460 por la utila ŝarĝo; enkapsuligo aldonas supre eksterajn kapliniojn de IP, UDP kaj tunelo, do la interna buĝeto de ŝarĝo denove falas. Malaltigi la MTU-on de la interfaco intence malgrandigas tiun buĝeton.
La kosto estas proporcia al la nombro de paketoj, ne al la nombro de bajtoj. La sama dosiero dividita en pli da paketoj bezonas pli da interrompoj, pli da enkursigaj decidoj kaj pli da prilaboro por paketo sur ĉiu aparato laŭ la vojo. Sur enkursigilo jam proksima al sia limo de paketoj po sekundo, tio estas reala malrapidiĝo, ne rondiga eraro. La kosto montriĝas eĉ kiam la transigo mem sukcesas.
Tial pli malgranda MTU estas ĉirkaŭvojo de limigo, ne ĝenerala optimumigo. Ĝi aĉetas fidindecon kontraŭ vojo, kiu ne povas porti la pli grandan kadron, kaj ĝi ŝargas superkoston por ĉiu paketo, kiu ne bezonis la malgrandigon.
Kiam pli malgranda MTU estas la ĝusta riparo
La klasika simptomo estas specifa: la TCP-manpremo finiĝas, malgrandaj respondoj alvenas, kaj granda elŝuto haltas aŭ restarigas sin. Ping kun la ne-fragmentu-bito je 1472 bajtoj malsukcesas, dum ping de 1400 bajtoj sukcesas, kio montras al vojo, kiu ne povas porti plengrandan paketon kaj ne liveras la ICMP-mesaĝon, kiu dirus al la sendinto malgrandigi.
Malkovro de la voja MTU dependas de tiuj ICMP-mesaĝoj pri necesa fragmentado. Kiam fajroŝirmilo faligas ilin, la sendinto daŭre reprovas la grandan paketon kaj la konekto ŝajnas pendi. Malaltigi la MTU-on ĉe la tunela flanko evitas la reprovon, kaj tio estas legitima riparo por tiu reto.
Ankaŭ alirteknologioj starigas siajn proprajn limojn: PPPoE kutime limiĝas je 1492, iuj movaj kaj DSL-vojoj estas pli malaltaj, kaj nestitaj tuneloj subtrahas la superkoston dufoje. Mezuru la realan vojon anstataŭ kopii nombron el gvidilo, kaj memoru, ke IPv6 postulas almenaŭ 1280 bajtojn da MTU sur ĉiu ligilo, kiu portas ĝin, kiel RFC 8200 difinas.
Komparu la tri regilojn antaŭ ol ŝanĝi unu
MTU, MSS kaj fragmentado estas malsamaj regiloj sur malsamaj tavoloj, kaj ŝanĝi la malĝustan lasas la simptomon surloke.
| 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 |
Limo de MSS ofte estas la malplej invada riparo, ĉar ĝi efikas nur sur TCP kaj lasas la interfacon libera por alia trafiko. Pli malalta interfaca MTU estas pli larĝa kaj pli facile pripensebla, tial ĝi oftas sur konsumantaj enkursigiloj, sed ĝi ŝargas al ĉiu protokolo la problemon de unu protokolo.
Malŝalti la ne-fragmentu-konduton kaŝas la simptomon permesante fragmentadon, kaj ĝi kutime plimalbonigas la kaŝprokraston dum ĝi rompas la reagon, kiu trovus la ĝustan grandecon. Evitu ĝin kiel daŭran solvon.
Mezuru la kompromison anstataŭ unu nombron
Trovu la limon de la vojo per ne-fragmentu-sondilo, komencu alte kaj malsupreniru ĝis la respondo alvenos:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Poste komparu la realan taskon ĉe ambaŭ agordoj: la sama dosiera transigo, la sama finpunkto kaj la sama reto. Notu la finiĝan tempon kaj la retransmetojn, ekzemple per nstat -az TcpRetransSegs, kaj observu la procesoron de la aparato, se la tunelo finiĝas sur malgranda enkursigilo. Mallonga sinteza trairtesto povas preteratenti la haltadon, kiu aperas nur post kelkaj megabajtoj.
Paketnombriloj altiĝos post malgrandigo, ĉar la sama transigo nun uzas pli da paketoj. Tio estas atendata kaj ne pruvas pli altan trairon. Komparu finitajn aplikaĵajn datumojn, la nombron de retransmetoj kaj la respondecon, ne nur la paketan rapidon.
Enkonduku la ŝanĝon laŭetape kaj tenu ĝin limigita
Notu la originan valoron, ŝanĝu unu regilon, kaj ripetu la mezuradon antaŭ ol fari ĝin daŭra. Se la pruvoj ne montras profiton, restarigu la antaŭan valoron per la sama interfaca komando, kiun vi uzis por agordi ĝin:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Limigu la rezulton al la reto, kiu bezonis ĝin. Profilo, kiu devas funkcii en hotelo-Wi-Fi, sur movebla hotspot kaj en oficeja LAN, ne rajtas heredi la plej malaltan valoron, kiun postulas iu ajn el ili, krom se la kliento ne povas malkovri la vojon.
La ĝusta valoro estas la plej granda MTU, kiu postvivas la vojon, ne la plej malgranda, kiu igas la simptomon malaperi. Dokumentu la vojon, la sondilan rezulton kaj la restarigon, kaj revizitu la agordon kiam la alirreto ŝanĝiĝas.