Maximális átviteli egység (MTU)

Maximális átviteli egység (MTU)

A számítógépes hálózatokban a Maximum Transmission Unit (MTU) kifejezés a legnagyobb PDU méretére vonatkozik (bájtban), amelyet egy kommunikációs protokoll adott rétege továbbíthat. Az MTU paraméterek általában kommunikációs interfésszel (NIC, soros port stb.) Együtt jelennek meg. Az MTU-t szabványok rögzíthetik (mint az Ethernet esetében), vagy a csatlakozáskor dönthetnek (mint általában a pont-pont soros kapcsolatok esetében). A magasabb MTU nagyobb hatékonyságot eredményez, mivel minden csomag több felhasználói adatot hordoz, miközben a protokoll általános költségei, például fejlécek vagy csomagonkénti késleltetések rögzítetlenek maradnak, és a nagyobb hatékonyság kismértékű javulást jelent a tömeges protokollátviteli sebességben. A nagy csomagok azonban egy ideig lassú kapcsolatot foglalhatnak el, ami nagyobb késleltetést okoz a csomagok követésében, és növeli a késést és a minimális késleltetést. Például egy 1500 bájtos csomag, a legnagyobb, amelyet az Ethernet engedélyez a hálózati rétegben (és ezáltal az Internet nagy részében), körülbelül 14.4 ezer modemet köt le körülbelül egy másodpercre.

Útvonal MTU felfedezése
Az Internet Protocol az internetes átviteli útvonal „útvonal MTU -ját” a forrás és a cél közötti „út” IP -ugrásai közül a legkisebb MTU -ként határozza meg. Más szóval, az MTU útvonal a legnagyobb csomagméret, amely ezen az úton halad át, anélkül, hogy széttöredezne.

Az RFC 1191 leírja az „Útvonal MTU felderítését”, egy technikát az MTU útvonal meghatározására két IP -gazdagép között. Ez úgy működik, hogy a kimenő csomagok IP -fejlécében beállítja a DF (ne töredezzen) opciót. Bármely eszköz az útvonal mentén, amelynek MTU -ja kisebb, mint a csomag, eldobja az ilyen csomagokat, és visszaküldi az ICMP „Destination Unreachable (Datagram Too Big)” üzenetét, amely tartalmazza az MTU -t, lehetővé téve a forrásgazda számára, hogy megfelelően csökkentse a feltételezett MTU útvonalat. A folyamat addig ismétlődik, amíg az MTU nem elég kicsi ahhoz, hogy töredezettség nélkül végighaladjon az egész úton.

Sajnos egyre több hálózat csökkenti az ICMP forgalmat (pl. A szolgáltatásmegtagadási támadások megelőzése érdekében), ami megakadályozza, hogy az útvonal MTU felderítése működjön. Az ilyen blokkolást gyakran észleli azokban az esetekben, amikor a kapcsolat kis volumenű adatok esetén működik, de lefagy, amint a gazda egyszerre nagy adatblokkot küld. Például az IRC esetén a csatlakozó kliens láthatja a ping üzenetet, de ezután nem kap választ. Ez azért van, mert az üdvözlő üzenetek nagy halmaza nagyobb csomagokban kerül kiküldésre, mint a valódi MTU. Ezenkívül egy IP-hálózatban a forráscímtől a célcímig vezető út gyakran dinamikusan módosul, különböző események (terheléselosztás, torlódás, kimenetek stb.) Hatására-ez az MTU útvonal változását eredményezheti (néha megismétlődik) az átvitel során, amely további csomagcseppeket vezethet be, mielőtt a gazda megtalálja az új biztonságos MTU -t.

A legtöbb Ethernet LAN 1500 bájtos MTU -t használ (a modern LAN -ok használhatnak Jumbo kereteket, lehetővé téve akár 9000 bájt MTU -t), azonban a határprotokollok, mint például a PPPoE, ezt csökkentik. Ez azt eredményezi, hogy az útvonal-MTU-felfedezés életbe lép, ami azt eredményezheti, hogy egyes webhelyek elérhetetlenné válnak a rosszul konfigurált tűzfalak mögött. Lehet ezt megkerülni, attól függően, hogy a hálózat melyik részét vezérli; például meg lehet változtatni az MSS -t (maximális szegmensméretet) a kezdeti csomagban, amely létrehozza a TCP -kapcsolatot a tűzfalon.

