Maximale transmissie-eenheid (MTU)
In computernetwerken verwijst de term Maximum Transmission Unit (MTU) naar de grootte (in bytes) van de grootste PDU die een bepaalde laag van een communicatieprotocol kan doorgeven. MTU-parameters verschijnen meestal in combinatie met een communicatie-interface (NIC, seriële poort, enz.). De MTU kan worden vastgesteld door standaarden (zoals het geval is met Ethernet) of worden bepaald op het moment van verbinding (zoals meestal het geval is bij punt-naar-punt seriële verbindingen). Een hogere MTU zorgt voor meer efficiëntie omdat elk pakket meer gebruikersgegevens bevat, terwijl protocoloverheads, zoals headers of onderliggende vertragingen per pakket, vast blijven, en hogere efficiëntie betekent een lichte verbetering van de bulkprotocoldoorvoer. Grote pakketten kunnen echter enige tijd een langzame verbinding in beslag nemen, wat leidt tot grotere vertragingen bij het volgen van pakketten en toenemende vertraging en minimale latentie. Een pakket van 1500 byte, het grootste dat door Ethernet op de netwerklaag (en dus het grootste deel van het internet) wordt toegestaan, zou bijvoorbeeld een 14.4k-modem ongeveer een seconde in beslag nemen.
Pad MTU-ontdekking
Het internetprotocol definieert het "pad-MTU" van een internettransmissiepad als de kleinste MTU van alle IP-hops van het "pad" tussen een bron en een bestemming. Anders gezegd, het pad MTU is de grootste pakketgrootte die dit pad doorloopt zonder fragmentatie.
RFC 1191 beschrijft "Path MTU discovery", een techniek om het pad MTU tussen twee IP-hosts te bepalen. Het werkt door de optie DF (Do not Fragment) in te stellen in de IP-headers van uitgaande pakketten. Elk apparaat langs het pad waarvan de MTU kleiner is dan het pakket, zal dergelijke pakketten laten vallen en een ICMP-bericht "Destination Unreachable (Datagram Too Big)" met zijn MTU terugsturen, waardoor de bronhost zijn veronderstelde pad-MTU op de juiste manier kan verminderen. Het proces herhaalt zich totdat de MTU klein genoeg is om het hele pad te doorlopen zonder fragmentatie.
Helaas laten steeds meer netwerken ICMP-verkeer vallen (bijvoorbeeld om denial-of-service-aanvallen te voorkomen), waardoor pad-MTU-detectie niet werkt. Een dergelijke blokkering wordt vaak gedetecteerd in gevallen waarin een verbinding werkt voor gegevens met een laag volume, maar vastloopt zodra een host een groot gegevensblok tegelijk verzendt. Met IRC kan een verbindende client bijvoorbeeld het ping-bericht zien, maar daarna geen reactie krijgen. Dit komt omdat de grote set welkomstberichten wordt verzonden in pakketten die groter zijn dan de echte MTU. Ook wordt in een IP-netwerk het pad van het bronadres naar het bestemmingsadres vaak dynamisch gewijzigd als reactie op verschillende gebeurtenissen (taakverdeling, congestie, uitgangen, enz.) - dit kan ertoe leiden dat het pad MTU verandert (soms herhaald) tijdens een transmissie, wat verdere pakketdalingen kan introduceren voordat de host de nieuwe veilige MTU vindt.
De meeste Ethernet-LAN's gebruiken een MTU van 1500 bytes (moderne LAN's kunnen Jumbo-frames gebruiken, waardoor een MTU tot 9000 bytes mogelijk is), maar grensprotocollen zoals PPPoE zullen dit verminderen. Dit zorgt ervoor dat pad-MTU-detectie van kracht wordt met als mogelijk resultaat dat sommige sites achter slecht geconfigureerde firewalls onbereikbaar worden. Men kan hier eventueel omheen werken, afhankelijk van welk deel van het netwerk men controleert; men kan bijvoorbeeld de MSS (maximale segmentgrootte) wijzigen in het initiële pakket dat de TCP-verbinding tot stand brengt bij iemands firewall.
Dit probleem doet zich vaker voor sinds de introductie van Windows Vista, dat de 'Next Generation TCP/IP Stack' introduceert. Dit implementeert "Auto-tuning van het ontvangstvenster dat voortdurend de optimale grootte van het ontvangstvenster bepaalt door het bandbreedtevertragingsproduct en de ophaalsnelheid van de toepassing te meten, en de maximale grootte van het ontvangstvenster aan te passen op basis van veranderende netwerkomstandigheden." [2] Dit bleek te mislukken in combinatie met oudere routers en firewalls die met andere besturingssystemen leken te werken. Het wordt meestal gezien in ADSL-routers en kan vaak worden verholpen door een firmware-update.
ATM-backbones, een voorbeeld van MTU-tuning
Soms verdient het vanuit het oogpunt van efficiëntie de voorkeur om kunstmatig een verlaagde MTU in software aan te geven onder de werkelijk maximaal mogelijke lengte die wordt ondersteund. Een voorbeeld hiervan is het geval waarbij IP-verkeer via een ATM-netwerk (Asynchronous Transfer Mode) wordt overgedragen. Sommige providers, vooral die met een telefonieachtergrond, gebruiken ATM op hun interne backbone-netwerk.
Het gebruik van ATM met optimale efficiëntie wordt bereikt wanneer de pakketlengte een veelvoud van 48 bytes is. Dit komt omdat ATM wordt verzonden als een stroom van pakketten met een vaste lengte (bekend als 'cellen'), die elk een payload van 48 bytes aan gebruikersgegevens kunnen dragen met 5 bytes overhead voor een totaalbedrag van 53 bytes per cel. De totale lengte van de verzonden gegevens is dus 53 * ncells bytes, waarbij ncells = het aantal vereiste cellen van = INT((payload_length+47)/48). Dus in het ergste geval, waar de totale lengte = (48*n+1) bytes, is één extra cel nodig om de laatste byte nuttige lading te verzenden, de laatste cel kost 53 extra verzonden bytes, waarvan 47 opvulling. Om deze reden maximaliseert het kunstmatig declareren van een verminderde MTU in software de protocolefficiëntie op de ATM-laag door de totale payloadlengte van ATM AAL5 waar mogelijk een veelvoud van 48 bytes te maken.
Zo hebben 31 volledig gevulde ATM-cellen een laadvermogen van 31*48=1488 bytes. Als we dit cijfer van 1488 nemen en alle overheadkosten die worden bijgedragen door alle relevante hogere protocollen daarvan aftrekken, kunnen we een voorgestelde waarde verkrijgen voor een kunstmatig verlaagde, optimaal MTU. In het geval dat de gebruiker normaal gesproken pakketten van 1500 bytes zou verzenden, vereist het verzenden tussen 1489 en 1536 bytes extra vaste kosten van 53 bytes die worden verzonden, in de vorm van één extra ATM-cel.
Voor het voorbeeld van IP over DSL-verbindingen die PPPoA/VC-MUX gebruiken, waarbij opnieuw wordt gekozen om 31 ATM-cellen te vullen zoals eerder, verkrijgen we een gewenst optimaal gereduceerd MTU-cijfer van 1478 = 31*48-10, rekening houdend met een overhead van 10 bytes bestaande uit van een Point-to-Point Protocol-overhead van 2 bytes en een AAL5-overhead van 8 bytes. Dit geeft een totale kostprijs van 31*53=1643 bytes die via ATM worden verzonden vanuit een pakket van 1478 bytes dat wordt doorgegeven aan PPPoA. In het geval van IP verzonden via ADSL met behulp van PPPoA zou 1478 de totale lengte van het IP-pakket inclusief IP-headers zijn. Dus in dit voorbeeld bespaart het aanhouden van een zelfopgelegde gereduceerde MTU van 1478, in tegenstelling tot het verzenden van IP-pakketten met een totale lengte van 1500, 53 bytes per pakket op de ATM-laag ten koste van een vermindering van de lengte van IP-pakketten met 22 bytes.
Een maximale MTU voor PPPoE/DSL-verbindingen is 1492, per RFC 2516: 6 bytes zijnde PPPoE-header, waardoor er voldoende ruimte overblijft voor een payload van 1488 bytes, of 31 volle ATM-cellen.
Tot slot: De standaardwaarde van MTU is 1492.... en in geval van browseproblemen of MSN-verbindingsproblemen moet deze worden verlaagd naar de waarden 1422 en 1420.
Referentie: Wikipedia
Beste wensen
Hallo, Bedankt voor het nuttige artikel