Maksimal transmissionsenhed (MTU)

Maksimal transmissionsenhed (MTU)

I computernetværk refererer udtrykket MTU (Maximum Transmission Unit) til størrelsen (i bytes) af den største PDU, som et givet lag af en kommunikationsprotokol kan sende videre. MTU-parametre vises normalt i forbindelse med en kommunikationsgrænseflade (NIC, seriel port osv.). MTU'en kan fastsættes efter standarder (som det er tilfældet med Ethernet) eller bestemmes på tilslutningstidspunktet (som det normalt er tilfældet med punkt-til-punkt serielle links). En højere MTU giver større effektivitet, fordi hver pakke bærer flere brugerdata, mens protokolomkostninger, såsom headere eller underliggende forsinkelser pr. pakke, forbliver faste, og højere effektivitet betyder en lille forbedring i bulkprotokolgennemstrømning. Store pakker kan dog optage et langsomt link i nogen tid, hvilket forårsager større forsinkelser i at følge pakker og øger forsinkelse og minimumsforsinkelse. For eksempel ville en 1500 byte-pakke, den største tilladte af Ethernet på netværkslaget (og dermed det meste af internettet), binde et 14.4k modem i omkring et sekund.

Sti MTU -opdagelse
Internetprotokollen definerer "stien MTU" for en internettransmissionssti som den mindste MTU af nogen af ​​IP-hopsene på "stien" mellem en kilde og destination. Sagt på en anden måde er stien MTU den største pakkestørrelse, der krydser denne vej uden at lide under fragmentering.

RFC 1191 beskriver "Path MTU discovery", en teknik til at bestemme stien MTU mellem to IP-værter. Det virker ved at indstille indstillingen DF (Don't Fragment) i IP-headerne på udgående pakker. Enhver enhed langs stien, hvis MTU er mindre end pakken, vil droppe sådanne pakker og sende en ICMP "Destination Unreachable (Datagram Too Big)"-meddelelse tilbage, der indeholder dens MTU, hvilket giver kildeværten mulighed for at reducere sin antagne sti-MTU på passende måde. Processen gentages, indtil MTU'en er lille nok til at krydse hele stien uden fragmentering.

Desværre falder et stigende antal netværk ICMP-trafik (f.eks. for at forhindre denial-of-service-angreb), hvilket forhindrer sti-MTU-opdagelse i at virke. Man opdager ofte en sådan blokering i de tilfælde, hvor en forbindelse fungerer for lav-volumen data, men hænger, så snart en vært sender en stor blok af data ad gangen. For eksempel kan en tilsluttende klient med IRC se op til ping-meddelelsen, men ikke få noget svar efter det. Dette skyldes, at det store sæt velkomstbeskeder sendes ud i pakker, der er større end den rigtige MTU. Også i et IP-netværk bliver stien fra kildeadressen til destinationsadressen ofte dynamisk ændret som reaktion på forskellige hændelser (belastningsbalancering, overbelastning, udfald osv.) - dette kan resultere i, at stien MTU ændres (nogle gange gentagne gange) under en transmission, hvilket kan introducere yderligere pakkefald, før værten finder den nye sikre MTU.

De fleste Ethernet-LAN'er bruger en MTU på 1500 bytes (moderne LAN'er kan bruge Jumbo-rammer, hvilket giver mulighed for en MTU på op til 9000 bytes), men grænseprotokoller som PPPoE vil reducere dette. Dette får sti-MTU-opdagelse til at træde i kraft med det mulige resultat, at nogle websteder bag dårligt konfigurerede firewalls bliver utilgængelige. Man kan eventuelt omgå dette, alt efter hvilken del af netværket man styrer; for eksempel kan man ændre MSS (maksimal segmentstørrelse) i den indledende pakke, der opsætter TCP-forbindelsen ved ens firewall.

