Maximum Transmission Unit (MTU)

Maximal överföringsenhet (MTU)

I datanätverk hänvisar termen Maximum Transmission Unit (MTU) till storleken (i byte) på den största PDU som ett givet lager av ett kommunikationsprotokoll kan vidarebefordra. MTU -parametrar visas vanligtvis i samband med ett kommunikationsgränssnitt (NIC, serieport, etc.). MTU: n kan fastställas enligt standarder (som är fallet med Ethernet) eller beslutas vid anslutningstid (som vanligtvis är fallet med punkt-till-punkt-seriella länkar). En högre MTU ger större effektivitet eftersom varje paket bär mer användardata medan protokollets omkostnader, till exempel rubriker eller underliggande per-paketfördröjningar förblir fasta, och högre effektivitet innebär en liten förbättring av bulkprotokollgenomströmningen. Stora paket kan dock uppta en långsam länk under en tid, vilket orsakar större förseningar för att följa paket och öka fördröjning och minimal latens. Till exempel skulle ett paket på 1500 byte, det största som Ethernet tillåter vid nätverkslagret (och därmed större delen av Internet), knyta ett 14.4 k modem i ungefär en sekund.

Sökväg MTU -upptäckt
Internetprotokollet definierar "sökväg MTU" för en Internetöverföringsväg som den minsta MTU av någon av IP -humlen i "sökvägen" mellan en källa och destination. Sätt på ett annat sätt, vägen MTU är den största paketstorleken som går igenom denna väg utan att lida fragmentering.

