Gyorsabb a kisebb VPN MTU? Hasonlítsa össze a tényleges bizonyítékokat
Az alacsonyabb MTU megkerülheti az útvonal korlátját, és mégis átbocsátást költhet. Hasonlítsa össze a valódi korlátot, a fejlécek többletköltségét és a munkaterhelést, mielőtt megtartaná a változtatást.
Az alagút eldobja a nagy átviteleket, de átengedi a pingeket, ezért a tanács gyorsan jön: csökkentse az MTU-t. A javítás néha működik, aztán minden hálózaton minden profilra alkalmazzák. Ezen a ponton a célzott javítás állandó teljesítményadóvá válik. Az összehasonlítást az útvonal valódi korlátja és az egyes csomagok e korlát alá zsugorításának költsége között kell megtenni.
Mi zsugorodik valójában, amikor csökkenti az MTU-t
Minden csomag fejléceket hordoz, mielőtt az adatait hordozná. Egy 1500 bájtos Ethernet-útvonalon az IPv4 és a TCP 40 bájtot fogyaszt, és 1460-at hagy a hasznos tehernek; a beágyazás felülre külső IP-, UDP- és alagútfejléceket tesz, így a belső terhelési keret ismét csökken. Az interfész MTU-jának csökkentése szándékosan zsugorítja ezt a keretet.
A költség a csomagok számával arányos, nem a bájtok számával. Ugyanaz a fájl több csomagra osztva több megszakítást, több útválasztási döntést és több csomagonkénti feldolgozást igényel az útvonal minden eszközén. Egy olyan routeren, amely már közel van a másodpercenkénti csomagkorlátjához, ez valódi lassulás, nem kerekítési hiba. A költség akkor is megmutatkozik, amikor maga az átvitel sikerül.
Ezért a kisebb MTU egy korlát megkerülése, nem általános optimalizálás. Megbízhatóságot vásárol egy olyan útvonallal szemben, amely nem képes a nagyobb keretet szállítani, és többletköltséget számít fel minden csomagért, amelynek nem volt szüksége a csökkentésre.
Mikor a kisebb MTU a helyes javítás
A klasszikus tünet konkrét: a TCP kézfogás befejeződik, kis válaszok érkeznek, és egy nagy letöltés elakad vagy visszaáll. A 1472 bájton ne-töredezz bittel küldött ping meghiúsul, míg a 1400 bájtos ping sikerül, ami olyan útvonalra utal, amely nem képes teljes méretű csomagot szállítani, és nem kézbesíti azt az ICMP-üzenetet, amely megmondaná a küldőnek, hogy csökkentsen.
Az útvonal MTU-felderítése ezekre az ICMP töredezettség-szükséglet üzenetekre támaszkodik. Amikor egy tűzfal eldobja őket, a küldő újra és újra próbálja a nagy csomagot, és a kapcsolat lefagyni látszik. Az MTU csökkentése az alagút oldalán elkerüli az ismétlést, és ez jogos javítás annak a hálózatnak.
A hozzáférési technológiák is saját korlátokat szabnak: a PPPoE általában 1492-nél véget ér, egyes mobil- és DSL-útvonalak alacsonyabbak, a beágyazott alagutak pedig kétszer vonják le a többletköltséget. Mérje meg a tényleges útvonalat ahelyett, hogy számot másolna egy útmutatóból, és ne feledje, hogy az IPv6 legalább 1280 bájt MTU-t követel minden olyan kapcsolaton, amely hordozza, ahogy az RFC 8200 meghatározza.
Hasonlítsa össze a három szabályzót, mielőtt egyet megváltoztat
Az MTU, az MSS és a töredezettség különböző szabályzók különböző rétegeken, és a rossz megváltoztatása a helyén hagyja a tünetet.
| 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 |
Az MSS korlátozása gyakran a legkevésbé invazív javítás, mert csak a TCP-re hat, és szabadon hagyja az interfészt más forgalomnak. Az alacsonyabb interfész-MTU szélesebb és könnyebben átgondolható, ezért gyakori a fogyasztói routereken, de minden protokollal egyetlen protokoll problémáját fizetteti meg.
A ne-töredezz viselkedés kikapcsolása elrejti a tünetet azzal, hogy engedi a töredezettséget, és általában rontja a késleltetést, miközben eltöri azt a visszajelzést, amely megtalálta volna a helyes méretet. Kerülje állandó megoldásként.
A kompromisszumot mérje, ne egyetlen számot
Keresse meg az útvonal korlátját egy ne-töredezz próbával, induljon magasról, és lépkedjen lefelé, amíg a válasz meg nem érkezik:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Utána hasonlítsa össze a valódi feladatot mindkét beállításon: ugyanazt a fájlátvitelt, ugyanazt a végpontot és ugyanazt a hálózatot. Jegyezze fel a befejezési időt és az újraküldéseket, például a nstat -az TcpRetransSegs paranccsal, és figyelje az eszköz processzorát, ha az alagút kis routeren végződik. Egy rövid szintetikus átbocsátásteszt kihagyhatja azt az elakadást, amely csak több megabájt után jelenik meg.
A csomagszámlálók növekedni fognak a csökkentés után, mert ugyanaz az átvitel most több csomagot használ. Ez várható, és nem bizonyíték a nagyobb átbocsátásra. Hasonlítsa össze a befejezett alkalmazásadatokat, az újraküldések számát és a válaszkészséget, ne csak a csomagsebességet.
Fokozatosan vezesse be a változtatást, és tartsa korlátozottan
Jegyezze fel az eredeti értéket, változtasson meg egy szabályzót, és ismételje meg a mérést, mielőtt véglegessé teszi. Ha a bizonyítékok nem mutatnak hasznot, állítsa vissza az előző értéket ugyanazzal az interfészparanccsal, amellyel beállította:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Korlátozza az eredményt arra a hálózatra, amelynek szüksége volt rá. Egy profilnak, amelynek hotel Wi-Fi-n, mobil hotspoton és irodai LAN-on kell működnie, nem kellene örökölnie a legkisebb értéket, amelyet bármelyikük megkövetel, kivéve, ha a kliens nem képes felderíteni az útvonalat.
A helyes érték a legnagyobb MTU, amely túléli az útvonalat, nem a legkisebb, amely eltünteti a tünetet. Dokumentálja az útvonalat, a próba eredményét és a visszaállítást, és vizsgálja felül a beállítást, amikor a hozzáférési hálózat megváltozik.