Dette problem er dukket oftere op siden introduktionen af ​​Windows Vista, som introducerer 'Next Generation TCP/IP Stack'. Dette implementerer "Auto-tuning af modtagevindue, der kontinuerligt bestemmer den optimale modtagevinduestørrelse ved at måle båndbreddeforsinkelsesproduktet og applikationshentningshastigheden og justerer den maksimale modtagevinduestørrelse baseret på skiftende netværksforhold."[2] Dette har vist sig at mislykkes i forbindelse med ældre routere og firewalls, der så ud til at fungere med andre operativsystemer. Det ses oftest i ADSL-routere og kan ofte rettes ved en firmwareopdatering.

ATM-rygrad, et eksempel på MTU-tuning
Nogle gange er det at foretrække ud fra et effektivitetssynspunkt kunstigt at erklære en reduceret MTU i software under den sande maksimalt mulige understøttede længde. Et eksempel på dette er tilfældet, hvor IP-trafik føres over et ATM-netværk (Asynchronous Transfer Mode). Nogle udbydere, især dem med telefonibaggrund, bruger ATM på deres interne backbone-netværk.

Brug af ATM med optimal effektivitet opnås, når pakkelængden er et multiplum af 48 bytes. Dette skyldes, at ATM sendes som en strøm af pakker med fast længde (kendt som 'celler'), som hver kan bære en nyttelast på 48 bytes brugerdata med 5 bytes overhead til en samlet pris på 53 bytes pr. celle. Så den samlede længde af den transmitterede datalængde er 53 * ncells bytes, hvor ncells = antallet af nødvendige celler på = INT((nyttelast_længde+47)/48). Så i værste tilfælde, hvor den samlede længde = (48*n+1) bytes, er der behov for en ekstra celle for at transmittere den sidste byte af nyttelast, hvoraf den sidste celle koster yderligere 53 transmitterede bytes, hvoraf 47 er udfyldning. Af denne grund maksimerer kunstigt at erklære en reduceret MTU i software protokoleffektiviteten på ATM-laget ved at få ATM AAL5's samlede nyttelastlængde til at være et multiplum af 48 gange, når det er muligt.

For eksempel bærer 31 fuldstændigt fyldte ATM-celler en nyttelast på 31*48=1488 bytes. Ved at tage dette tal på 1488 og trække eventuelle overheads fra alle relevante højere protokoller fra det, kan vi få en foreslået værdi for en kunstigt reduceret optimal MTU. I det tilfælde, hvor brugeren normalt ville sende 1500 byte-pakker, kræver afsendelse af mellem 1489 og 1536 bytes en ekstra fast omkostning på 53 bytes, der sendes i form af en ekstra ATM-celle.

For eksemplet med IP over DSL-forbindelser ved brug af PPPoA/VC-MUX, igen ved at vælge at fylde 31 ATM-celler som før, opnår vi et ønsket optimalt reduceret MTU-tal på 1478 = 31*48-10 under hensyntagen til en overhead på 10 bytes bestående af af en punkt-til-punkt-protokol-overhead på 2 bytes og en AAL5-overhead på 8 bytes. Dette giver en samlet pris på 31 * 53 = 1643 bytes transmitteret via ATM fra en 1478 byte pakke sendt til PPPoA. I tilfælde af IP sendt over ADSL ved hjælp af PPPoA vil tallet 1478 være den samlede længde af IP-pakken inklusive IP-headere. Så i dette eksempel sparer man ved at holde sig til en selvpålagt reduceret MTU på 1478 i modsætning til at sende IP-pakker med en samlet længde på 1500 53 bytes pr. pakke på ATM-laget til en pris på 22 bytes reduktion af længden af ​​IP-pakker.

En maksimal MTU for PPPoE/DSL-forbindelser er 1492 pr. RFC 2516: 6 bytes er PPPoE-header, hvilket giver plads nok til en nyttelast på 1488 byte eller 31 fulde ATM-celler.

Langt om længe: Standardværdien for MTU skal være 1492.... og i tilfælde af browserproblemer eller MSN-forbindelsesproblemer skal den sænkes til værdierne 1422 og 1420.

Reference: Wikipedia

Med venlig hilsen