Մեծ ներբեռնումներն ընդդեմ VPN-ի. ընտրեք ուղին հարցման պահին

«Մեծ ներբեռնումները ուղարկիր VPN-ի շուրջ, իսկ փոքր պատասխանները թող դրա վրա» հնչում է որպես երթուղավորման քաղաքականություն, բայց այդպիսին չէ: Երթուղիչը որոշում է այդ պահին հասանելի տեղեկությունով՝ հասցեներ, պորտեր, արձանագրություն, firewall-ի նշաններ, հայտնաբերված հոսք: Պատասխանի վերջնական չափը այդ բազմության մեջ չէ, որովհետև այն դեռ չի հասել, և երբ երթուղիչը կկարողանար չափել բայթերը, նա արդեն դրանք տեղափոխում է: Եթե ուզում եք ղեկավարել ըստ առաջադրանքի, որոշումը պետք է տեղափոխվի մի կետ, որը գիտի առաջադրանքը, և ներքևի ստուգաթերթը ցույց է տալիս՝ արդյոք ձեր նախագծում կա այդպիսի կետ:

Ինչու երթուղիչը չի կարող չափել պատասխանը

Այն պահին, երբ փաթեթին ուղի է պետք, երթուղիչը տեսել է հոսքի առավելագույնը առաջին մի քանի փաթեթները: Նա կարող է ասել, թե ով ում հետ է խոսում, ինչ արձանագրությամբ, ինչ նշանով, և քանի բայթ է անցել մինչև հիմա: Մինչև հիմա անցած բայթերը նկարագրում են անցյալը: Պատասխանի չափը դեռ չստեղծված պատասխանի հատկություն է, և բաժանված կամ հոսքային պատասխանների դեպքում այն գուցե երբեք նախապես հայտնի չլինի:

Նույնիսկ արձանագրության սեփական մետատվյալները ավելի թույլ են, քան թվում են: HTTP-ն թույլ է տալիս պատասխաններ, որոնց երկարությունը չի հայտարարվում մարմնից առաջ, և մեկ օգտվողի գործողությունը կարող է ստեղծել բազմաթիվ հարցումներ, որոնց համակցված արժեքը նման չէ ոչ մի վերնագրի արժեքի: Վերնագիրը առաջադրանքի չափ համարելը մոդելավորման սխալ է՝ նախքան երթուղավորման սխալ լինելը:

Ստուգում 1. կա՞ որոշման կետ, որը կարող է ուղի ընտրել

Նշեք այն բաղադրիչը, որը կկատարի ընտրությունը, ապա նշեք, թե ինչ գիտի նա ընտրության պահին: Թարմացնողը, որը ներբեռնում է փաստաթղթավորված հոսթերի հավաքածուից, գիտի իր նպատակը մինչև փոխանցման սկսվելը: Ներբեռնման ծառայությունը, որը դիտում է մետատվյալները և հետո բացում հարցումը, գիտի առաջադրանքը մինչև կապի գոյությունը: Համագործակցող proxy-ն կարող է կիրառել հարցման մակարդակի քաղաքականություն կամ պահել պատասխանը քեշում՝ առանց ձևանալու, թե երթուղիչ է:

Եթե պատասխանը «դարպասն» է, ստուգաթերթը արդեն ձախողվել է: Դարպասը կարող է դասակարգել հայտնի հոսքերը ըստ նշանակակետի, նշանի կամ հաճախորդի հատվածի և ուղարկել դրանք սահմանված ուղիով առաջին փաթեթից, ինչը հաճախ բավական է հաստատված թարմացնողի համար և երբեք բավական չէ անհայտ պատասխանի չափի համար:

Ստուգում 2. ի՞նչ են իրականում ասում մետատվյալները

Հավելվածագիտակից ղեկավարումն այնքան լավ է, որքան լավ են այն դաշտերը, որոնք նա կարդում է: HTTP-ի իմաստաբանությունը-ի պատասխանի երկարության կանոնները թույլ են տալիս դեպքեր, երբ երկարությունը սկզբում հասանելի չէ, և բովանդակության կոդավորումները միևնույն է փոխանցված բայթերի քանակը տարբեր են դարձնում ներկայացման չափից: Ուստի վերնագրի շեմը հատելիս ուղին փոխող քաղաքականությունը կվարվի անհետևողական, և հիմնականում հենց այն մեծ փոխանցումների վրա, որոնք պետք է բռներ:

