Максимална единица за пренос (MTU)

Максимална единица за пренос (MTU)

Во компјутерското вмрежување, терминот Максимална единица за пренос (MTU) се однесува на големината (во бајти) на најголемиот PDU што даден слој од комуникацискиот протокол може да го помине понатаму. MTU параметрите обично се појавуваат во асоцијација со комуникациски интерфејс (NIC, сериска порта, итн.). MTU може да биде фиксиран според стандарди (како што е случајот со Ethernet) или да се одлучи во времето на поврзување (како што е обично случајот со сериските врски од точка до точка). Повисокиот MTU носи поголема ефикасност затоа што секој пакет носи повеќе кориснички податоци додека горните трошоци на протоколот, како што се заглавијата или основните доцнења по пакет остануваат фиксни, а повисоката ефикасност значи мало подобрување на протокот на протоколот на големо. Сепак, големите пакети можат да заземаат бавна врска некое време, предизвикувајќи поголеми доцнења во следењето на пакетите и зголемување на доцнењето и минималната латентност. На пример, пакет од 1500 бајти, најголемиот дозволен од Ethernet на мрежниот слој (а со тоа и најголемиот дел од Интернетот), би го врзувал модемот од 14.4 k за околу една секунда.

Откривање на патеката MTU
Интернет протоколот ја дефинира „патеката MTU“ на патеката за пренос на Интернет како најмалиот MTU од кој било од IP-прескокнувањата на „патот“ помеѓу изворот и дестинацијата. На друг начин, патеката MTU е најголемата големина на пакетот што ја поминува оваа патека без да претрпи фрагментација.

