Një Middleware Serveri Që Ndalon Kërkuesit Të Rremë Para Se Të Arrijin Në Aplikacionin Tuaj

Tubacioni i kërkesave në një aplikacion web është diçka elegante. Një kërkesë arrin në serverin web, kalon përmes një radie middleware, arrin në një kontrollor, dhe kthehet përgjigje. Çdo middleware në radë ka mundësinë të inspektojë kërkesën, ta modifikojë atë, ta kalojë më tutje, ose ta refuzojë plotësisht. Kjo arkitekturë është e përsosur për zbatimin e detektimit të boteve sepse verifikimi ndodh përpara se kërkesa të prekë logjikën e aplikacionit. Një kërkues i rremë që pretendon të jetë Googlebot identifikohet dhe bllokohet në shtresën middleware, dhe kontrollori nuk e di madje që kërkesa ka ekzistuar. Asnjë cikël CPU i shpenzuar për dhënien e një faqeje. Asnjë pyetje baze të dhënash e ekzekutuar. Asnjë futje cache e plotësuar. Boti i rremë bllokohet në derë, dhe burimet e serverit që do të kishin qenë konsumuar ruhen për vizitorët legjitime.

Motivimi për ndërtimin e këtij middleware erdhi nga një problem konkret dhe i shtrenjtë. Një aplikacion i madh po konsumuante gjerësinë e brezit dhe burimet e serverit me shpejtësi që nuk korrespondonte me bazën e tij aktuale të përdoruesve. Regjistrat e aksesit zbuluuan vëllime masive kërkesash nga agjentë përdoruesish që pretendojnë të jenë Googlebot, Bingbot, dhe kërkuesit e tjerë të ligjshëm. Hetimet konfirmuan se shumica e këtyre ishin të rremë, që burojnë nga ofruesit e hostimit në re në vend se të motorëve të kërkimit që ata pretendojnë të përfaqësojnë. Çdo kërkesë e rremë konsumuante të njëjtat burime serveri si ajo e vërtetë: të njëjtën kohë ekzekutimi PHP, të njëjtat pyetje në bazën e të dhënave, të njëjtën alokimin e kujtesës, të njëjtën gjerësinë e brezit për përgjigjen. Shumëzuar në të gjithë mijëra kërkesa të rremë në orë, kostoja ishte substanciale. Zgjidhja middleware ishte projektuar për të eleminuar këtë shpenzim duke kapur kërkuesit të rremë përpara se ata të konsumuanin ndonjë burim aplikacioni.

Zbatimi ndjek një model të drejtpërdrejtë që çdo zhvillues backend mund ta përshtatë. Middleware përgjegja çdo kërkesë hyrëse, kontroller nëse vargu i agjentit të përdoruesit përputhet me një model kërkuesit të motorit të kërkimit të njohur, dhe nëse e bën, verifikon adresën IP të kërkesës kundër infrastrukturës së njohur të kërkuesit duke përdorur API-n e detektimit të boteve. Kërkesa që pretendojnë të jenë kërkuesit por nuk kalojnë verifikimin bllokohen me një përgjigje 403. Kërkesa që kalojnë verifikimin, ose që nuk pretendojnë të jenë kërkuesit në të gjithë, vazhdojnë përmes radës middleware normalisht. Kontrolli i tërë shton latencën minimale sepse rezultatet e verifikimit ruhen në cache për adresë IP, që do të thotë se çdo IP unike verifikohet vetëm një herë.

Logjika e Vendimeve Pas Bllokimit në Shtresën Middleware

Zgjedhja për të bllokuar në shtresën middleware në vend se në nivelin e serverit web (Nginx ose Apache) ose në nivelin e aplikacionit (brenda kontrolluesve) është një vendim arkitekturor i qëllimshëm me kompromise specifike. Bllokimi në nivelin e serverit web është opsioni më efiçient për sa i përket konsumimit të burimeve sepse kërkesa nuk arrin në PHP fare. Megjithatë, konfigurimi i serverit web për detektimin e boteve zakonisht përfshin lista statike të bllokimit të IP-ve ose përputhje të thjeshta të agjentëve të përdoruesish, asnjëra e të cilave nuk siguron verifikimin dinamik të bazuar në API-n e nevojshme për të dalluar saktë kërkuesit e vërtetë nga të rremët. Mirëmbajtja e një liste statike të bllokimit të milionave adresave IP është impraktike, dhe përputhja e agjentit të përdoruesit vetëm nuk mund të verifikojë identitetin sepse agjentët e përdoruesish mund të falsifikohen lehtë.