RFC 1191 beskriver “Path MTU discovery”, en teknik för att bestämma vägen MTU mellan två IP -värdar. Det fungerar genom att ställa in alternativet DF (Don't Fragment) i IP -rubrikerna för utgående paket. Varje enhet längs banan vars MTU är mindre än paketet kommer att släppa sådana paket och skicka tillbaka ett ICMP "Destination Unreachable (Datagram Too Big)" -meddelande som innehåller dess MTU, så att källvärden kan minska sin antagna sökväg MTU på lämpligt sätt. Processen upprepas tills MTU är tillräckligt liten för att korsa hela vägen utan fragmentering.

Du kanske också är intresserad av att se: 2 WIRE routerkonfiguration

Tyvärr tappar allt fler nätverk ICMP-trafik (t.ex. för att förhindra denial-of-service-attacker), vilket hindrar sökvägen MTU-upptäckt att fungera. Man upptäcker ofta sådan blockering i de fall där en anslutning fungerar för data med låg volym men hänger så snart en värd skickar ett stort block av data åt gången. Till exempel, med IRC kan en anslutande klient se upp till ping -meddelandet, men får inget svar efter det. Detta beror på att den stora uppsättningen välkomstmeddelanden skickas ut i paket som är större än den riktiga MTU: n. Även i ett IP-nätverk ändras sökvägen från källadressen till destinationsadressen ofta dynamiskt, som svar på olika händelser (belastningsbalansering, trängsel, utdata, etc.)-detta kan leda till att MTU-vägen ändras (ibland upprepas) under en överföring, vilket kan införa ytterligare paketdroppar innan värden hittar den nya säkra MTU: n.

De flesta Ethernet -LAN använder en MTU på 1500 byte (moderna LAN kan använda Jumbo -ramar, vilket möjliggör en MTU upp till 9000 byte), men gränsprotokoll som PPPoE kommer att minska detta. Detta gör att sökväg MTU-upptäckt träder i kraft med det möjliga resultatet att vissa webbplatser bakom dåligt konfigurerade brandväggar inte kan nås. Man kan möjligen kringgå detta, beroende på vilken del av nätverket man kontrollerar; till exempel kan man ändra MSS (maximal segmentstorlek) i det ursprungliga paketet som konfigurerar TCP -anslutningen vid sin brandvägg.

Detta problem har dykt upp oftare sedan introduktionen av Windows Vista som introducerar "Next Generation TCP/IP Stack". Detta implementerar "Automatisk inställning för mottagningsfönster som kontinuerligt bestämmer den optimala mottagningsfönstret genom att mäta bandbreddsfördröjningsprodukten och programhämtningshastigheten och justerar den maximala mottagningsfönstret beroende på förändrade nätverksförhållanden." [2] Detta har sett att misslyckas i samband med äldre routrar och brandväggar som tycktes fungera med andra operativsystem. Det ses oftast i ADSL -routrar och kan ofta rättas till med en firmware -uppdatering.

Du kanske också är intresserad av att se: Läkemedel som tas på isolerade sjukhus

ATM -ryggrad, ett exempel på MTU -tuning
Ibland är det att föredra ur effektivitetssynpunkt att artificiellt deklarera en reducerad MTU i mjukvara under den verkliga maximala möjliga längden som stöds. Ett exempel på detta är fallet där IP -trafik transporteras över ett ATM -nätverk (Asynchronous Transfer Mode). Vissa leverantörer, särskilt de med telefonibakgrund, använder bankomat på sitt interna ryggradsnätverk.

Att använda ATM med optimal effektivitet uppnås när paketlängden är en multipel av 48 byte. Detta beror på att ATM skickas som en ström av paket med fast längd (känd som "celler"), som var och en kan bära en nyttolast på 48 byte användardata med 5 byte med overhead för en total kostnad av 53 byte per cell. Så den totala längden på den överförda datalängden är 53 * ncellsbyte, där ncells = antalet nödvändiga celler för = INT ((nyttolastlängd+47)/48). Så i värsta fall, där den totala längden = (48*n+1) byte, behövs en ytterligare cell för att överföra den sista byte nyttolasten, varvid den sista cellen kostar extra 53 överförda byte 47 varav vaddering. Av denna anledning maximerar artificiell förklaring av en reducerad MTU i programvara protokolleffektiviteten vid ATM -lagret genom att göra ATM AAL5 totala nyttolastlängd till en multipel av 48 byte när det är möjligt.

Till exempel har 31 helt fyllda ATM -celler en nyttolast på 31*48 = 1488 byte. Om vi tar denna siffra på 1488 och drar ifrån eventuella omkostnader från alla relevanta högre protokoll kan vi erhålla ett föreslaget värde för en artificiellt reducerad optimal MTU. I det fall där användaren normalt skulle skicka 1500 byte -paket kräver sändning mellan 1489 och 1536 byte en extra fast kostnad på 53 byte som överförs, i form av en extra ATM -cell.

Du kanske också är intresserad av att se: Hur man lägger till MTU i zxhn h108n

För exemplet IP över DSL-anslutningar med PPPoA/VC-MUX, som återigen väljer att fylla 31 ATM-celler som tidigare, får vi en önskad optimalt reducerad MTU-siffra på 1478 = 31*48-10 med hänsyn tagen till en overhead på 10 byte bestående av en punkt-till-punkt-protokoll-overhead på 2 byte och en AAL5-overhead på 8 byte. Detta ger en total kostnad på 31*53 = 1643 byte som överförs via ATM från ett 1478 byte -paket som skickas till PPPoA. När det gäller IP som skickas över ADSL med PPPoA skulle siffran 1478 vara IP -paketets totala längd inklusive IP -rubriker. Så i detta exempel sparar 1478 byte per paket vid ATM-lagret till en självpåförd reducerad MTU på 1500 i motsats till att skicka IP-paket med total längd 53 till en kostnad av en 22 bytes minskning av IP-pakets längd.

En maximal MTU för PPPoE/DSL -anslutningar är 1492, per RFC 2516: 6 byte är PPPoE -rubrik, vilket ger tillräckligt med utrymme för en nyttolast på 1488 byte eller 31 fulla ATM -celler.

Slutligen: Standardvärdet för MTU ska vara 1492 .... och vid surfningsproblem eller MSN -anslutningsproblem bör den minskas till värdena 1422 och 1420.

Referens: wikipedia

Med vänliga hälsningar