HTTPS i ngrohtë kundrejt një VPN të ngrohtë: krahasoni të njëjtën rrugë kërkese

Me siguri keni lexuar se HTTPS hap një lidhje të re TCP dhe një handshake të re TLS për çdo kërkesë API, kështu që një tunel që qëndron hapur një orë duket më i lirë. Gjysma e parë e kësaj është zakonisht e rreme. Një klient i mbështetur ripërdor një lidhje të vendosur për shumë shkëmbime, dhe një matje që ndërton një klient të re për çdo thirrje mat ciklin e jetës dhe jo mbrojtjen. Pjesa tjetër e kësaj faqe flet për çfarë të matni në vend të kësaj.

Çfarë kërkon vërtet ripërdorimi

Qëndrueshmëria është pjesë e modelit HTTP dhe jo një truk: një lidhje mbart disa shkëmbime kërkese dhe përgjigjeje. Lidhja përfundon kur njëra nga palët e mbyll, kur serveri tërheq një lidhje joaktive ose të mbingarkuar, ose kur një titull ose rregull protokolli thotë se lidhja nuk mund të ripërdoret. HTTPS e vendos atë bisedë brenda TLS pa kërkuar një handshake të re për çdo shkëmbim. Pra, një kërkesë e dytë nuk përsërit handshake-in e kërkesës së parë, përveç nëse diçka e përfundoi lidhjen në mes.

Ripërdorimi ka gjithashtu një kusht që aplikacionet e thyejnë lehtë. Një klient që planifikon të ripërdorë një lidhje duhet të lexojë trupin e plotë të përgjigjes, dhe një përgjigje e braktisur në gjysmë është mënyra e zakonshme se si një grup lidhjesh zhduket pa e vënë re askush.

Kontrolloni klientin e mbështetur të bibliotekës dhe ciklin e jetës së grupit të lidhjeve, në vend që të supozoni se grupimi është i ndezur ose i fikur. Shënoni edhe versionin HTTP të negociuar, sepse HTTP/2 dhe HTTP/3 e trajtojnë ripërdorimin e lidhjeve ndryshe nga HTTP/1.1. Trajtojeni versionin e negociuar si pjesë të matjes, jo si fusnotë.

Pse krahasimi mat ciklin e jetës

Krijimi i një klienti të re për çdo operacion dhe krahasimi i tij me një tunel që është lidhur prej një ore krahason vendosjen e lidhjes me një gjendje të qëndrueshme. Kjo është një matje e ligjshme, dhe nuk është HTTPS kundrejt VPN. Dy ekzekutime me të njëjtin konfigurim klienti e përshkruajnë sjelljen më mirë se një, sidomos kur ekzekutimi i parë ngroh një zgjidhës ose një cache lidhjesh.

Mbani konstant operacionin API, serverin, llogarinë dhe të dhënat, përndryshe krahasimi mbart më shumë se një ndryshore. Vendosni paraprakisht ku e vendosni kohëmatësin, sepse vendosja, negociimi TLS, ekzekutimi i aplikacionit dhe dorëzimi i përgjigjes kontribuojnë ndryshe në total. Një kohëmatës i vetëm i kërkesës së parë karakterizon vendosjen dhe nuk thotë asgjë për trafikun e qëndrueshëm që vërtet drejtoni. Shkruani kufijtë e kohëmatësit pranë numrave.

Ndani vendosjen e ftohtë nga kërkesat e ngrohta

Matni kërkesën e parë veçmas nga ato që vijnë pas saj. Pastaj shtoni çfarë shërbimi sheh vërtet: periudha joaktive, shpërthime, njëkohshmëri, madhësinë e përgjigjes dhe rilidhjet.

Mbani aktiv validimin e certifikatave dhe HTTPS në të dyja rrugët, sepse heqja e tyre mat një dizajn sigurie të ndryshëm dhe jo një më të shpejtë. Nëse tuneli ndryshon rrugën ose vendndodhjen e portës, raportoni atë ndryshim veçmas në vend që t'i atribuoni çdo ndryshim kohe kriptimit, sepse rruga, humbja dhe radha mund të dominojnë një kërkesë të vogël. Ekzekutoni çdo rrugë dy herë në të njëjtën rrugë përpara se të nxirrni një përfundim. Shënoni protokollin e negociuar dhe kufijtë e kohëmatësit me të dyja ekzekutimet.

Planifikoni për lidhjen që mbyllet

I qëndrueshëm nuk do të thotë i përhershëm. Një server, një proxy ose një ndryshim rrjeti mund të mbyllë një lidhje gjatë një periudhe joaktive, dhe klienti duhet të rimëkëmbet përmes sjelljes që mbështet biblioteka e tij. Ajo rimëkëmbje ka një makinë gjendjesh: kërkesa mund të jetë përfunduar në server, ose mund të ketë dështuar përpara se serveri ta lexojë, dhe një socket i mbyllur nuk i thotë thirrësit se cila ndodhi. Një operacion jo-idempotent në atë pozicion nuk mund të riprodhohet thjesht, sepse një riprodhim e kthen një rezultat të panjohur në një shkrim të dyfishtë. Këtu një tunel i ngrohtë dhe një lidhje e ngrohtë sillen njësoj, sepse të dy mund të dështojnë në momentin kur puna është në rrjedhë.

Përdorni mekanizmin e dokumentuar të riprovimit ose të idempotencës së shërbimit në vend të një cikli që rihap socket-in. Provoni rimëkëmbjen në mënyrë të qartë: mbyllni një lidhje joaktive dhe vëzhgoni çfarë bën klienti më pas. Rihapja e një socket-i nuk e bën të sigurt përsëritjen e një thirrjeje që ndryshon gjendjen.

Zgjidhni fillimisht kufirin, pastaj rregulloni

Zgjidhni kufirin e rrjetit nga kërkesat e aksesit dhe të besimit përpara se të optimizoni çdo gjë. Një VPN mbron segmentin midis palëve të tij, ndërsa pikat fundore të aplikacionit dhe çdo segment teksti të qartë jashtë tunelit vazhdojnë të kenë rëndësi. Pastaj rregulloni ciklin e jetës së lidhjes brenda atij kufiri. Përfundimi për tunelin më të lirë rrjedh vetëm nga bindja se çdo kërkesë përsërit handshake-in, dhe pikërisht ajo bindje provohet këtu.

Seksioni për qëndrueshmërinë në RFC 9112 është referenca për atë që ripërdorimi premton vërtet, duke përfshirë kushtet që përfundojnë një lidhje. Lexojeni një herë përpara se t'i besoni një matjeje që i injoron ato.