Maksimum transmissie -eenheid (MTU)

Maksimum transmissie -eenheid (MTU)

In rekenaarnetwerk verwys die term Maximum Transmission Unit (MTU) na die grootte (in grepe) van die grootste PDU wat 'n gegewe laag van 'n kommunikasieprotokol kan deurgee. MTU -parameters verskyn gewoonlik in samewerking met 'n kommunikasie -koppelvlak (NIC, seriële poort, ens.). Die MTU kan volgens standaarde vasgestel word (soos die geval is met Ethernet) of op die koppeltyd besluit word (soos gewoonlik die geval is met punt-tot-punt seriële skakels). 'N Hoër MTU bied groter doeltreffendheid omdat elke pakkie meer gebruikersdata bevat, terwyl protokolbokoste, soos opskrifte of onderliggende vertragings per pakkie, vas bly, en hoër doeltreffendheid beteken 'n effense verbetering in grootmaat protokol deurset. Groot pakkies kan egter 'n geruime tyd 'n stadige skakel inneem, wat groter vertragings in die volg van pakkies veroorsaak en 'n toename in vertraging en minimale vertraging veroorsaak. Byvoorbeeld, 'n pakket van 1500 byte, die grootste wat Ethernet by die netwerklaag toelaat (en dus die grootste deel van die internet), sal 'n 14.4k -modem vir ongeveer een sekonde vasmaak.

Pad MTU -ontdekking
Die internetprotokol definieer die 'pad MTU' van 'n internetoordragpad as die kleinste MTU van enige van die IP -hoepels van die 'pad' tussen 'n bron en bestemming. Anders gestel, die pad MTU is die grootste pakketgrootte wat hierdie pad oorsteek sonder om fragmentasie te ondergaan.

RFC 1191 beskryf "Path MTU discovery", 'n tegniek om die pad MTU tussen twee IP -gashere te bepaal. Dit werk deur die opsie DF (Don't Fragment) in die IP -koptekste van uitgaande pakkies in te stel. Elke toestel langs die pad waarvan die MTU kleiner is as die pakkie, sal sulke pakkies laat val en 'n ICMP "Destination Unreachable (Datagram Too Big)" -boodskap met sy MTU terugstuur, sodat die brongasheer sy veronderstelde pad MTU op die regte manier kan verminder. Die proses word herhaal totdat die MTU klein genoeg is om die hele pad sonder fragmentasie te deurkruis.

Ongelukkig laat toenemende aantal netwerke die ICMP-verkeer af (bv. Om ontkenning van diensaanvalle te voorkom), wat verhoed dat pad MTU-ontdekking werk. 'N Mens ontdek dikwels so 'n blokkering in die gevalle waar 'n verbinding vir lae-volume data werk, maar dit hang sodra 'n gasheer 'n groot blok data op 'n slag stuur. Byvoorbeeld, met IRC kan 'n verbindingskliënt die pingboodskap sien, maar daarna geen reaksie kry nie. Dit is omdat die groot stel welkome boodskappe in pakkies groter as die regte MTU gestuur word. Ook in 'n IP-netwerk word die pad van die bronadres na die bestemmingsadres dikwels dinamies aangepas in reaksie op verskillende gebeurtenisse (lasbalansering, opeenhoping, uitsette, ens.)-dit kan daartoe lei dat die pad MTU verander (soms herhaal) tydens 'n oordrag, wat verdere pakkiedruppels kan veroorsaak voordat die gasheer die nuwe veilige MTU vind.

Die meeste Ethernet -LAN's gebruik 'n MTU van 1500 grepe (moderne LAN's kan Jumbo -rame gebruik, wat 'n MTU tot 9000 grepe moontlik maak), maar grensprotokolle soos PPPoE sal dit verminder. Dit veroorsaak dat pad MTU-ontdekking in werking tree, met die moontlike gevolg dat sommige webwerwe agter swak gekonfigureerde firewalls onbereikbaar is. U kan moontlik hieraan werk, afhangende van watter deel van die netwerk u beheer; u kan byvoorbeeld die MSS (maksimum segmentgrootte) verander in die aanvanklike pakket wat die TCP -verbinding by u eie firewall opstel.