Bllokimi në nivelin e aplikacionit, brenda kontrolluesve ose klasave të shërbimit, është opsioni më fleksibël por më pak efiçient. Në kohën kur kërkesa arrin në një kontrollor, radia middleware ka ekzekutuar tashmë, përshkrimi i rrugës ka zgjidhur, dhe potencialisht operacionet e shtrenjta si inicializimi i seancës dhe autentifikimi kanë ndodhur tashmë. Bllokimi në këtë pikë shpëton kohën e ekzekutimit të kontrollorit por shpenzoi gjithçka që ndodhi përpara tij. Për aplikacionet me trafik të lartë ku kërkesa boti të rremë numërojnë në mijëra në orë, ky përpunim i dëmtuar i mëparshëm arrin.

Shtresa middleware qëndron në pikën optimale në tubacion. Ekzekutohet përpara menaxhimit të seancës, përpara autentifikimit, përpara middleware-specifik të rrugës, dhe sigurisht përpara logjikës së ndonjë kontrolluesi. Por ka qasje në objektin e plotë të kërkesës, duke përfshirë headerat, adresat IP, dhe parametrat e pyetjeve, që do të thotë se mund të kryejë logjikën e verifikimit sofistikuar në vend të përputhjes së thjeshtë të modeleve. Middleware mund të quajë një API të jashtme, rezultatet në cache, të aplikojë logjikën kushtore bazuar në identitetin e pretenduar, dhe të regjistrojë rezultatet e verifikimit për analiza. Kjo kombinim i efiçiencës dhe fleksibilitetit e bën middleware shtëpinë natyrale për detektimin e boteve në një aplikacion web.

Strategjia e cache është veçanërisht e rëndësishme për performancën. Pa cache, çdo kërkesë nga një kërkues i pretenduar do të kërkonte një thirrje API për të verifikuar adresën IP. Edhe me një API të shpejtë, kjo do të shtonte latencën për çdo kërkesë. Zgjidhja është të ruash rezultatet e verifikimit në cache të çelësuar sipas adresës IP, me një kohë-për-të-jetë disa orësh ose madje një dite të plotë. Kërkuesit e motorit të kërkimit operojnë nga rreze IP të qëndrueshme që ndryshojnë rrallë, kështu që një rezultat i verifikimit në cache mbetet i vlefshëm për periudha të zgjatura. Kur një kërkesë arrin nga një Googlebot i pretenduar, middleware fillimisht kontrollon cache-in. Nëse IP ishte verifikuar si legjitime brenda periudhës cache, kërkesa lejohet përmes menjëherë. Nëse IP ishte verifikuar si e rremë, ajo bllokohet menjëherë. Vetëm adresat e para të kohës kërkojnë një thirrje aktuale të API-t, dhe pas asaj thirrjeje iniciale, rezultati shërbehet nga cache me kosto latence të papërfillshme.

Çfarë Ndodh me Kërkesa Që Bllokuhen

Bllokimi i një kërkuesi të rremë nuk është thjesht një çështje e kthimit të një përgjigje 403 dhe vazhdimit. Vendimi i bllokimit dhe konteksti i tij duhet të regjistrohet për analiza. Çdo kërkesë e bllokuar përfaqëson një pikë të dhënash rreth kush po përpiqet të hyjë në faqen e internetit, çfarë pretendojnë të jenë, dhe nga vijnë. Me kalimin e kohës, ky regjistër zbërthen modele që informojnë vendimet më të gjerë të sigurisë. Ndoshta një ASN specifik është përgjegjës për një pjesë disproporcionale të kërkuesve të rremë. Ndoshta kërkesa të rremë Googlebot arrosen në orë të caktuara të ditës. Ndoshta një rrugë URL e veçantë tërhiq më shumë kërkuesit të rremë se të tjerë, duke sugjeruar që botët po synojnë përmbajtjen specifike.

