Տաք HTTPS ընդդեմ տաք VPN-ի. համեմատեք նույն հարցման ուղին

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

Ինչ է իրականում պահանջում կրկին օգտագործումը

Կայունությունը HTTP մոդելի մասն է, ոչ հնարք. մեկ կապը կրում է հարցում-պատասխան մի քանի փոխանակում։ Կապն ավարտվում է, երբ կողմերից մեկը փակում է այն, երբ սերվերը հանում է անգործ կամ գերբեռնված կապը, կամ երբ վերնագիրը կամ արձանագրության կանոնը ասում է, որ կապը հնարավոր չէ կրկին օգտագործել։ HTTPS-ն այդ խոսակցությունը դնում է TLS-ի ներսում՝ առանց յուրաքանչյուր փոխանակման համար նոր ձեռքսեղմում պահանջելու։ Այսպիսով երկրորդ հարցումը չի կրկնում առաջին հարցման ձեռքսեղմումը, եթե ինչ-որ բան միջանկյալ չի ավարտել կապը։

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

Ստուգեք գրադարանի աջակցվող հաճախորդը և կապերի լողավազանի կյանքի ցիկլը՝ փոխարենը չենթադրելով, որ լողավազանը միացված է կամ անջատված։ Գրանցեք նաև պայմանավորված HTTP տարբերակը, որովհետև HTTP/2-ը և HTTP/3-ը կապերի կրկին օգտագործումը վարում են այլ կերպ, քան HTTP/1.1-ը։ Պայմանավորված տարբերակը համարեք չափման մաս, ոչ թե ստորագրություն։

Ինչու է համեմատությունը չափում կյանքի ցիկլը

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

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

Առանձնացրեք սառը հաստատումը տաք հարցումներից

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

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

Նախապես պատրաստվեք փակվող կապին

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

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

Նախ ընտրեք սահմանը, ապա կարգավորեք

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

RFC 9112-ի կայունության բաժինը այն հղումն է, թե կրկին օգտագործումն իրականում ինչ է խոստանում, ներառյալ կապը ավարտող պայմանները։ Կարդացեք այն մեկ անգամ, նախքան վստահել այնպիսի չափման, որը անտեսում է դրանք։