Maximum Transmission Unit (MTU)

Maksimal overføringsenhet (MTU)

I datanettverk refererer begrepet Maximum Transmission Unit (MTU) til størrelsen (i byte) på den største PDU som et gitt lag i en kommunikasjonsprotokoll kan passere videre. MTU -parametere vises vanligvis i forbindelse med et kommunikasjonsgrensesnitt (NIC, seriell port, etc.). MTU kan være fastsatt av standarder (som tilfellet er med Ethernet) eller bestemt ved tilkoblingstidspunkt (som vanligvis er tilfelle med punkt-til-punkt serielle lenker). En høyere MTU gir større effektivitet fordi hver pakke bærer flere brukerdata mens protokollkostnader, for eksempel overskrifter eller underliggende forsinkelser per pakke, forblir faste, og høyere effektivitet betyr en liten forbedring i bulkprotokolloverføringen. Imidlertid kan store pakker oppta en treg kobling en stund, noe som kan føre til større forsinkelser for å følge pakker og øke forsinkelse og minimum ventetid. For eksempel vil en pakke på 1500 byte, den største tillatt av Ethernet på nettverkslaget (og dermed det meste av Internett), knytte et 14.4 k modem i omtrent ett sekund.

MTU -sti -oppdagelse
Internettprotokollen definerer "banen MTU" til en Internett -overføringsbane som den minste MTU av noen av IP -hoppene til "banen" mellom en kilde og destinasjon. Sagt på en annen måte, banen MTU er den største pakkestørrelsen som krysser denne banen uten å bli fragmentert.