Hierdie probleem het meer gereeld na vore gekom sedert die bekendstelling van Windows Vista, wat die 'Next Generation TCP/IP Stack' bekendstel. Dit implementeer “Ontvang venster outomaties afstem, wat die optimale ontvangsvenstergrootte voortdurend bepaal deur die bandwydte-vertragingsproduk en die hersteltempo van die program te meet, en pas die maksimum ontvangsvenstergrootte aan op grond van veranderende netwerkomstandighede.” [2] Dit blyk dat dit misluk in samewerking met ouer routers en firewalls wat blykbaar met ander bedryfstelsels werk. Dit word meestal in ADSL -routers gesien en kan dikwels reggestel word deur 'n firmware -opdatering.

OTM -ruggraat, 'n voorbeeld van MTU -tuning
Soms is dit uit die oogpunt van doeltreffendheid verkieslik om 'n verminderde MTU in sagteware onder die werklike maksimum moontlike lengte kunsmatig te verklaar. Een voorbeeld hiervan is die geval waar IP -verkeer oor 'n OTM -netwerk (Asynchronous Transfer Mode) vervoer word. Sommige verskaffers, veral diegene met 'n telefoniese agtergrond, gebruik OTM op hul interne ruggraatnetwerk.

Die gebruik van OTM teen optimale doeltreffendheid word verkry wanneer die pakkie 'n veelvoud van 48 grepe is. Dit is omdat OTM gestuur word as 'n stroom pakkette met 'n vaste lengte (bekend as 'selle'), wat elk 'n vrag van 48 grepe gebruikersdata met 5 grepe oorhoofse koste kan lewer, teen 'n totale koste van 53 grepe per sel. Die totale lengte van die gestuurde datalengte is dus 53 * ncells grepe, waar ncells = die aantal vereiste selle van = INT ((payload_length+47)/48). In die ergste geval, waar die totale lengte = (48*n+1) grepe, is daar nog 'n ekstra sel nodig om die laaste greep loonvrag oor te dra, waarvan die finale sel 'n ekstra 53 gestuurde grepe 47 kos, waarvan 5 gevul is. Om hierdie rede maksimeer die kunsmatige verklaring van 'n verminderde MTU in sagteware die doeltreffendheid van die protokol by die OTM -laag, deur die totale ATM AAL48 totale loonvraglengte soveel as XNUMX bytes te maak.

Byvoorbeeld, 31 volledig gevulde OTM -selle dra 'n vrag van 31*48 = 1488 grepe. As ons hierdie syfer van 1488 neem en alle uitgawes wat deur alle relevante hoër protokolle bygedra word, aftrek, kan ons 'n voorgestelde waarde verkry vir 'n kunsmatig verminderde optimaal MTU. In die geval waar die gebruiker normaalweg 1500 byte pakkies stuur, benodig die stuur van tussen 1489 en 1536 grepe 'n ekstra vaste koste van 'n 53 byte gestuur, in die vorm van een ekstra OTM -sel.

Vir die voorbeeld van IP via DSL-verbindings met PPPoA/VC-MUX, en weer kies om 31 OTM-selle soos voorheen te vul, kry ons 'n gewenste optimaal verlaagde MTU-syfer van 1478 = 31*48-10, met inagneming van 'n bokoste van 10 grepe bestaande uit van 'n punt-tot-punt-protokol bokoste van 2 grepe, en 'n AAL5 bokoste van 8 grepe. Dit gee 'n totale koste van 31*53 = 1643 grepe wat via OTM gestuur word vanaf 'n pakkie van 1478 byte wat aan PPPoA deurgegee is. In die geval van IP wat via ADSL gestuur word met PPPoA, is die syfer van 1478 die totale lengte van die IP -pakket, insluitend IP -opskrifte. In hierdie voorbeeld bespaar u dus by 'n selfopgelegde verminderde MTU van 1478, in teenstelling met die stuur van IP-pakkies met 'n totale lengte van 1500, 53 grepe per pakkie by die OTM-laag teen 'n koste van 22 byte van die lengte van IP-pakkies.

'N Maksimum MTU vir PPPoE/DSL -verbindings is 1492, per RFC 2516: 6 grepe is PPPoE -koptekst, wat genoeg ruimte laat vir 'n 1488 byte -vrag of 31 volledige OTM -selle.

Ten slotte: Die standaardwaarde van MTU moet 1492 wees ... en in geval van blaaiprobleme of MSN -verbindingsprobleme, moet dit verminder word tot die waardes 1422 en 1420.

Verwysing: Wikipedia

Beste groete