Առավելագույն փոխանցման միավոր (MTU)
Համակարգչային ցանցերում Maximum Transmission Unit (MTU) տերմինը վերաբերում է ամենամեծ PDU- ի չափին (բայթերով), որը հաղորդակցության արձանագրության տվյալ շերտը կարող է փոխանցել հետագայում: MTU- ի պարամետրերը սովորաբար հայտնվում են կապի միջերեսի (NIC, սերիական նավահանգիստ և այլն) հետ համատեղ: MTU- ն կարող է ամրագրվել ստանդարտներով (ինչպես Ethernet- ի դեպքում է) կամ որոշվել միացման ժամանակ (ինչպես սովորաբար լինում է կետից-կետ սերիական հղումների դեպքում): Ավելի բարձր MTU- ն բերում է ավելի մեծ արդյունավետություն, քանի որ յուրաքանչյուր փաթեթ կրում է ավելի շատ օգտվողի տվյալներ, մինչդեռ արձանագրության ծախսերը, օրինակ ՝ վերնագրերը կամ մեկ փաթեթի հիմքում ընկած ուշացումները մնում են հաստատուն, իսկ ավելի բարձր արդյունավետությունը նշանակում է զանգվածային արձանագրությունների թողունակության փոքր բարելավում: Այնուամենայնիվ, մեծ փաթեթները կարող են որոշ ժամանակ զբաղեցնել դանդաղ կապով ՝ առաջացնելով փաթեթների հետևման ավելի մեծ ուշացումներ և աճող հետաձգում և նվազագույն ուշացում: Օրինակ, 1500 բայթ փաթեթը, որը ամենամեծն է թույլատրվում Ethernet- ի կողմից ցանցի շերտում (և, հետևաբար, ինտերնետի մեծ մասը), կկապի 14.4k մոդեմը մոտ մեկ վայրկյան:
Athանապարհ MTU- ի հայտնաբերում
Ինտերնետային արձանագրությունը սահմանում է ինտերնետային փոխանցման ուղու «ուղին MTU» ՝ որպես աղբյուրի և նպատակակետի միջև ընկած «ճանապարհի» IP- ից ամենափոքր MTU- ն: Այլ կերպ ասած, ուղին MTU- ն ամենամեծ փաթեթի չափն է, որն անցնում է այս ճանապարհով ՝ առանց տառապելու մասնատման:
RFC 1191- ը նկարագրում է «Ուղու MTU- ի հայտնաբերումը» ՝ երկու IP հոսթերի միջև MTU ուղին որոշելու տեխնիկա: Այն աշխատում է ՝ ելքային փաթեթների IP վերնագրերում տեղադրելով DF (Մի՛ բեկորացրեք) տարբերակը: Deviceանապարհի երկայնքով, որի MTU- ն ավելի փոքր է, քան փաթեթը, կթողնի այդպիսի փաթեթները և հետ կուղարկի ICMP- ի «Անհասանելի նպատակակետ (տվյալների մեծ չափաբաժին)» հաղորդագրությունը, որը պարունակում է իր MTU- ն, ինչը թույլ կտա աղբյուրի սերվերին համապատասխան նվազեցնել MTU- ի իր ենթադրյալ ուղին: Գործընթացը կրկնվում է այնքան ժամանակ, քանի դեռ MTU- ն այնքան փոքր չէ, որ կարող է անցնել ամբողջ ճանապարհն առանց մասնատման:
Unfortunatelyավոք, ցանցերի աճող թիվը նվազեցնում է ICMP- ի երթևեկը (օրինակ ՝ ծառայությունից հրաժարվելու հարձակումները կանխելու համար), ինչը խոչընդոտում է MTU- ի հայտնագործման աշխատանքին: Հաճախ կարելի է հայտնաբերել նման արգելափակում այն դեպքերում, երբ կապը գործում է ցածր ծավալի տվյալների համար, բայց անջատվում է հենց որ հաղորդավարը միաժամանակ տվյալների մեծ բլոկ է ուղարկում: Օրինակ, IRC- ով միացնող հաճախորդը կարող է տեսնել մինչև պինգ հաղորդագրությունը, բայց դրանից հետո ոչ մի պատասխան չստանալ: Դա պայմանավորված է նրանով, որ ողջույնի ուղերձների մեծ փաթեթը ուղարկվում է իրական MTU- ից ավելի մեծ փաթեթներով: Բացի այդ, IP ցանցում աղբյուրի հասցեից դեպի նպատակակետ հասցե հաճախ փոխվում է դինամիկ կերպով ՝ ի պատասխան տարբեր իրադարձությունների (բեռի հավասարակշռում, գերբնակվածություն, ելքեր և այլն), ինչը կարող է հանգեցնել MTU- ի ուղու փոփոխության (երբեմն կրկնվում է) փոխանցման ընթացքում, որը կարող է առաջացնել փաթեթների հետագա անկումներ, մինչև տանտերը չգտնի նոր ապահով MTU- ն:
Ethernet LAN- ների մեծամասնությունը օգտագործում է 1500 բայթ MTU (ժամանակակից LAN- ները կարող են օգտագործել Jumbo- ի շրջանակներ ՝ թույլատրելով MTU մինչև 9000 բայթ), սակայն PPPoE- ի նման սահմանային արձանագրությունները դա կնվազեցնեն: Սա հանգեցնում է նրան, որ MTU- ի հայտնագործությունն ուժի մեջ է մտնում հնարավոր արդյունքով ՝ վատ կազմաձևված firewall- ների հետևում որոշ կայքեր անհասանելի դարձնելու համար: Կարելի է աշխատել դրա շուրջ ՝ կախված ցանցի որ հատվածից է վերահսկվում. օրինակ, կարելի է փոխել MSS- ը (հատվածի առավելագույն չափը) նախնական փաթեթում, որը ստեղծում է TCP կապը firewall- ում:
Այս խնդիրը ավելի հաճախ է ի հայտ եկել Windows Vista- ի ներդրումից ի վեր, որը ներկայացնում է «Հաջորդ սերնդի TCP/IP Stack»: Սա իրականացնում է «Ստացեք պատուհանի ավտոմատ կարգավորում, որն անընդհատ որոշում է ընդունման պատուհանի օպտիմալ չափը ՝ չափելով թողունակության հետաձգման արտադրանքը և հավելվածի առբերման արագությունը, և ճշգրտում է ընդունման պատուհանի առավելագույն չափը ՝ հիմնվելով ցանցի փոփոխվող պայմանների վրա» [2]: Ակնհայտ է, որ դա ձախողվում է հին երթուղիչների և firewall- ների հետ համատեղ, որոնք, կարծես, աշխատում էին այլ օպերացիոն համակարգերի հետ: Այն առավել հաճախ հանդիպում է ADSL երթուղիչներում և հաճախ կարող է ուղղվել որոնվածը թարմացնելով:
Բանկոմատների ողնաշարեր, MTU թյունինգի օրինակ
Երբեմն արդյունավետության տեսանկյունից նախընտրելի է ծրագրային ապահովման մեջ արհեստականորեն հայտարարել նվազեցված ՄՏՀ -ն `իրական հնարավոր առավելագույն երկարությունից ցածր: Դրա օրինակներից մեկն այն դեպքն է, երբ IP տրաֆիկն իրականացվում է բանկոմատի (Ասինխրոն փոխանցման ռեժիմ) ցանցով: Որոշ պրովայդերներ, մասնավորապես հեռախոսային ծառայություններ ունեցողները, իրենց ներքին ողնաշարային ցանցում օգտագործում են բանկոմատ:
Օպտիմալ արդյունավետությամբ բանկոմատի օգտագործումը ձեռք է բերվում, երբ փաթեթի երկարությունը 48 բայթ բազմապատիկ է: Դա պայմանավորված է նրանով, որ բանկոմատն ուղարկվում է որպես ֆիքսված երկարության փաթեթների հոսք (հայտնի է որպես «բջիջներ»), որոնցից յուրաքանչյուրը կարող է կրել 48 բայթ օգտվողի տվյալների բեռ ՝ 5 բայթ ընդհանուր արժեքով ՝ մեկ բջիջի համար 53 բայթ ընդհանուր արժեքով: Այսպիսով, փոխանցվող տվյալների երկարության ընդհանուր երկարությունը 53 * n բջիջ բայթ է, որտեղ ncells = = INT ((բեռնվածության_երկարություն+47)/48) անհրաժեշտ բջիջների թիվը: Այսպիսով, ամենավատ դեպքում, երբ ընդհանուր երկարությունը = (48*n+1) բայթ, անհրաժեշտ է մեկ լրացուցիչ բջիջ `վերջին բայթ բեռնվածությունը փոխանցելու համար, վերջնական բջիջը կարժենա լրացուցիչ 53 փոխանցված բայթ, որոնցից 47 -ը լցոնում են: Այդ իսկ պատճառով, ծրագրային ապահովման մեջ կրճատված MTU- ի արհեստականորեն հայտարարումը առավելագույնի է հասցնում արձանագրությունների արդյունավետությունը բանկոմատների շերտում `հնարավորության դեպքում դարձնելով բանկոմատի AAL5 ընդհանուր բեռնվածության երկարությունը 48 բայթ:
Օրինակ, 31 ամբողջությամբ լցված բանկոմատի բջիջ կրում է 31*48 = 1488 բայթ բեռնվածություն: Հաշվի առնելով 1488 -ի այս ցուցանիշը և դրանից հանելով բոլոր համապատասխան բարձրագույն արձանագրություններով կնքված ընդհանուր ծախսերը, մենք կարող ենք առաջարկվող արժեք ստանալ արհեստականորեն նվազեցված օպտիմալ կերպով ՄՏՀ -ի համար: Այն դեպքում, երբ օգտագործողը սովորաբար կուղարկեր 1500 բայթ փաթեթ, 1489 -ից 1536 բայթ ուղարկելու համար պահանջվում է փոխանցված 53 բայթ լրացուցիչ ֆիքսված արժեք ՝ մեկ լրացուցիչ բանկոմատի բջիջի տեսքով:
PPPoA/VC-MUX- ի միջոցով DSL միացումների IP- ի օրինակով ՝ կրկին ընտրելով 31 բանկոմատների բջիջների լրացում, ինչպես նախկինում, մենք ստանում ենք 1478 = 31*48-10 ցանկալի օպտիմալ նվազեցված MTU ցուցանիշ ՝ հաշվի առնելով 10 բայթերի ընդհանուր ծախսը: կետ առ կետ արձանագրություն `2 բայթից բարձր, և AAL5- ից` 8 բայթից: Սա տալիս է 31*53 = 1643 բայթ ընդհանուր արժեքը, որը փոխանցվում է բանկոմատով 1478 բայթ փաթեթից, որը փոխանցվում է PPPoA- ին: ADSL- ի միջոցով PPPoA- ի միջոցով ուղարկված IP- ի դեպքում 1478 թիվը կլինի IP փաթեթի ընդհանուր երկարությունը, ներառյալ IP վերնագրերը: Այսպիսով, այս օրինակում 1478-ի ինքնորոշված կրճատված MTU- ի պահպանումը, ի տարբերություն 1500-ի ընդհանուր IP փաթեթների ուղարկման, խնայում է 53 բայթ մեկ փաթեթի համար բանկոմատների շերտում `IP փաթեթների երկարության 22 բայթ կրճատմամբ:
PPPoE/DSL միացումների առավելագույն MTU- ն 1492 է, RFC- ի համար ՝ 2516: 6 բայթը PPPoE- ի վերնագիր է, թողնելով բավականաչափ տարածք 1488 բայթ բեռնվածության կամ 31 լրիվ բանկոմատի բջիջի համար:
Վերջապես ` MTU- ի ստանդարտ արժեքը պետք է լինի 1492 ... իսկ դիտման կամ MSN կապի խնդիրների դեպքում այն պետք է իջեցվի մինչև 1422 և 1420 արժեքների:
Հղում Վիքիփեդիա, ազատ հանրագիտարան
Best regards
Բարև, շնորհակալություն օգտակար հոդվածի համար