RFC 1191 beskriver “Path MTU discovery”, en teknikk for å bestemme banen MTU mellom to IP -verter. Det fungerer ved å angi alternativet DF (Don't Fragment) i IP -overskriftene til utgående pakker. Enhver enhet langs banen hvis MTU er mindre enn pakken, slipper slike pakker og sender tilbake en ICMP “Destination Unreachable (Datagram Too Big)” -melding som inneholder dens MTU, slik at kildeverten kan redusere den antatte banen MTU på riktig måte. Prosessen gjentas til MTU er liten nok til å krysse hele banen uten fragmentering.

Du kan også være interessert i å se: 2 WIRE ruterkonfigurasjon

Dessverre reduserer stadig flere nettverk ICMP-trafikk (f.eks. For å forhindre tjenestenektangrep), noe som forhindrer at MTU-oppdagelse fungerer. Man oppdager ofte slik blokkering i tilfeller der en tilkobling fungerer for data med lavt volum, men henger så snart en vert sender en stor blokk med data om gangen. For eksempel, med IRC kan en tilkoblende klient se opp til ping -meldingen, men får ikke noe svar etter det. Dette er fordi det store settet med velkomstmeldinger sendes ut i pakker som er større enn den virkelige MTU. I et IP-nettverk blir banen fra kildeadressen til destinasjonsadressen ofte endret dynamisk, som svar på forskjellige hendelser (lastbalansering, overbelastning, utdata, etc.)-dette kan føre til at banen MTU endres (noen ganger gjentatt) under en overføring, som kan innføre ytterligere pakkedråper før verten finner den nye trygge MTU.

De fleste Ethernet -LAN bruker en MTU på 1500 byte (moderne LAN kan bruke Jumbo -rammer, noe som gir en MTU opptil 9000 byte), men grenseprotokoller som PPPoE vil redusere dette. Dette får stien MTU-oppdagelse til å tre i kraft med det mulige resultatet at noen nettsteder bak dårlig konfigurerte brannmurer ikke kan nås. Man kan muligens omgå dette, avhengig av hvilken del av nettverket man kontrollerer; for eksempel kan man endre MSS (maksimal segmentstørrelse) i den opprinnelige pakken som setter opp TCP -tilkoblingen på brannmuren.

Dette problemet har dukket opp oftere siden introduksjonen av Windows Vista som introduserer 'Next Generation TCP/IP Stack'. Dette implementerer "Mottag vindu Auto-Tuning som kontinuerlig bestemmer den optimale mottaksvinduets størrelse ved å måle båndbreddeforsinkelsesproduktet og applikasjonshentingshastigheten, og justerer maksimal mottaksvinduestørrelse basert på endrede nettverksforhold." [2] Dette har vist seg å mislykkes i forbindelse med eldre rutere og brannmurer som syntes å fungere med andre operativsystemer. Det er oftest sett i ADSL -rutere og kan ofte rettes opp med en fastvareoppdatering.

Du kan også være interessert i å se: Medisiner tatt på isolasjonssykehus

ATM -ryggrad, et eksempel på MTU -tuning
Noen ganger er det å foretrekke ut fra et synspunkt om effektivitet å kunstig erklære en redusert MTU i programvare under den virkelige maksimalt mulige lengden som støttes. Et eksempel på dette er tilfellet der IP -trafikk overføres over et ATM -nettverk (asynkron overføringsmodus). Noen tilbydere, spesielt de med telefonibakgrunn, bruker minibank på sitt interne ryggradenettverk.

Bruk av minibank med optimal effektivitet oppnås når pakkelengden er et multiplum på 48 byte. Dette er fordi minibank sendes som en strøm av pakker med fast lengde (kjent som 'celler'), som hver kan bære en nyttelast på 48 byte brukerdata med 5 byte overhead for en total kostnad på 53 byte per celle. Så den totale lengden på den overførte datalengden er 53 * ncellbyte, hvor nceller = antall nødvendige celler på = INT ((nyttelastlengde+47)/48). Så i verste fall, hvor den totale lengden = (48*n+1) byte, er det nødvendig med en ekstra celle for å overføre den siste byte nyttelast, den siste cellen koster ekstra 53 overførte byte, 47 av disse er polstring. Av denne grunn maksimerer kunstig erklæring av redusert MTU i programvare protokolleffektiviteten ved ATM -laget ved å gjøre ATM AAL5 total nyttelastlengde til et multiplum på 48 byte når det er mulig.

For eksempel bærer 31 fullstendig fylte minibanker en nyttelast på 31*48 = 1488 byte. Ved å ta dette tallet 1488 og trekke fra det eventuelle omkostninger bidratt med alle relevante høyere protokoller, kan vi oppnå en foreslått verdi for en kunstig redusert optimalt MTU. I tilfelle hvor brukeren normalt ville sende 1500 byte pakker, krever sending mellom 1489 og 1536 byte en ekstra fast kostnad på 53 byte som sendes, i form av en ekstra minibank.

Du kan også være interessert i å se: Hvordan legge til MTU i zxhn h108n

For eksempel på IP over DSL-tilkoblinger som bruker PPPoA/VC-MUX, og igjen velger å fylle 31 ATM-celler som før, får vi et ønsket optimalt redusert MTU-tall på 1478 = 31*48-10 med tanke på en overhead på 10 byte bestående av en punkt-til-punkt-protokoll overhead på 2 byte, og en AAL5 overhead på 8 byte. Dette gir en total kostnad på 31*53 = 1643 byte overført via minibank fra en pakke på 1478 byte sendt til PPPoA. Når det gjelder IP sendt over ADSL ved hjelp av PPPoA, vil tallet 1478 være den totale lengden på IP -pakken inkludert IP -overskrifter. Så i dette eksemplet ved å holde en selvpålagt redusert MTU på 1478 i motsetning til å sende IP-pakker med en total lengde på 1500, sparer du 53 byte per pakke i ATM-laget til en kostnad på en 22 byte reduksjon av lengden på IP-pakker.

En maksimal MTU for PPPoE/DSL -tilkoblinger er 1492, per RFC 2516: 6 byte er PPPoE -topptekst, noe som gir nok plass til en nyttelast på 1488 byte eller 31 fulle minibanker.

Endelig: Standardverdien til MTU skal være 1492 .... og ved nettleserproblemer eller problemer med MSN -tilkobling bør den reduseres til verdiene 1422 og 1420.

Referanse: Wikipedia

Med vennlig hilsen