RFC 1191 го опишува „Откривањето на патеката MTU“, техника за одредување на патеката MTU помеѓу два IP домаќини. Работи со поставување на опцијата DF (Don't Fragment) во IP заглавијата на појдовните пакети. Секој уред долж патеката чиј MTU е помал од пакетот ќе ги исфрли таквите пакети и ќе испрати ICMP порака „Дестинацијата недостижна (Премногу голем податок)“ која го содржи својот MTU, дозволувајќи му на изворниот домаќин соодветно да ја намали својата претпоставена патека MTU. Процесот се повторува додека MTU не биде доволно мал за да ја помине целата патека без фрагментација.

Можеби ќе ве интересира да видите: 2 Конфигурација на рутер WIRE

За жал, зголемениот број мрежи го намалуваат сообраќајот на ICMP (на пр. за да се спречат напади на одбивање на услугата), што спречува откривањето на патеката MTU да работи. Човек често открива такво блокирање во случаите кога врската работи за податоци со мал волумен, но виси штом домаќинот испраќа голем блок од податоци во исто време. На пример, со IRC, клиентот за поврзување може да ја види пораката за пинг, но после тоа нема да добие одговор. Тоа е затоа што големиот сет на пораки за добредојде се испраќаат во пакети поголеми од вистинскиот MTU. Исто така, во IP мрежата, патеката од изворната адреса до адресата одредиште често се менува динамично, како одговор на различни настани (балансирање на оптоварување, застој, излези, итн.) - ова може да резултира со промена на патеката MTU (понекогаш се повторува) за време на пренос, што може да воведе дополнителни падови на пакети пред домаќинот да го најде новиот безбеден MTU.

Повеќето етернет LAN користат MTU од 1500 бајти (модерните LAN може да користат Jumbo рамки, овозможувајќи MTU до 9000 бајти), но граничните протоколи како PPPoE ќе го намалат ова. Ова предизвикува откривањето на патеката MTU да стапи на сила со можен резултат да направи некои локации зад лошо конфигурираните заштитни ѕидови недостапни. Може да се работи околу ова, во зависност од тоа кој дел од мрежата го контролира; на пример, може да се смени MSS (максимална големина на сегментот) во почетниот пакет што ја поставува TCP конекцијата на заштитниот ѕид.

Овој проблем се појавува почесто од воведувањето на Windows Vista кој го воведува „Следната генерација TCP/IP Stack“. Ова го имплементира „Автоматско подесување на прозорецот за примање што постојано ја одредува оптималната големина на прозорецот за примање со мерење на производот за доцнење на пропусниот опсег и стапката на враќање на апликацијата, и ја прилагодува максималната големина на прозорецот за примање врз основа на променливите услови на мрежата“.[2] Се гледа дека ова не успева во врска со постарите рутери и заштитни ѕидови кои се чини дека работат со други оперативни системи. Најчесто се гледа во ADSL рутерите и често може да се коригира со ажурирање на фирмверот.

Можеби ќе ве интересира да видите: Лекови земени во изолирани болници

АТМ столбови, пример за подесување на MTU
Понекогаш се претпочита од гледна точка на ефикасност вештачки да се прогласи намалена MTU во софтвер под вистинската максимална можна должина поддржана. Еден пример за ова е случајот кога IP сообраќајот се пренесува преку мрежа на ATM (Asynchronous Transfer Mode). Некои провајдери, особено оние со телефонско потекло, користат банкомат на нивната внатрешна основна мрежа.

Користењето на банкомат со оптимална ефикасност се постигнува кога должината на пакетот е повеќекратна од 48 бајти. Тоа е затоа што банкоматот се испраќа како проток на пакети со фиксна должина (познати како „ќелии“), од кои секоја може да носи товар од 48 бајти кориснички податоци со 5 бајти надземни трошоци за вкупна цена од 53 бајти по ќелија. Значи, вкупната должина на должината на пренесените податоци е 53 * ncells бајти, каде што ncells = бројот на потребни ќелии од = INT((payload_length+47)/48). Така, во најлош случај, каде што вкупната должина = (48*n+1) бајти, потребна е една дополнителна ќелија за да се пренесе последниот бајт на носивост, а последната ќелија чини дополнителни 53 пренесени бајти, од кои 47 се пополнети. Поради оваа причина, вештачкото декларирање на намален MTU во софтверот ја максимизира ефикасноста на протоколот на слојот на ATM со тоа што вкупната должина на товарот на ATM AAL5 ќе биде повеќекратна од 48 бајти секогаш кога е можно.

На пример, 31 целосно пополнети банкомати носат товар од 31*48=1488 бајти. Земајќи ја оваа бројка од 1488 и одземајќи од неа сите општи трошоци придонесени од сите релевантни повисоки протоколи, можеме да добиеме предложена вредност за вештачки намалена оптимално MTU. Во случај кога корисникот вообичаено би испратил пакети од 1500 бајти, испраќањето помеѓу 1489 и 1536 бајти бара дополнителен фиксен трошок од 53 пренесени бајти, во форма на една дополнителна ќелија на банкомат.

Можеби ќе ве интересира да видите: Како да додадете MTU во zxhn h108n

На примерот на IP преку DSL конекции користејќи PPPoA/VC-MUX, повторно избирајќи да пополните 31 ATM ќелии како порано, ја добиваме посакуваната оптимално намалена бројка MTU од 1478 = 31*48-10 земајќи го предвид надземниот товар од 10 бајти што се состои на протокол од точка-до-точка над глава од 2 бајти и надземен AAL5 од 8 бајти. Ова дава вкупен трошок од 31*53=1643 бајти пренесени преку банкомат од 1478 бајти пакет предаден на PPPoA. Во случај на IP испратена преку АДСЛ користејќи PPPoA, бројката од 1478 би била вкупната должина на IP пакетот вклучувајќи ги IP заглавијата. Така, во овој пример, задржувањето на самонаметната намалена MTU од 1478, наспроти испраќањето на IP пакети со вкупна должина од 1500, заштедува 53 бајти по пакет во слојот на ATM по цена од 22 бајти намалување на должината на IP пакетите.

Максималниот MTU за PPPoE/DSL конекции е 1492, по RFC 2516: 6 бајти се заглавие PPPoE, што остава доволно простор за товар од 1488 бајти или 31 полни ATM ќелии.

Конечно: Стандардната вредност на MTU треба да биде 1492.... а во случај на проблеми со прелистувањето или проблеми со поврзувањето на MSN треба да се намали на вредностите 1422 и 1420.

Суд: Википедија

Со почит