Ez a probléma gyakrabban merült fel a Windows Vista bevezetése óta, amely bevezeti a „Next Generation TCP/IP Stack” -t. Ez megvalósítja a „Vételi ablak automatikus hangolását, amely folyamatosan meghatározza az optimális fogadási ablak méretét a sávszélesség-késleltetés termék és az alkalmazás lekérési arányának mérésével, és beállítja a maximális fogadási ablakméretet a változó hálózati feltételek alapján.” [2] Ez láthatóan meghiúsult a régebbi útválasztókkal és tűzfalakkal együtt, amelyek más operációs rendszerekkel működtek együtt. Leggyakrabban az ADSL útválasztókban látható, és gyakran javítható firmware frissítéssel.

ATM gerinc, példa az MTU hangolásra
Néha a hatékonyság szempontjából előnyösebb, ha mesterségesen deklarálják a csökkentett MTU -t a szoftverekben a ténylegesen megengedett maximális hossz alatt. Ennek egyik példája az az eset, amikor az IP -forgalmat ATM (aszinkron átviteli mód) hálózaton keresztül továbbítják. Egyes szolgáltatók, különösen a telefonos háttérrel rendelkezők, ATM -et használnak belső gerinchálózatukban.

Az ATM optimális hatékonyságú használata akkor érhető el, ha a csomag hossza 48 bájt többszöröse. Ennek oka az, hogy az ATM-et rögzített hosszúságú csomagok (úgynevezett „cellák”) formájában küldik el, amelyek mindegyike 48 bájtos felhasználói adatot és 5 bájt általános költséget tud szállítani, cellánként 53 bájtos összköltséggel. Tehát az átvitt adathossz teljes hossza 53 * ncellás bájt, ahol ncellák = a szükséges cellák száma = INT ((hasznos terhelés_hossza+47)/48). Tehát a legrosszabb esetben, ahol a teljes hossz = (48*n+1) bájt, egy további cellára van szükség a hasznos terhelés utolsó bájtjának továbbításához, a végső cella pedig további 53 továbbított bájtba kerül, amelyek közül 47 kitöltés. Emiatt a csökkentett MTU mesterséges deklarálása a szoftverben maximalizálja a protokoll hatékonyságát az ATM rétegben azáltal, hogy az ATM AAL5 teljes hasznos terhelésének hossza 48 bájt, amikor csak lehetséges.

Például 31 teljesen kitöltött ATM cella 31*48 = 1488 bájt hasznos terhet hordoz. Ha ezt az 1488 -as számot levonjuk, és levonjuk belőle az összes vonatkozó magasabb protokoll által okozott általános költséget, akkor megkaphatjuk a mesterségesen csökkentett, optimálisan MTU javasolt értékét. Abban az esetben, ha a felhasználó általában 1500 bájtos csomagot küldene, az 1489 és 1536 bájt közötti küldés további 53 bájt fix költséget igényel, egy további ATM cella formájában.

Például a PPPoA/VC-MUX-ot használó IP-kapcsolaton keresztül, DSL-kapcsolaton keresztül, ismét a 31 ATM-cella kitöltése mellett döntve, a kívánt optimálisan csökkentett 1478 = 31*48-10 MTU-értéket kapjuk, figyelembe véve a 10 bájtos többletköltséget. 2 bájt és egy 5 bájtos AAL8 rezsi. Ez 31*53 = 1643 bájt összköltséget eredményez az ATM -en keresztül egy PPPoA -nak továbbított 1478 bájtos csomagból. A PPPoA használatával ADSL -n keresztül küldött IP esetén az 1478 -as szám az IP -csomag teljes hossza, beleértve az IP -fejléceket. Tehát ebben a példában a saját maga által meghatározott, 1478-as csökkentett MTU-t tartva, szemben az 1500 teljes hosszúságú IP-csomagok küldésével, csomagonként 53 bájtot takarít meg az ATM-rétegben, 22 bájtos IP-csomagok hosszának csökkentésével.

A PPPoE/DSL -kapcsolatok maximális MTU -értéke 1492, RFC 2516 szerint: 6 bájt PPPoE -fejléc, elegendő helyet hagyva egy 1488 bájtos hasznos terhelésnek vagy 31 teljes ATM -cellának.

Végül: Az MTU standard értéke 1492 ... és böngészési problémák vagy MSN csatlakozási problémák esetén az 1422 és 1420 értékekre kell csökkenteni.

Referencia: Wikipedia

Üdvözlettel: