Արդյո՞ք ավելի փոքր VPN MTU-ն ավելի արագ է։ Համեմատեք իրական ապացույցները
Ավելի ցածր MTU-ն կարող է շրջանցել ուղու սահմանը և միևնույն ժամանակ արժենալ թողունակություն։ Համեմատեք իրական սահմանափակումը, վերնագրերի ծախսը և աշխատանքային բեռը նախքան փոփոխությունը պահելը։
Թունելը գցում է մեծ փոխանցումները, բայց բաց է թողնում ping-ը, ուստի խորհուրդը արագ է գալիս՝ իջեցրեք MTU-ն։ Ուղղումը երբեմն աշխատում է, և հետո այն կիրառվում է յուրաքանչյուր պրոֆիլի վրա յուրաքանչյուր ցանցում։ Հենց այդ պահին նպատակային վերանորոգումը դառնում է մշտական հարկ կատարողականության վրա։ Համեմատությունը, որը պետք է անել, ուղու իրական սահմանի և դրա տակ յուրաքանչյուր փաթեթը փոքրացնելու ծախսի միջև է։
Ի՞նչն է իսկապես փոքրանում, երբ իջեցնում եք MTU-ն
Յուրաքանչյուր փաթեթ վերնագրեր է կրում նախքան ձեր տվյալները կրելը։ 1500 բայթանոց Ethernet ուղու վրա IPv4-ը և TCP-ն սպառում են 40 բայթ և թողնում 1460 օգտակար բեռի համար. ինկապսուլացիան վերևում ավելացնում է արտաքին IP, UDP և թունելի վերնագրեր, ուստի ներքին բեռի բյուջեն կրկին իջնում է։ Ինտերֆեյսի MTU-ի իջեցումը դիտավորյալ փոքրացնում է այդ բյուջեն։
Ծախսը համեմատական է փաթեթների թվին, ոչ բայթերի թվին։ Նույն ֆայլը ավելի շատ փաթեթների բաժանված՝ պահանջում է ավելի շատ ընդհատումներ, ավելի շատ երթուղային որոշումներ և ավելի շատ մշակում յուրաքանչյուր փաթեթի համար ուղու յուրաքանչյուր սարքում։ Այն երթուղիչում, որն արդեն մոտ է վայրկյանում փաթեթների իր սահմանին, դա իրական դանդաղում է, ոչ թե կլորացման սխալ։ Ծախսը երևում է նույնիսկ այն ժամանակ, երբ ինքը փոխանցումը հաջողվում է։
Ահա թե ինչու ավելի փոքր MTU-ն սահմանափակման շրջանցում է, ոչ թե ընդհանուր օպտիմացում։ Այն հուսալիություն է գնում ավելի մեծ շրջանակ չկրող ուղու դիմաց և լրացուցիչ ծախս է գանձում յուրաքանչյուր փաթեթից, որը փոքրացման կարիք չուներ։
Երբ ավելի փոքր MTU-ն ճիշտ ուղղումն է
Դասական ախտանիշը կոնկրետ է. TCP ձեռքսեղմումը ավարտվում է, փոքր պատասխաններ են գալիս, և մեծ ներբեռնումը կանգ է առնում կամ վերակայվում։ 1472 բայթի վրա «մի՛ մասնատիր» բիթով ping-ը ձախողվում է, մինչդեռ 1400 բայթանոց ping-ը հաջողվում է, ինչը ցույց է տալիս ուղի, որը չի կարող կրել ամբողջական չափի փաթեթ և չի հասցնում այն ICMP հաղորդագրությունը, որը կասեր ուղարկողին փոքրացնել։
Ուղու MTU-ի հայտնաբերումը կախված է այդ ICMP մասնատման-անհրաժեշտության հաղորդագրություններից։ Երբ հրապատն արգելափակում է դրանք, ուղարկողը շարունակաբար կրկնում է մեծ փաթեթը, և կապը կարծես կախված է։ Թունելի կողմում MTU-ի իջեցումը խուսափում է կրկնությունից, և դա օրինական վերանորոգում է այդ ցանցի համար։
Մուտքի տեխնոլոգիաները նույնպես դնում են իրենց սահմանները. PPPoE-ն սովորաբար սահմանափակվում է 1492-ով, որոշ բջջային և DSL ուղիներ ավելի ցածր են, իսկ ներդրված թունելները լրացուցիչ ծախսը հանում են երկու անգամ։ Չափեք իրական ուղին՝ ուղեցույցից թիվ արտագրելու փոխարեն, և հիշեք, որ IPv6-ը պահանջում է առնվազն 1280 բայթ MTU այն կրող յուրաքանչյուր կապում, ինչպես սահմանում է RFC 8200-ը։
Համեմատեք երեք կարգավորիչները նախքան մեկը փոխելը
MTU-ն, MSS-ը և մասնատումը տարբեր շերտերի տարբեր կարգավորիչներ են, և սխալը փոխելը ախտանիշը թողնում է տեղում։
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS-ի սահմանափակումը հաճախ ամենաքիչ ներխուժող վերանորոգումն է, որովհետև ազդում է միայն TCP-ի վրա և ինտերֆեյսը ազատ է թողնում այլ երթևեկության համար։ Ավելի ցածր ինտերֆեյսային MTU-ն ավելի լայն է և ավելի հեշտ դատելի, դրա համար էլ տարածված է սպառողական երթուղիչներում, բայց մեկ արձանագրության խնդրի վճարը գանձում է բոլոր արձանագրություններից։
«Մի՛ մասնատիր» վարքագծի անջատումը թաքցնում է ախտանիշը՝ թույլ տալով մասնատում, և սովորաբար վատթարացնում է ուշացումը՝ միաժամանակ կոտրելով հետադարձ կապը, որը կգտներ ճիշտ չափը։ Խուսափեք դրանից որպես մշտական լուծում։
Չափեք փոխզիջումը, ոչ թե մեկ թիվ
Գտեք ուղու սահմանը «մի՛ մասնատիր» զոնդով, սկսեք բարձրից և իջեք, մինչև պատասխանը գա՝
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Այնուհետև համեմատեք իրական առաջադրանքը երկու կարգաբերումներում. նույն ֆայլի փոխանցումը, նույն վերջնակետը և նույն ցանցը։ Գրանցեք ավարտի ժամանակը և կրկնափոխանցումները, օրինակ nstat -az TcpRetransSegs-ով, և հետևեք սարքի պրոցեսորին, եթե թունելը ավարտվում է փոքր երթուղիչում։ Կարճ սինթետիկ թողունակության թեստը կարող է բաց թողնել այն կանգառը, որն ի հայտ է գալիս միայն մի քանի մեգաբայթից հետո։
Փաթեթների հաշվիչները կբարձրանան իջեցումից հետո, քանի որ նույն փոխանցումն այժմ ավելի շատ փաթեթ է օգտագործում։ Դա սպասելի է և ավելի բարձր թողունակության ապացույց չէ։ Համեմատեք ավարտված հավելվածային տվյալները, կրկնափոխանցումների թիվը և արձագանքունակությունը, ոչ միայն փաթեթների արագությունը։
Ներմուծեք փոփոխությունը փուլերով և պահեք այն սահմանափակ
Գրանցեք սկզբնական արժեքը, փոխեք մեկ կարգավորիչ և կրկնեք չափումը նախքան այն մշտական դարձնելը։ Եթե ապացույցները օգուտ չեն ցույց տալիս, վերականգնեք նախորդ արժեքը նույն ինտերֆեյսի հրամանով, որով այն սահմանել էիք՝
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Սահմանափակեք արդյունքը այն ցանցով, որն իրեն պետք էր։ Պրոֆիլը, որը պետք է աշխատի հյուրանոցի Wi-Fi-ում, բջջային հոթսփոթում և գրասենյակի LAN-ում, չպետք է ժառանգի նրանցից որևէ մեկի պահանջած ամենացածր արժեքը, եթե միայն հաճախորդը չի կարող հայտնաբերել ուղին։
Ճիշտ արժեքը ամենամեծ MTU-ն է, որը վերապրում է ուղին, ոչ թե ամենափոքրը, որը վերացնում է ախտանիշը։ Փաստաթղթավորեք ուղին, զոնդի արդյունքը և հետադարձը, և վերանայեք կարգավորումը, երբ մուտքի ցանցը փոխվի։