Maksimuma Transdona Unueco (MTU)

Maksimuma Transdona Unueco (MTU)

En komputila reto, la termino Maksimuma Transdona Unueco (MTU) rilatas al la grandeco (en bajtoj) de la plej granda PDU, kiun donita tavolo de komunikada protokolo povas transdoni. MTU-parametroj kutime aperas lige kun komunikada interfaco (NIC, seria pordo, ktp). La MTU povas esti fiksita per normoj (kiel okazas kun Eterreto) aŭ decidita ĉe konekta tempo (kiel kutime okazas kun punkt-al-punktaj seriaj ligoj). Pli alta MTU alportas pli grandan efikecon ĉar ĉiu pakaĵeto portas pli da uzantodatenoj dum protokolaj lumfolioj, kiel ekzemple titoloj aŭ subaj po-pakaĵaj prokrastoj restas fiksaj, kaj pli alta efikeco signifas iometan plibonigon en groca protokolrapideco. Tamen grandaj pakaĵoj povas okupi malrapidan ligon dum iom da tempo, kaŭzante pli grandajn prokrastojn al sekvaj pakaĵoj kaj pliigante malfruon kaj minimuman latentecon. Ekzemple, pakaĵo de 1500 bajtoj, la plej granda permesita de Eterreto ĉe la reta tavolo (kaj do plej multe de la interreto), ligos 14.4k-modemon dum ĉirkaŭ unu sekundo.

Vojo MTU-malkovro
La Interreta Protokolo difinas la "vojon MTU" de interreta transdona vojo kiel la plej malgrandan MTU de iu ajn el la IP-saltetoj de la "vojo" inter fonto kaj celloko. Alimaniere dirite, la vojo MTU estas la plej granda paka grandeco, kiu trairas ĉi tiun vojon sen suferi fragmentiĝon.

RFC 1191 priskribas "Vojon MTU-malkovron", teknikon por determini la vojon MTU inter du IP-gastigantoj. Ĝi funkcias agordante la opcion DF (Ne Fragmentu) en la IP-kaplinioj de eksiĝintaj pakoj. Ĉiu aparato laŭ la vojo, kies MTU estas pli malgranda ol la paketo, faligos tiajn paketojn kaj resendos mesaĝon ICMP "Destinebla Neatingebla (Datagramo Tro Granda)" enhavantan sian MTU, permesante al la fonta gastiganto malpliigi sian supozitan vojon MTU taŭge. La procezo ripetas ĝis la MTU estas sufiĉe malgranda por trairi la tutan vojon sen fragmentiĝo.

Bedaŭrinde kreskantaj nombroj da retoj faligas ICMP-trafikon (ekz. Por malebligi rifuzojn de servo-atakoj), kio malebligas funkcii malkovron de MTU-vojo. Oni ofte detektas tian blokadon en la kazoj, kiam ligo funkcias por malaltaj volumaj datumoj sed pendas tuj kiam gastiganto sendas grandan blokon de datumoj samtempe. Ekzemple, kun IRC konektanta kliento povus vidi la ping-mesaĝon, sed ne ricevos respondon post tio. Ĉi tio estas ĉar la granda aro da bonvenaj mesaĝoj estas senditaj en pakoj pli grandaj ol la vera MTU. Ankaŭ en IP-reto, la vojo de la fonta adreso al la celloka adreso ofte ŝanĝiĝas dinamike, responde al diversaj eventoj (ŝarĝ-ekvilibrigado, obstrukciĝo, eliroj, ktp) - ĉi tio povus rezultigi la ŝanĝon de la vojo MTU (foje ripetita) dum transdono, kiu povas enkonduki pliajn paketajn gutojn antaŭ ol la gastiganto trovos la novan sekuran MTU.

Plej multaj Ethernet-retoj uzas MTU de 1500 bajtoj (modernaj LAN povas uzi Jumbo-kadrojn, permesante MTU ĝis 9000 bajtoj), tamen landlimaj protokoloj kiel PPPoE malpliigos ĉi tion. Ĉi tio kaŭzas vojon MTU-eltrovo kun la ebla rezulto de igi iujn retejojn malantaŭ malbone agorditaj fajromuroj neatingeblaj. Oni povas ĉirkaŭiri tion, depende de kiu parto de la reto oni regas; ekzemple oni povas ŝanĝi la MSS (maksimuma segmentograndeco) en la komenca pakaĵo, kiu starigas la TCP-konekton ĉe onia fajromuro.