Përgjigja ndaj një kërkesë të bllokuar mund të jetë gjithashtu më nuancuar se një 403 i përgjithshëm. Disa zbatimi kthejnë një 429 (Shumë Kërkesa) për ta nxehur faktin se boti ka qenë identifikuar, duke e bërë më të vështirë për operatorin e botit të përshtatë qasjen e tyre. Të tjerët kthejnë një 200 me një trup bosh, i cili shpenzoi gjerësinë minimale të brezit ndërkohë që parandalon bototin nga dija se ai ka qenë zbuluar. Qasjet më agresive kthejnë një 403 me një mesazh që tregon se verifikimi i kërkuesit dështoi, i cili është transparent por jep operatorëve të boteve informacion rreth mekanizmit të zbulimit. Zgjedhja varet nga filozofia e operatorit të faqes në lidhje me transparencën kundër sigurisë operacionale.

Për botët që pretendojnë të jenë kërkuesit por janë në të vërtetë shërbime legjitime që ndodh të përdorin varje të agjentit të kërkuesit në mënyrë të pasaktë, bllokimi mund të jetë më i shqetësues se pretenduar. Disa mjete të monitorimit SEO, për shembull, përdorin agjentë të ngjashëm me Googlebot për të simuluar se si Google shikon një faqe. Këto mjete do të dështojnë verifikimin sepse nuk janë Google, edhe pse qëllimi i tyre është legjitime nga perspektiva e operatorit të faqes. Middleware mund ta përqafojë këtë duke ruajtur një listë të lejimeve të intervaleve IP për shërbime të njohura të palëve të treta, ose duke aplikuar verifikimin vetëm për modele të caktuara të agjentit të përdoruesit ndërkohë që injoron të tjerët. Fleksibilitatea e qasjes middleware lejon këtë lloj politike nuancuese pa kërkuar ndryshime në konfigurimin e serverit web ose në kodin e aplikacionit.

Verifikimi Sinkron Kundër Asinkron

Pyetja nëse të verifikojmë botët në mënyrë sinkrone ose asinkrone ndikon si në efektivitetin e bllokimit ashtu edhe në ndikimin e performancës në aplikacion. Verifikimi sinkron do të thotë middleware pushon kërkesën, thirrje API verifikimi, pret përgjigjen, dhe pastaj ose lejon ose bllokon kërkesën bazuar në rezultatin. Kjo qasje siguron bllokimin e menjëhershëm por shton latencën ndaj kërkesës së parë nga çdo adresë IP. Me cache, latenca ndikon vetëm në kërkesën e parë, por për aplikacionet me trafik të lartë edhe ajo vonesë rastesore mund të jetë e papranueshme.

Verifikimi asinkron merr një qasje të ndryshme. Kërkesa e parë nga një IP e re lejohet përmes ndërkohë që një punë verifikimi radhitet në sfondin. Kur rezultati i verifikimit vjen mbrapa, ai ruhet në cache, dhe të gjitha kërkesa të mëvonshme nga ai IP trajtohen sipas rezultatit. Kjo qasje shton zero latencë në tubacionin e kërkesave por lejon një numër të vogël të kërkesave fillestare nga botët të rremë të kalojnë përpara se verifikimi të përfundojë. Për shumicën e aplikacioneve, ky kompromis është i pranueshëm. Një bot i rremë që dërgon tre kërkesa përpara se të bllokohet ka konsumuar shumë më pak burime se ajo që dërgon mijëra kërkesa pa veprim.

Sistemi i radhës e bën qasjen asinkrone të drejtpërdrejtë. Middleware-i dërgon një punë verifikimi që thirrje API-n e detektimit të boteve, ruaj rezultatin në cache, dhe opsionalisht nxes një ngjarje të cilën pjesë të tjera të aplikacionit mund të dëgjojnë. Puna ekzekutohet në sekonda, që do të thotë se dritarja gjatë së cilës trafiku i botit i paverikuar mund të kalojë përmes është jashtëzakonisht i ngushtë. Për aplikacionet që përdorin një cache të shpejtë në memorie, rezultati i ruajtur në cache është i disponueshëm për të gjithë instancat e aplikacionit menjëherë, kështu që edhe në një mjedis të balancuar ngarkese, verifikimi duhet të ndodhë vetëm një herë për adresë IP në të gjithë shërbesat.

