VPN-ը խափանվեց էջի կեսին. արդյո՞ք ֆոնային հարցումները դեռ դուրս են գալիս։

Ներդիրը դեռ ցուցադրում է վահանակը այն պահից, երբ թունելը դեռ չէր մահացել։ Կարգավիճակի թվերը սառչում են, փոքրիկ պտտիչը շարունակում է պտտվել, և հասցեի տողը դեռ կրում է այն հավելվածը, որը բացել եք մեկ ժամ առաջ։ Ընդհատումից հետո ոչնչի չեք դիպչել, սակայն էջը կարող է դեռ փորձել հասնել իր սերվերին իր սեփական ժամանակացույցով։ Հենց դա են մարդիկ բաց թողնում. էջը, որ միայն տեսանելի է, և էջը, որ դեռ հարցումներ է ուղարկում, դրսից նույնն են երևում, և նրանցից միայն մեկն է հայտնվում ցանցի մատյանում։

Աշխատանք, որ էջը սկսում է առանց ձեզ

Չորս մեխանիզմ բեռնված փաստաթուղթը զբաղված են պահում։ Կրկնվող ժամաչափը կարող է ամեն մի քանի վայրկյանում նորից գործարկել կարգավիճակի կանչը։ Fetch-ը կարող է գործարկվել, երբ ներդիրը նորից տեսանելի է դառնում ձեր վերադառնալուց հետո։ WebSocket-ի կամ սերվերի ուղարկած իրադարձությունների վրա կառուցված կենդանի ալիքը կարող է փորձել վերամիանալ իր հետընթացի ժամանակացույցով։ Կայքի գրանցած service worker-ը կարող է արթնանալ հերթում դրված համաժամեցման համար նույնիսկ այն դեպքում, երբ ձեր առջև ներդիր չկա։

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

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

Ինչու էջի նախորդ բեռնումը երթուղի չի պահում

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

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

Ուր է իջնում ձախողման քաղաքականությունը

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

Երկու մանրամասնություն է որոշում, թե որն եք ստանում։ Առաջինը այն կիրառման շրջանակն է, որը հաճախորդը աջակցում է. ամբողջ սարքի արգելափակում, թունելի ադապտերով սահմանափակված արգելափակում կամ բացառություններով կանոնների հավաքածու։ Երկրորդը, թե արդյոք նպատակակետը ընկնում է ավելի վաղ ավելացված բացառության մեջ տեղական տպիչի, captive portal-ի կամ հոսքային ծառայության համար։

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

Վերահսկվող ստուգում մեկանգամյա էջով

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

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

Զննարկիչում Ցանց վահանակը բաժանում է երկու հարցերը։ Զտեք Fetch/XHR-ով, ապա կարդացեք նախաձեռնողի սյունակը. գրառում, որը սկսել է ժամաչափը կամ սկրիպտը, առանց դրանից առաջ գրանցված նավարկության, ֆոնային փորձ է, այլ ոչ թե վերբեռնում։ Համեմատեք դրա մեկնարկի ժամանակը այն պահի հետ, երբ թունելը խափանվեց։ Եթե գրառումը դեռ սպասման մեջ է, երբ թունելն արդեն չկա, հարցումը սպասում է ուղու, որն այլևս գոյություն չունի։

Սերվերի կողմի ապացույցներն ավելի ուժեղ են, քան այն ամենը, ինչ ցույց է տալիս զննարկիչը։ Ժամանակի դրոշմով և աղբյուրի հասցեով հարցումների մատյանը ապացուցում է, որ փաթեթը հասել է։ Զննարկիչի գրառումները կարող են կրել քուքիներ, թոքեններ և ամբողջական URL-ներ, ուստի պահեք միայն այն դաշտերը, որոնք ձեր հարցին պետք են, և թաքցրեք մնացածը նախքան դրանք որևէ տեղ տեղադրելը։

Ինչ անել պատասխանի հետ

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

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