Faqja e chat-it hapet, por lidhja e drejtpërdrejtë dështon: ku duhet parë

Hap panelin e rrjetit përpara se të ngarkosh faqen e chat-it dhe më pas gjej kërkesën që mbart mesazhet, jo atë që vizaton skeletin e faqes. Dokumenti, skriptet, shkëmbimi gjatë hyrjes dhe transporti i chat-it mund të shkojnë të gjitha drejt pritësve të ndryshëm. Shumica e raporteve se VPN-i prishi chat-in përshkruajnë në fakt dështimin e njërës prej këtyre katër kërkesave. Shikoji me radhë dhe përgjigjja zakonisht duket në dy minutat e para.

Gjej kërkesën që mbart mesazhet

Filtro sipas llojit kur faqja qetësohet: një WebSocket shfaqet si zë më vete, një rrjedhë ngjarjesh mbetet e hapur me një përgjigje që rritet dhe një sondazh i gjatë përsëritet në interval të rregullt. Regjistro skemën, pritësin, portën dhe statusin për atë që mbart përditësimet. Vër re nëse filloi para apo pas hyrjes, sepse një transport i hapur para vërtetimit është zakonisht një dizajn tjetër nga ai i hapur pas tij. Lexo titujt e kërkesës për kërkesën e përmirësimit ose llojin e përmbajtjes së pranuar, sepse identifikojnë transportin që faqja e vendosur zgjodhi vërtet.

Postimet e vjetra në forum përshkruajnë transport të cilat produktet i braktisën vite më parë, prandaj beso asaj që regjistroi shfletuesi dhe jo artikullit. Nëse zëri mungon plotësisht, kodi i klientit mund të mos ketë provuar kurrë një lidhje, gjë që tregon një dështim të mëparshëm skripti ose konfigurimi. Ngarkimi i faqes provon vetëm se dokumenti mbërriti, dhe pikërisht ky dallim vendos nëse po korrigjon rrjetin fare.

Konfigurimi, dorëzimi dhe jetëgjatësia dështojnë ndryshe

Një WebSocket hapet me një përmirësim HTTP që përgjigjet me statusin 101, dhe gjithçka pas tij janë mesazhe të kornizuara dhe jo tërheqje faqesh, dy faza që RFC 6455 i mban haptazi të ndara. Një rrjedhë ngjarjesh përgjigjet me një lloj përmbajtjeje transmetimi dhe mban trupin e përgjigjes të hapur. Të dyja mund të dështojnë të hapen, të hapen dhe të mos dorëzojnë asgjë, ose të hapen, të dorëzojnë dhe pastaj të vdesin në heshtje.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

Kap dështimin e parë kuptimplotë përpara se të prekësh një profil, sepse tre momentet tregojnë shtresa të ndryshme. Nëse shtrëngimi i duarve nuk përfundon kurrë, krahasoje me një kërkesë të thjeshtë HTTPS drejt të njëjtit pritës për të parë nëse diçka arrin atje. Nëse përfundon dhe nuk vijnë mesazhe, vëzhgo kornizat ose trupin e rrjedhës ndërsa dikush dërgon një mesazh prove nga një llogari tjetër. Nëse funksionon dhe pastaj ndalon, shëno kohën e saktë dhe kodin e mbylljes, sepse ai çift identifikon cila anë u dorëzua.

Kodi 1006 do të thotë që socket-i u mbyll pa një kornizë mbylljeje, dhe kështu duket një ndërmjetës ose një afat i paveprimit nga brenda shfletuesit. Rrahja e zemrës së VPN nuk provon që sesioni i brendshëm i aplikacionit është ende i gjallë.

Pritësi i drejtpërdrejtë është destinacion më vete

Backend-et e chat-it shpesh jetojnë në emrin e tyre të pritësit, ndonjëherë në një portë tjetër ose pas një certifikate të veçantë. Ai destinacion kërkon zgjidhjen, rrugën dhe trajtimin e vet të proxy-t, dhe tunelimi i ndarë mund të përfshijë faqen duke përjashtuar socket-in. Zgjidh emrin e pritësit të drejtpërdrejtë nga makina kliente dhe konfirmo se përgjigjet me adresën që pret në atë rrjet. Kontrollo zinxhirin e certifikatave posaçërisht për atë emër pritësi, sepse një wildcard që mbulon faqen nuk mbulon gjithmonë pikën fundore të socket-it.

Nëse një proxy qëndron në rrugë, konfirmo se lejon përmirësimin ose përgjigjen afatgjatë në vend që ta mbajë në buffer. Proxy-t e korporatave që rishkruajnë HTML shpesh i trajtojnë keq përmirësimet WebSocket, gjë që jep një faqe që vizatohet ndërsa chat-i nuk lidhet kurrë. Dy kërkesa drejt të njëjtit produkt pra nuk janë dy kërkesa drejt të njëjtit pritës.

Rregullo listën e destinacioneve, jo kontrollet e sigurisë

Rregullimi i një liste destinacionesh është një ndryshim rrugëtimi dhe i përket pronarit të rrugës. Lehtësimi i vërtetimit të certifikatave ose heqja e titullit Origin është një ndryshim sigurie dhe i përket pronarit të politikës, i cili rrallë është personi që korrigjon biletën. Mënyra më e shpejtë për ta bërë një lidhje të duket e suksesshme është zakonisht mënyra më e shpejtë për ta bërë një incident të mundur.

Pyet pronarin e aplikacionit cilat origjina pranon backend-i përpara se të ndryshosh gjithçka, dhe kalo atë përgjigje tek ai që kontrollon proxy-n. Nëse një gabim certifikate shfaqet vetëm përmes tunelit, inspekto pajisjen që ndërhyn në vend që të instalosh një anashkalim.

Regjistro mjaftueshëm për ta dorëzuar

Artefakti i dobishëm është i shkurtër: URL-ja e faqes, pika fundore e drejtpërdrejtë, rezultati i shtrëngimit të duarve, koha e dështimit të parë dhe nëse u provua një rilidhje. Shto emrin e profilit VPN dhe rrjetin ku ishe, dhe kushdo që e lexon mund ta riprodhojë testin pa bërë gjashtë pyetje. Fshih cookie-t, titujt e autorizimit dhe trupin e mesazheve, dhe parapëlqe një pamje ekrani të kolonës së kohës sesa një eksport të plotë arkivi. Kornizat dhe arkivat e rrjetit mund të përmbajnë mesazhe private dhe shenja sesioni, prandaj inspekto përpara se të bashkëngjitësh gjithçka.

Nëse dështimi është një mbyllje e heshtur, përfshi kodin e mbylljes dhe intervalin e paveprimit përpara tij, sepse ai çift zakonisht identifikon pronarin e afatit. Dorëzo regjistrin pronarit të aplikacionit ose të portës në vend që të hamendësosh vetë një vlerë afati. Përgjigjja e tyre për sjelljen e mbështetur të keepalive është ajo që mbyll biletën.