Një qasje hibride kombinon më të mirën e të dyja. Agjentë të njohur të boteve që përputhjen modele të sigurta të lartë të besimit shkaktuese verifikimin sinkron me rezultate të ruajtura në cache, duke shtuar latencën minimale. Modelet e besimit më të ulët shkaktuese verifikimin asinkron, duke lejuar kërkesën e parë përpara ndërkohë që verifikimi ekzekutohet në sfondin. Kjo qasje e shkallëzuar optimizohet për rastin e zakonshëm ndërkohë që trajton rastet e skajeve me mirësi. Pozicioni i middleware në tubacionin e kërkesave e bën atë vendin ideal për të zbatuar këtë logjikë, sepse ka qasje në të gjithë informacionin e nevojshëm për të bërë vendimin e rrugëzimit dhe ekzekutohet përpara logjikës s'ka shpenzim të aplikacionit.

Ndikimi i Matshëm i Bllokimit në Derë

Rezultatet e zbatimit të middleware detektimi të boteve janë të dukshme pothuajse menjëherë në metrikat e serverit. Ndryshimi më dramatik është në konsumin e gjerësisë së brezit. Kërkuesit e rremë kërkojnë faqe HTML të plota, duke përfshirë të gjithë aktivet të përmendura në përgjigje. Çdo kërkesë e bllokuar shpëton gjerësinë e brezit që do të kishte qenë e përdorur për të transmetuar përgjigjen e plotë, e cila për faqet e pasura në përmbajtje mund të jetë dhjetëra ose qindra kilobajt për kërkesë. Në të gjithë mijëra kërkesa të bllokuara në orë, kursimin e gjerësisë së brezit grumbullohet në reduktimin e kuptimshëm të kostove, veçanërisht për aplikacionet e strehëzuara në ofrues që tarifojnë për gigabajt të transferit.

Shfrytëzimi i CPU bie sepse serveri nuk ekzekuton më kodin PHP, nuk ekzekuton pyetje në bazën e të dhënave, dhe nuk dhënie template për kërkesa që nuk prodhojnë vlerë. Reduktimi është më i dukshëm gjatë orëve jashtë orëve të pikut kur trafiku njerëzor është i ulët por trafiku i boteve mbetet konstant. Para zbatimit të middleware, serveri mbante një shfrytëzim bazalinereg të CPU madje edhe në tre të mëngjesit sepse botët nuk flenë. Pas zbatimit, shfrytëzimi jashtë orëve të pikut bie në afër zeros, duke i dhënë serverit hapësirë për trafikun legjitime gjatë orëve me ngarkesë.

Kohë përgjigje për vizitorët legjitime përmirësohen si pasojë e drejtpërdrejtë e ngarkesës së ulur të serverit. Një server web që trajton pesëqind kërkesa në sekondë, treqind e të cilave janë botë të rremë, ka më pak kapacitet të disponueshëm për dyqind vizitorët reale se sa serveri që trajton vetëm dyqind kërkesa në sekondë, të gjithë e të cilave janë legjitime. Middleware nuk thjesht kursen burime në kërkesa të bllokuara. Ai përmirëson cilësinë e shërbimit për çdo kërkesë që kalon përmes, sepse serveri ka më shumë kapacitet të disponueshëm për punën reale.

Ngarkesa e bazës të dhënave bie proporcionalisht. Nëse aplikacioni pyet bazën e të dhënave për çdo kërkesë faqeje, bllokimi i treqind kërkesash të rremë në sekondë eleminon treqind pyetje të panevojshme në bazën e të dhënave në sekondë. Për aplikacionet me pyetje komplekse ose lidhje të kufizuara të bazës të dhënave, ky reduktim mund të jetë dallimi midis funksionimit të qëndrueshëm dhe mbingarkesës periodike. Middleware mbron të gjithë grupin, nga serveri web përmes shtresës së aplikacionit në bazën e të dhënave, duke ndaluar trafikun e padëshiruar përpara se ai të arrijë në ndonjërin e tyre.