VPN-ja ra në mes të faqes: a dalin ende kërkesat në sfond?

Skeda ende shfaq panelin e kontrollit nga koha përpara se tuneli të vdiste. Numrat e statusit ngrinë, një rrotullues i vogël vazhdon të rrotullohet, dhe shiriti i adresave ende mban aplikacionin që hapët një orë më parë. Nuk prekët asgjë pas ndërprerjes, e megjithatë faqja mund të vazhdojë të përpiqet të arrijë serverin e saj sipas kalendarit të vet. Kjo është pjesa që njerëzit e humbin: një faqe thjesht e dukshme dhe një faqe që ende dërgon kërkesa duken njësoj nga jashtë, dhe vetëm njëra prej tyre shfaqet në një regjistër rrjeti.

Puna që një faqe nis pa ju

Katër mekanizma e mbajnë një dokument të ngarkuar të zënë. Një kohëmatës përsëritës mund të ekzekutojë përsëri një thirrje statusi çdo disa sekonda. Një fetch mund të aktivizohet kur skeda bëhet përsëri e dukshme pasi ktheheni tek ajo. Një kanal i drejtpërdrejtë i ndërtuar mbi WebSocket ose ngjarje të dërguara nga serveri mund të provojë një rilidhje sipas kalendarit të vet të tërheqjes. Një service worker i regjistruar nga sajti mund të zgjohet për një sinkronizim në radhë edhe kur nuk ka asnjë skedë përpara jush.

Asnjëra prej tyre nuk kërkon një klikim dhe asnjëra nuk e ringarkon dokumentin. Shiriti i adresave, pozicioni i lëvizjes dhe vlerat e paraqitura mbeten të gjitha aty ku ishin. Ndryshon vetëm ana e rrjetit: çdo përpjekje e re është një vendim i freskët i marrë në momentin kur fillon.

Ky dallim ka rëndësi sepse faqja e dukshme ruhet lokalisht. Pikselat e pikturuar tashmë nuk thonë asgjë nëse kërkesa e radhës pati sukses. Një grafik i ngrirë me një rrotullues është pamja e zakonshme e një faqeje, kërkesat e së cilës tani dështojnë. Leximi i ekranit ju tregon çfarë tha serveri disa minuta më parë, jo çfarë po bën shfletuesi tani.

Pse ngarkimi i mëparshëm i faqes nuk mban një rrugë

Asgjë në ngarkimin e faqes nuk e lidh dokumentin me tunelin. Rrugëzimi zgjidhet për çdo paketë, në momentin e dërgimit, nga tabela që ekziston kur paketa largohet. Kur ndërfaqja e tunelit zhduket, ai kërkim nuk përputhet më me rrugën e tunelit. Ose bie mbi përshtatësin fizik ose nuk gjen asgjë, në varësi të asaj që klienti la pas.

Kthimet e përsëritura janë detyra të planifikuara të zakonshme. Seksioni i kohëmatësve i standardit HTML përshkruan se si vendosen në radhë dhe e trajton intervalin si një vonesë minimale dhe jo si një premtim për ritëm të saktë, kështu që një skedë në sfond mund të pyesë shumë më rrallë sesa kërkon kodi i saj. Më pak përpjekje nuk është e njëjtë me asnjë përpjekje, dhe kthimi i një skede në plan të parë është një moment i zakonshëm për një shpërthim të tyre.

Ku zbret politika e dështimit

Bllokimi i klientit vlerësohet kur provohet një lidhje, jo kur u mor faqja. Nëse aksesi i zakonshëm është ende i lejuar, përpjekja e re mund të dalë përmes lidhjes fizike haptazi. Nëse politika e mban atë trafik derisa tuneli të kthehet, përpjekja dështon në momentin e lidhjes dhe faqja shfaq një gabim që mund ta provojë përsëri disa sekonda më vonë.

Dy detaje vendosin cilën prej tyre merrni. E para është shtrirja e zbatimit që mbështet klienti: një bllokim për të gjithë pajisjen, një bllokim i kufizuar në përshtatësin e tunelit, ose një grup rregullash me përjashtime. E dyta është nëse destinacioni bie brenda një përjashtimi që keni shtuar më parë për një printer lokal, një portal robërues ose një shërbim transmetimi.

Kriptimi në nivel aplikacioni nuk ndryshon asgjë nga kjo. HTTPS mbron bajtët midis shfletuesit dhe serverit; nuk thotë asgjë se cila ndërfaqe i transporton. Një faqe mund të jetë krejtësisht e kriptuar dhe prapë të dalë në rrugën e gabuar, dhe pikërisht këtë lejon një bllokim i ngushtë.

Një kontroll i kontrolluar me një faqe të hedhshme

Përdorni një host që e kontrolloni dhe një faqe që nuk bën gjë tjetër veçse e thërret, që të mos ketë të dhëna reale në lojë. Nga një terminal, merrni një mostër të rrugës përpara dhe pas ndërprerjes:

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

Ekzekutojeni me tunelin lart, më pas ulni tunelin dhe ekzekutojeni përsëri. Një përgjigje nga një adresë publike ndërsa tuneli është poshtë ju thotë se rruga e drejtpërdrejtë është e hapur. Një skadim kohe ose një lidhje e refuzuar ju thotë se politika po mban. Përsëriteni edhe një herë pasi klienti të rilidhet, që të shihni rrugën e tunelit duke u kthyer në vend që ta supozoni.

Në shfletues, paneli Rrjeti i ndan dy pyetjet. Filtroni në Fetch/XHR, pastaj lexoni kolonën e iniciatorit: një zë i nisur nga një kohëmatës ose një skript, pa navigim të regjistruar përpara tij, është përpjekje në sfond dhe jo ringarkim. Krahasoni kohën e fillimit me momentin kur tuneli ra. Nëse zëri është ende në pritje kur tuneli mungon, kërkesa po pret një rrugë që nuk ekziston më.

Provat nga ana e serverit janë më të forta se çdo gjë që tregon shfletuesi. Një regjistër kërkesash me vulë kohe dhe adresë burimi provon se paketa mbërriti. Zërat e shfletuesit mund të mbajnë cookies, tokena dhe URL të plota, ndaj mbani vetëm fushat që i nevojiten pyetjes suaj dhe mbuloni pjesën tjetër përpara se t'i ngjitni kudo.

Çfarë të bëni me përgjigjen

Nëse përpjekjet në sfond vazhdojnë të kenë sukses ndërsa tuneli është poshtë, bllokimi është më i ngushtë nga sa supozuat, dhe ajo e çarë vlen të mbyllet përpara se t'i besoni klientit punë të ndjeshme. Nëse dështojnë, politika po bën punën e saj dhe faqja e ngrirë është thjesht pamje. Në çdo rast, mbyllja e një skede nuk është kontroll për të gjithë pajisjen: skedat e tjera, shfletuesit e tjerë dhe aplikacionet e tjera planifikojnë secili punën e vet.

Hapa të mëtejshëm që ia vlen të ndërmerren: renditni cilat përjashtime keni shtuar dhe pse, konfirmoni nëse klienti bllokon vetëm trafikun brenda shtrirjes së tunelit apo të gjithë trafikun, dhe vëzhgoni një kërkesë në sfond nga fillimi në fund me regjistrin e serverit të hapur. Ato tri përgjigje mbulojnë pjesën më të madhe të asaj që një raport «VPN-ja ra dhe diçka është ende e lidhur» përmban në të vërtetë.