Այն, ինչին հավելվածի մետատվյալները կարող են աջակցել, առաջադրանքի մասին որոշումն է. այս աշխատահոսքը զանգվածային համաժամեցում է, այս մեկը՝ ինտերակտիվ, այս մեկը՝ ծրագրային թարմացում հայտնի աղբյուրից: Դա մտադրության լեզվով գրված քաղաքականություն է, և բավականաչափ կայուն է փորձարկելու համար: «Այս պատասխանը կլինի քառասուն մեգաբայթից մեծ» այդպիսի քաղաքականություն չէ:

Ստուգում 3. հոսքը արդեն գոյություն ունի՞

Երթուղավորումը կարող է փոխվել հոսքի համար՝ առանց կապի ինքնությունը փոխելու, և այդ տարբերությունն արժե հստակ պահել: TCP կապը նույնականացվում է իր ծայրակետերի հասցեներով և պորտերով, և փաթեթները կարող են այլ ուղի վերցնել, եթե երթուղային աղյուսակը փոխվի դրանց տակ: Այն, ինչ չի կարող փոխվել անտեսանելիորեն, ցանցային հասցեների թարգմանության վիճակն է. երթևեկությունը այլ ելք տեղափոխելը սովորաբար փոխում է հանրային աղբյուրի բազմակը, և հեռավոր կողմը կտեսնի այլ գործընկեր՝ առանց համապատասխան վիճակի:

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Այսպիսով գործնական կանոնն այն է, որ կապի կեսին մի ելքից մյուսը տեղափոխելը նոր հարաբերություն է, ոչ միգրացիա: Եթե նախագիծը պահանջում է, որ նույն կապը շարունակվի, որոշումը պետք է կայացվեր առաջին SYN-ից առաջ, և հետո ավելացված ոչ մի փաթեթի կանոն չի կարող այն մաքուր վերակառուցել:

Ստուգում 4. իսկական պահանջը ուշացո՞ւմն է, ոչ թե ելքը

Շատ հարցումներ «զանգվածային երթևեկությունը ուղարկիր այլ տեղ» իրականում բողոք են, որ մեծ փոխանցումը ինտերակտիվ աշխատանքը դանդաղ է զգացնում: Դա ժամանակացույցի խնդիր է, և ունի ժամանակացույցի պատասխան. արդար հերթը կամ եղած ուղու վրա աջակցվող թողունակության քաղաքականությունը թույլ չեն տալիս զանգվածային հոսքին սովամահ անել չաթի հաղորդագրությունը՝ առանց երկուսից որևէ մեկը տեղափոխելու:

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Ախտանիշին այսպես մոտենալը թողնում է ելքի որոշումը այնտեղ, որտեղ դրել է անվտանգության քաղաքականությունը, և այն շրջելի է մեկ հրամանով: Ամբողջ երթևեկության դասի համար ելքը փոխելը քաղաքականության փոփոխություն է՝ նույնականացման, մատյանագրման և մուտքի կանոնների հետևանքներով, ուստի այն չպետք է լինի առաջին գործիքը ուշացման բողոքի դեպքում:

Եթե պահանջը իսկապես այլ ինտերնետ ելք է, ասեք դա հենց այդ բառերով և իրականացրեք աջակցվող սահմանում. նոր կապ հաստատված աշխատահոսքից, կամ հավելված, որը բացում է իր հարցումը ընտրված ելքով: Այնուհետև գրանցեք, թե որ առաջադրանքներն են օգտագործում որ ելքը, որպեսզի հաջորդ մարդը ստիպված չլինի դա եզրակացնել երթուղային աղյուսակից:

Պահեք ստուգաթերթը փոփոխության գրառման մեջ. որոշման կետը, այն ղեկավարող դաշտը կամ առաջադրանքը, արդյոք հոսքը արդեն գոյություն ունի, և արդյոք չափված ախտանիշը ուշացում էր, թե ելք: Չորս հարց, և քաղաքականությունը, որը պատասխանում է բոլոր չորսին, այն է, որը կարող եք շահագործել, ոչ թե պաշտպանել: