Անցման թեստ. արդյո՞ք հաստատված TCP հոսքը գոյատևում է։

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

Երկու արդյունք, որոնք նման են մեկ հաջողության

Պատկերացրեք 10.90.0.42 հասցեում գտնվող հաճախորդ, որն ունի միացում 198.51.100.20:443-ին։ Հիմնական ելքը դա թարգմանում է մեկ հանրային հասցեի և պորտի, իսկ պահուստային ելքը՝ մեկ այլի։ Հաճախորդի ներքին հասցեն երբեք չի փոխվում, և դրա համար էլ մարդիկ ակնկալում են, որ միացումը կգոյատևի։

Սերվերը ներքին հասցե չի տեսնում։ Այն տեսնում է թարգմանված վերջնակետը, և այդ կետը փոխարկումից հետո այլ է։

Այսպիսով հին հոսքը սպառվում է ժամկետով, մինչդեռ նույն ծառայությանը նոր միացումն աշխատում է անմիջապես։ Երկու դիտարկումներն էլ ճշմարիտ են միաժամանակ։

Ինչ է տեսնում սերվերը, երբ ելքը փոխվում է

TCP միացումը նույնականացվում է իր քառյակով, և աղբյուրի հասցեի կամ պորտի փոփոխությունը ստացող հոսթի համար ստեղծում է այլ միացում։ Նոր աղբյուրից այն միացման վրա եկող փաթեթները, որը սերվերը չի ճանաչում, դեն են նետվում կամ պատասխանվում են վերակայմամբ։ VPN հաճախորդի հասցեում ոչինչ չի պահպանում կապը այդ փոփոխության ընթացքում։

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

Ստուգեք՝ արդյոք զույգն իսկապես պահում է վիճակը, նախքան ինչ-որ մեկին շարունակականություն խոստանալը։ Ստորև բերված հրամանները ցույց են տալիս ընթացիկ վիճակը երկու կողմերում։

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Ինչու նույն հանրային հասցեն բավարար չէ

Երկու ուղիներում մեկ հանրային հասցե պահելը լավ սկիզբ է, որովհետև այդ ժամանակ սերվերը տեսնում է նույն աղբյուրի վերջնակետը։ Սակայն ինքնին դա բավարար չէ։ Փոխանցող սարքը դեռ պետք է թարգմանության վիճակ, ֆայրվոլի վիճակ և օգտագործելի վերադարձի ուղի, և դրանք պետք է գոյություն ունենան այն սարքում, որը փոխարկումից հետո կրում է երթևեկությունը։

RFC 3022-ը նկարագրում է հասցեների թարգմանությունը և թարգմանող սարքերի միջև վիճակի փոխանակումը դիտարկում որպես պահուստային ծրագրի մաս։ Լողացող հասցեն կամ պատճենված պրոֆիլը տեղափոխում է կոնֆիգուրացիան՝ չտեղափոխելով վիճակը։

Այդ պատճառով միայն պահուստի միջով ping անող թեստը շատ քիչ բան է ապացուցում։ Ping-ը կորցնելու միացման վիճակ չունի։

Որոշեք, թե որքան ուժեղ է պահանջը

Եթե օգտատերերը կարող են վերամիանալ խափանումից հետո, ապա նախագիծը վերականգնման նախագիծ է, և ընդունման թեստը նոր հարցում է։ Եթե ֆայլի փոխանցումը պետք է գոյատևի, նախագծին անհրաժեշտ է վիճակի համաժամեցում և շատ ավելի զգույշ թեստ։ Եթե հեռավոր սեսիան պետք է գոյատևի, պահանջը դեռ ավելի ուժեղ է և կարող է պահանջել հավելվածի մակարդակի մեխանիզմ՝ ցանցի մակարդակի փոխարեն։

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

Հստակ ասեք, թե ինչ է տեղի ունենում, երբ հիմնականն վերադառնում է, քանի որ ավտոմատ հետադարձը կարող է կտրել միացում, որը հենց նոր էր վերականգնվել պահուստի վրա։ Այդ դեպքը պատկանում է թեստային պլանին, ոչ թե ծանոթագրությանը։

Ստուգեք հին հոսքը և նոր հարցումը

Սկսեք անվնաս երկար փոխանցում հիմնական ուղով, ապա առանձին նոր հարցում նույն ծառայությանը։ Գրանցեք հավելվածի համատեքստը, դիտարկված ելքի հասցեն և ժամը։ Խախտեք հիմնականը հաստատված ձևով և շարունակեք դիտել սկզբնական փոխանցումը՝ նոր հարցումն ուղարկելով պահուստի միջով։

Հաղորդեք երեք արժեք՝ արդյոք հին հոսքը շարունակվեց, վերակայվեց կամ սպառվեց ժամկետով, երբ նոր գործողությունն առաջին անգամ աշխատեց, և արդյոք հետադարձը ինչ-որ բան կտրեց։ Այդ երեք տողերն են ընդունման արձանագրությունը։

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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