Ĉi tiu problemo aperis pli ofte ekde la enkonduko de Vindozo Vista, kiu enkondukas la 'Sekvan Generacion TCP / IP Stack'. Ĉi tio efektivigas "Aŭtomatan Agordon de Ricevado de Fenestroj, kiu kontinue determinas la optimuman fenestran grandecon per ricevo mezurante la larĝan bandan prokrastan produkton kaj la programon retrovi rapidon, kaj ĝustigas la maksimuman fenestran ricevan grandecon surbaze de ŝanĝiĝantaj retaj kondiĉoj." [2] Ĉi tio estis malsukcesita kune kun pli malnovaj enkursigiloj kaj fajromuroj, kiuj ŝajnis funkcii kun aliaj operaciumoj. Ĝi estas plej ofte vidata en ADSL-enkursigiloj kaj ofte povas esti korektita per firmvara ĝisdatigo.

ATM-spinoj, ekzemplo de MTU-agordo
Foje estas preferinde el la vidpunkto de efikeco artefarite deklari reduktitan MTU en programoj sub la vera maksimuma ebla longeco subtenata. Unu ekzemplo de ĉi tio estas la kazo, kiam IP-trafiko estas transportita per ATM (Asynchronous Transfer Mode) reto. Iuj provizantoj, precipe tiuj kun telefonia fono, uzas ATM en sia interna spina reto.

Uzado de ATM ĉe optimuma efikeco atingiĝas kiam pakaĵeta longo estas oblo de 48 bajtoj. Ĉi tio estas ĉar ATM estas sendita kiel fluo de fiks-longaj pakoj (konataj kiel 'ĉeloj'), ĉiu el kiuj povas porti utilan ŝarĝon de 48 bajtoj da uzantaj datumoj kun 5 bajtoj da supre por tuta kosto de 53 bajtoj por ĉelo. Do la totala longo de la elsendita datuma longo estas 53 * nĉelaj bajtoj, kie nĉeloj = la nombro de bezonataj ĉeloj de = INT ((utila ŝarĝo_longo + 47) / 48). Do en la plej malbona kazo, kie la totala longo = (48 * n + 1) bajtoj necesas unu aldona ĉelo por transdoni la lastan bajton da utila ŝarĝo, la fina ĉelo kostas pliajn 53 elsenditajn bajtojn 47 el kiuj plenigas. Tial, artefarite deklari reduktitan MTU en programoj maksimumigas protokolan efikecon ĉe la ATM-tavolo per tio, ke la ATM AAL5-totala utila ŝarĝa longo estu multoblo de 48 bajtoj kiam ajn eblas.

Ekzemple, 31 tute plenigitaj ATM-ĉeloj portas utilan ŝarĝon de 31 * 48 = 1488 bajtoj. Prenante ĉi tiun ciferon de 1488 kaj subtrahante de ĝi iujn ajn kostojn kontribuitajn de ĉiuj koncernaj pli altaj protokoloj, ni povas akiri sugestitan valoron por artefarite reduktita optimume MTU. En la kazo, kiam la uzanto kutime sendus 1500 bajtajn paketojn, sendi inter 1489 kaj 1536 bajtoj postulas aldonan fiksan koston de 53 bajtoj transdonitaj, en la formo de unu ekstra ATM-ĉelo.

Por la ekzemplo de IP super DSL-ligoj uzantaj PPPoA / VC-MUX, denove elektante plenigi 31 ATM-ĉelojn kiel antaŭe, ni akiras deziratan optimume reduktitan MTU-ciferon de 1478 = 31 * 48-10 konsiderante lumfolion de 10 bajtoj konsistantaj de Punkta-al-Punkta Protokolo supre de 2 bajtoj, kaj AAL5-supre de 8 bajtoj. Ĉi tio donas totalan koston de 31 * 53 = 1643 bajtoj elsenditaj per ATM de pakaĵeto de 1478 bajtoj transdonita al PPPoA. En la kazo de IP sendita per ADSL per PPPoA la cifero de 1478 estus la tuta longo de la IP-pakaĵo inkluzive de IP-titoloj. Do en ĉi tiu ekzemplo konservi memelektitan reduktitan MTU de 1478 kontraste al sendi IP-pakaĵojn de tuta longeco 1500 ŝparas 53 bajtojn por pakaĵo ĉe la ATM-tavolo je kosto de 22 bajtoj-redukto de la longo de IP-pakaĵoj.

Maksimuma MTU por PPPoE / DSL-ligoj estas 1492, per RFC 2516: 6 bajtoj estante PPPoE-titolo, lasante sufiĉan lokon por 1488-bajta utila ŝarĝo, aŭ 31 plenajn ATM-ĉelojn.

Fine: La norma valoro de MTU devas esti 1492 ... kaj en kazo de foliumaj problemoj aŭ problemoj pri konekteco de MSN ĝi estu malpliigita al la valoroj 1422 kaj 1420.

referenco: Vikipedio

Best regards