Uchafswm yr Uned Drosglwyddo (MTU)

Uchafswm yr Uned Drosglwyddo (MTU)

Mewn rhwydweithio cyfrifiadurol, mae'r term Uned Trosglwyddo Uchaf (MTU) yn cyfeirio at faint (mewn beitiau) y PDU mwyaf y gall haen benodol o brotocol cyfathrebu ei drosglwyddo. Mae paramedrau MTU fel arfer yn ymddangos mewn cysylltiad â rhyngwyneb cyfathrebu (NIC, porth cyfresol, ac ati). Gellir gosod yr MTU yn ôl safonau (fel sy'n wir am Ethernet) neu ei benderfynu ar amser cysylltu (fel sy'n digwydd fel arfer gyda chysylltiadau cyfresol pwynt i bwynt). Mae MTU uwch yn dod â mwy o effeithlonrwydd oherwydd bod pob pecyn yn cludo mwy o ddata defnyddwyr tra bod gorbenion protocol, megis penawdau neu oedi sylfaenol fesul pecyn yn aros yn sefydlog, ac mae effeithlonrwydd uwch yn golygu gwelliant bach mewn trwybwn protocol swmp. Fodd bynnag, gall pecynnau mawr feddiannu cyswllt araf am beth amser, gan achosi mwy o oedi wrth ddilyn pecynnau a chynyddu oedi ac isafswm hwyrni. Er enghraifft, byddai pecyn beit 1500, y mwyaf a ganiateir gan Ethernet yn haen y rhwydwaith (ac felly'r rhan fwyaf o'r Rhyngrwyd), yn clymu modem 14.4k am oddeutu un eiliad.

Darganfyddiad llwybr MTU
Mae'r Protocol Rhyngrwyd yn diffinio “llwybr MTU” llwybr trosglwyddo Rhyngrwyd fel y MTU lleiaf o unrhyw un o hopys IP y “llwybr” rhwng ffynhonnell a chyrchfan. Rhowch ffordd arall, y llwybr MTU yw'r maint pecyn mwyaf sy'n croesi'r llwybr hwn heb ddioddef darnio.

Mae RFC 1191 yn disgrifio “Path MTU Discover”, techneg ar gyfer pennu'r llwybr MTU rhwng dau westeiwr IP. Mae'n gweithio trwy osod yr opsiwn DF (Peidiwch â Darnio) ym mhenawdau IP pecynnau sy'n mynd allan. Bydd unrhyw ddyfais ar hyd y llwybr y mae ei MTU yn llai na'r pecyn yn gollwng pecynnau o'r fath ac yn anfon neges ICMP “Destination Unreachable (Datagram Too Big)” sy'n cynnwys ei MTU, gan ganiatáu i'r gwesteiwr ffynhonnell leihau ei MTU llwybr tybiedig yn briodol. Mae'r broses yn ailadrodd nes bod yr MTU yn ddigon bach i groesi'r llwybr cyfan heb ddarnio.

Yn anffodus, mae niferoedd cynyddol o rwydweithiau yn gollwng traffig ICMP (ee i atal ymosodiadau gwrthod gwasanaeth), sy'n atal darganfyddiad llwybr MTU rhag gweithio. Mae un yn aml yn canfod blocio o'r fath yn yr achosion lle mae cysylltiad yn gweithio ar gyfer data cyfaint isel ond yn hongian cyn gynted ag y bydd gwesteiwr yn anfon bloc mawr o ddata ar y tro. Er enghraifft, gydag IRC efallai y bydd cleient sy'n cysylltu yn gweld hyd at y neges ping, ond heb gael ymateb ar ôl hynny. Mae hyn oherwydd bod y set fawr o negeseuon croeso yn cael eu hanfon allan mewn pecynnau sy'n fwy na'r MTU go iawn. Hefyd, mewn rhwydwaith IP, mae'r llwybr o'r cyfeiriad ffynhonnell i'r cyfeiriad cyrchfan yn aml yn cael ei addasu'n ddeinamig, mewn ymateb i ddigwyddiadau amrywiol (cydbwyso llwyth, tagfeydd, allbynnau, ac ati) - gallai hyn arwain at newid MTU y llwybr (weithiau ailadrodd) yn ystod trosglwyddiad, a allai gyflwyno diferion pecyn pellach cyn i'r gwesteiwr ddod o hyd i'r MTU diogel newydd.

Mae'r rhan fwyaf o LAN Ethernet yn defnyddio MTU o 1500 beit (gall LANs modern ddefnyddio fframiau Jumbo, gan ganiatáu ar gyfer MTU hyd at 9000 beit), ond bydd protocolau ffiniau fel PPPoE yn lleihau hyn. Mae hyn yn achosi i ddarganfyddiad llwybr MTU ddod i rym gyda'r canlyniad posibl o wneud rhai safleoedd y tu ôl i waliau tân sydd wedi'u ffurfweddu'n wael yn anghyraeddadwy. Gall un weithio o amgylch hyn o bosibl, yn dibynnu ar ba ran o'r rhwydwaith y mae un yn ei rheoli; er enghraifft, gall un newid yr MSS (maint y segment uchaf) yn y pecyn cychwynnol sy'n sefydlu'r cysylltiad TCP wrth wal dân rhywun.

Mae'r broblem hon wedi dod i'r wyneb yn amlach ers cyflwyno Windows Vista sy'n cyflwyno 'Stack TCP / IP y Genhedlaeth Nesaf'. Mae hyn yn gweithredu “Derbyn Tiwnio Auto Ffenestr sy'n pennu maint y ffenestr derbyn gorau posibl yn barhaus trwy fesur y cynnyrch oedi lled band a chyfradd adfer y cais, ac yn addasu'r maint ffenestr derbyn uchaf yn seiliedig ar amodau rhwydwaith sy'n newid.” [2] Gwelwyd bod hyn yn methu ar y cyd â llwybryddion hŷn a waliau tân yr oedd yn ymddangos eu bod yn gweithio gyda systemau gweithredu eraill. Fe'i gwelir amlaf mewn llwybryddion ADSL ac yn aml gellir ei gywiro trwy ddiweddariad cadarnwedd.

Asgwrn cefn ATM, enghraifft o diwnio MTU
Weithiau mae'n well o safbwynt effeithlonrwydd datgan yn artiffisial MTU gostyngedig mewn meddalwedd sy'n is na'r gwir hyd mwyaf posibl a gefnogir. Un enghraifft o hyn yw'r achos lle mae traffig IP yn cael ei gario dros rwydwaith ATM (Modd Trosglwyddo Asyncronig). Mae rhai darparwyr, yn enwedig y rhai sydd â chefndir teleffoni, yn defnyddio peiriant ATM ar eu rhwydwaith asgwrn cefn mewnol.

Cyflawnir defnyddio ATM ar yr effeithlonrwydd gorau posibl pan fo hyd pecyn yn lluosrif o 48 beit. Mae hyn oherwydd bod ATM yn cael ei anfon fel llif o becynnau hyd sefydlog (a elwir yn 'gelloedd'), a gall pob un ohonynt gario llwyth tâl o 48 beit o ddata defnyddwyr gyda 5 beit o orbenion am gyfanswm cost o 53 beit y gell. Felly cyfanswm hyd y data a drosglwyddir yw 53 * beit ncells, lle mae ncells = nifer y celloedd gofynnol o = INT ((payload_length + 47) / 48). Felly yn yr achos gwaethaf, lle mae cyfanswm y hyd = (48 * n + 1) yn beitio, mae angen un gell ychwanegol i drosglwyddo'r un beit olaf o lwyth tâl, gyda'r gell olaf yn costio 53 beit ychwanegol a drosglwyddir 47 ohonynt yn padin. Am y rheswm hwn, mae datgan yn artiffisial MTU gostyngedig mewn meddalwedd yn cynyddu effeithlonrwydd protocol yn yr haen ATM trwy wneud i gyfanswm hyd llwyth tâl ATM AAL5 fod yn lluosrif o 48 beit pryd bynnag y bo hynny'n bosibl.

Er enghraifft, mae gan 31 o gelloedd ATM sydd wedi'u llenwi'n llwyr lwyth tâl o 31 * 48 = 1488 beit. Gan gymryd y ffigur hwn o 1488 a thynnu oddi wrtho unrhyw orbenion a gyfrannwyd gan yr holl brotocolau uwch perthnasol, gallwn gael gwerth a awgrymir ar gyfer MTU sydd wedi'i leihau'n artiffisial yn optimaidd. Yn yr achos lle byddai'r defnyddiwr fel arfer yn anfon 1500 o becynnau beit, mae anfon rhwng 1489 a 1536 beit yn gofyn am gost sefydlog ychwanegol o 53 beit a drosglwyddir, ar ffurf un gell ATM ychwanegol.

Er enghraifft, IP dros gysylltiadau DSL gan ddefnyddio PPPoA / VC-MUX, gan ddewis llenwi 31 o gelloedd ATM fel o'r blaen, rydym yn cael ffigur MTU dymunol wedi'i ostwng yn optimaidd o 1478 = 31 * 48-10 gan ystyried gorbenion o 10 beit sy'n cynnwys Protocol Pwynt i Bwynt uwchben 2 beit, ac uwchben AAL5 o 8 beit. Mae hyn yn rhoi cyfanswm cost o 31 * 53 = 1643 beit a drosglwyddir trwy beiriant ATM o becyn beit 1478 a basiwyd i PPPoA. Yn achos IP a anfonwyd dros ADSL gan ddefnyddio PPPoA, ffigur 1478 fyddai cyfanswm hyd y pecyn IP gan gynnwys penawdau IP. Felly yn yr enghraifft hon, mae cadw at MTU gostyngedig hunan-osodedig o 1478 yn hytrach nag anfon pecynnau IP o gyfanswm hyd 1500 yn arbed 53 beit y pecyn ar yr haen ATM ar gost o ostyngiad 22 beit o hyd pecynnau IP.

Uchafswm MTU ar gyfer cysylltiadau PPPoE / DSL yw 1492, fesul RFC 2516: 6 beit yw pennawd PPPoE, gan adael digon o le ar gyfer llwyth tâl beit 1488, neu 31 o gelloedd ATM llawn.

Yn olaf: Gwerth safonol MTU yw 1492 .... ac mewn achos o broblemau pori neu broblemau cysylltedd MSN dylid ei ostwng i'r gwerthoedd 1422 a 1420.

Cyfeirnod: Wicipedia

Cofion gorau