Serverový Middleware, Ktorý Zastaví Falošné Crawlery Skôr, Než Dosiahnu Vašu Aplikáciu

Požiadavková pipeline vo webovej aplikácii je elegantná vec. Požiadavka príde na webový server, prejde cez zásobník middleware, dosiahne kontrolér a vráti odpoveď. Každý middleware v zásobníku má možnosť skontrolovať požiadavku, upraviť ju, posunúť ďalej alebo ju úplne odmietnuť. Táto architektúra je ideálna na implementáciu detekcie botov, pretože overenie prebieha skôr, ako požiadavka dotkne akúkoľvek logiku aplikácie. Falošný crawler tvrdiacich, že je Googlebot, sa identifikuje a zablokuje v middleware vrstve a kontrolér ani nevie, že požiadavka existovala. Žiadne CPU cykly zmarnené na vykresľovanie stránky. Žiadne databázové dopyty. Žiadne položky cache. Falošný bot je zastavený pri dverách a serverové zdroje, ktoré by boli spotrebované, sú zachránené pre legitímnych návštevníkov.

Motivácia na vytvorenie tohto middleware pochádza z konkrétneho a drahého problému. Veľká aplikácia spotrebúvala šírku pásma a serverové zdroje v miere, ktorá nekorešpondovala s jej skutočnou používateľskou základňou. Záznamy o prístupe odhalili obrovský objem požiadaviek od používateľských agentov tvrdiacich, že sú Googlebot, Bingbot a ďalšie legitímne crawlery. Vyšetrovanie potvrdilo, že väčšina z nich bola falošná, pochádzajúca z cloudových hostingových služieb namiesto vyhľadávačov, ktorých sa tvárili. Každá falošná požiadavka spotrebovala rovnaké serverové zdroje ako tá skutočná: rovnaký čas vykonávania PHP, rovnaké databázové dopyty, rovnaké prideľovanie pamäte, rovnakú šírku pásma pre odpoveď. Vynásobená tisíckami falošných požiadaviek za hodinu, bola cena podstatná. Riešenie middleware bolo navrhnuté na elimináciu tohto plýtvanie chytením falošných crawlerov skôr, ako spotrebujú akékoľvek aplikačné zdroje.

Implementácia nasleduje jednoduchý vzor, ktorý môže prispôsobiť akýkoľvek backend vývojár. Middleware zachytí každú prichádzajúcu požiadavku, skontroluje, či reťazec používateľského agenta zodpovedá známemu vzoru crawler vyhľadávača, a ak áno, overí IP adresu požiadavky voči známej infraštruktúre crawlera pomocou API detekcie botov. Požiadavky, ktoré sa tvrdia, že sú crawlery, ale nezaložia overenie, sa zablokujú s odpoveďou 403. Požiadavky, ktoré overenie prejdú, alebo ktoré sa nepretvárajú, že sú crawlery, pokračujú cez middleware zásobník normálne. Celá kontrola pridáva minimálnu latenciu, pretože výsledky overenia sú uložené v cache na IP adresu, čo znamená, že každá jedinečná IP je overená len raz.

Logika Rozhodovania Za Blokovením na Middleware Vrstve

Voľba blokovať na middleware vrstve namiesto na webovej úrovni servera (Nginx alebo Apache) alebo na úrovni aplikácie (v rámci kontrolérov) je zámerne architektonické rozhodnutie s špecifickými kompromismi. Blokovanie na úrovni webového servera je najefektívnejší variant z hľadiska spotreby zdrojov, pretože požiadavka nikdy nedosiahne PHP. Konfigurácia webového servera na detekciu botov však zvyčajne zahŕňa statické IP blacklisty alebo jednoduché porovnávanie používateľských agentov, z ktorých ani jedno neposkytuje dynamické, API-riadené overenie potrebné na presné rozlíšenie skutočných crawlerov od falošných. Udržiavanie statického zoznamu milión IP adries nie je praktické a porovnávanie používateľských agentov samo osebe nemôže overiť identitu, pretože používateľské agenty sú triviálne falšovateľné.

Blokovanie na úrovni aplikácie, v rámci kontrolérov alebo servisných tried, je najflexibilnejšia voľba, ale najmenej efektívna. V momente, keď požiadavka dosiahne kontrolér, middleware zásobník už vykonala, trasa bola vyriešená a potenciálne drahé operácie, ako je inicializácia sedenia a autentifikácia, už nastali. Blokovanie v tomto bode šetrí čas vykonávania kontroléra, ale mrhá všetkým, čo sa stalo pred tým. Pre vysokoprevozné aplikácie, kde falošné bot požiadavky čísla v tisícoch za hodinu, sa toto zmarnené predspracovanie skladá.

Middleware vrstva sedí na optimálnom bode v pipeline. Vykonáva sa pred spracovaním sedenia, pred autentifikáciou, pred middleware špecifickým pre trasu a istotne pred akoukoľvek logikou kontroléra. Ale má prístup k plnému objektu požiadavky, vrátane záhlavá, IP adries a parametrov dotazu, čo znamená, že môže vykonávať sofistikovanú logiku overenia namiesto jednoduchého porovnávania vzorov. Middleware môže zavolať externému API, uložiť výsledky do cache, aplikovať podmienenú logiku na základe tvrdiac identity a protokolovať výsledky overenia na analýzu. Táto kombinácia efektívnosti a flexibility robí middleware prirodzeným domovom pre detekciu botov vo webovej aplikácii.

Stratégia cache je obzvlášť dôležitá pre výkonnosť. Bez cacheingu by každá požiadavka od tvrdiac crawlera vyžadovala API hovor na overenie IP adresy. Aj pri rýchlom API, to by pridalo latenciu do každej požiadavky. Riešenie je cache overením výsledkov s kľúčom IP adresa, s životnosťou niekoľko hodín alebo dokonca celý deň. Vyhľadávače crawlery pracujú zo stabilných rozsahov IP, ktoré sa menia zriedka, takže uložený výsledok overenia zostáva platný dlhší čas. Keď požiadavka príde od tvrdiacich Googlebot, middleware najskôr skontroluje cache. Ak bola IP overená ako legitímna v rámci cache obdobia, požiadavka je hneď povolená. Ak bola IP overená ako falošná, je hneď zablokovaná. Len IP adresy prvýkrát vyžadujú skutočný API hovor, a po tom iniciálnom hovore, je výsledok podávaný z cache pri zanedbateľnej náklady latencii.

Čo sa Deje s Požiadavkami, Ktoré sa Blokujú

Blokovanie falošného crawlera nie je jednoducho vrátením odpovede 403 a pokračovaním ďalej. Rozhodnutie o blokovaní a jeho kontext by mali byť zaznamenané na analýzu. Každá zablokovaná požiadavka predstavuje dátový bod o tom, kto sa pokúša prístupiť na lokalitu, čo sa pretvárajú, že sú, a odkiaľ pochádzajú. V čase sa tento záznam odhaľuje vzory, ktoré informujú širšie bezpečnostné rozhodnutia. Možno špecifické ASN je zodpovedné za neúmerný podiel falošných crawlerov. Možno falošné Googlebot požiadavky skúšajú v určitých časoch dňa. Možno špecifická trasa adresy privádza viac falošných crawlerov ako iné, čo naznačuje, že boty sa zameriavajú na špecifický obsah.

Odpoveď na zablokovanú požiadavku môže byť aj viac nuansovanejšia ako blanšetová 403. Niektoré implementácie vrátia 429 (Príliš Veľa Požiadaviek) na skrytie skutočnosti, že bot bol identifikovaný, čo sťažuje bot operátorovi prispôsobenie svojho prístupu. Iní vrátia 200 s prázdnym telom, čo mrhá minimálnou šírkou pásma a zároveň bráni botovi vedieť, že bol zistený. Agresívnejšie prístupy vrátia 403 so správou naznačujúcou, že overenie crawlera zlyhalo, ktoré je transparentné, ale dávajú bot operátorom informácie o mechanizme detekcie. Voľba závisí od filozofie operátora lokality o transparentnosti verzus operačnej bezpečnosti.

Pre boty, ktoré sa tvrdia, že sú crawlery, ale sú v skutočnosti legitímne služby, ktoré omylom používajú reťazce používateľských agentov podobné vyhľadávaču, blokovanie môže byť viac rušivé ako zámerné. Niektoré SEO monitorovacie nástroje napríklad používajú Googlebot-podobné používateľské agenty na simuláciu toho, ako Google vidí stránku. Tieto nástroje zlyháva overenie, pretože nie sú Google, aj keď ich účel je legitímny z hľadiska operátora lokality. Middleware to môže urobiť udržiavaním whitelist známych rozsahov IP pre dôveryhodné služby tretích strán, alebo aplikáciou overenia iba na špecifické vzory používateľských agentov pri ignorovaní iných. Flexibilita middleware prístupu umožňuje tento druh nuansovanej politiky bez potreby zmien v konfigurácii webového servera alebo kóde aplikácie.

Synchronné Versus Asynchronné Overenie

Otázka, či overovať boty synchrónne alebo asynchrónne, ovplyvňuje aj účinnosť blokovania a dopad na výkonnosť aplikácie. Synchronné overenie znamená, že middleware pozastaví požiadavku, zavolá overovací API, čaká na odpoveď a potom buď povolí alebo zablokuje požiadavku na základe výsledku. Tento prístup poskytuje okamžité blokovanie, ale pridáva latenciu k prvej požiadavke z každej IP adresy. S cachingom je latencia ovplyvňuje len prvú požiadavku, ale pre vysokoprevozné aplikácie aj ten príležitostný odsun môže byť neprijateľný.

Asynchronné overenie naberá iný prístup. Prvá požiadavka z novej IP je povolená cez kým sa overovacia úloha front-loads na pozadí. Keď sa overovací výsledok vráti, je uložený v cache a všetky nasledujúce požiadavky z tej IP sa spracovávajú podľa výsledku. Tento prístup nepridáva latenciu k pipeline požiadavky, ale dovoľuje malý počet počiatočných požiadaviek od falošných botov prejsť pred dokončením overenia. Pre väčšinu aplikácií je tento kompromis prijateľný. Falošný bot, ktorý posiela tri požiadavky predtým, ako sa zablokuje, spotreboval oveľa menej zdrojov ako ten, ktorý posiela tisícky požiadaviek bez prekážok.

Systém fronta robí asynchronný prístup jednoduchým. Middleware odešle overovaniu úlohu, ktorá volá API detekcie botov, ukladá výsledok do cache a voliteľne spúšťa event, na ktorý ostatné časti aplikácie môžu počúvať. Úloha bežať v sekundách, čo znamená, že okno, počas ktorého neoverená bot prevádzka môže prejsť, je mimoriadne úzke. Pre aplikácie pomocou rýchleho v-pamäti cache, je uložený výsledok dostupný všetkým aplikačným inštanciám ihneď, takže aj v aplikácii s vyvažovaním záťaže, overenie musí nastať iba raz na IP adresu na všetkých serveroch.

Hybridný prístup spája to najlepšie z oboch. Známy bot používateľských agentov, ktoré zodpovedajú vysoko-záverečným vzorom spúšťajú synchronné overenie s uloženými výsledkami, pridávajúc minimálnu latenciu. Nižšie-záverečné vzory spúšťajú asynchronné overenie, dovoľujúc prvú požiadavku cez kým overenie beží na pozadí. Tento vrstvený prístup optimalizuje pre bežný prípad pri zvládaní okrajových prípadov milostivo. Middleware pozícia v pipeline požiadavky robí ho ideálnym miestom na implementáciu tejto logiky, pretože má prístup k všetkým informáciám potrebným na routing rozhodnutie a vykonáva sa skôr ako drahá aplikačná logika.

Merateľný Vplyv Blokovania pri Dverách

Výsledky implementácie middleware detekcie botov sú viditeľné takmer ihneď v metrikách servera. Najdramatickejšia zmena je v spotrebe šírky pásma. Falošní crawlery si požadujú úplné HTML stránky, vrátane všetkých assetov odkazovaných v odpovedi. Každá zablokovaná požiadavka šetrí šírku pásma, ktorá by bola použitá na prenos plnej odpovede, ktorá pre obsahu-ťažké stránky môžu byť desiatky alebo stovky kilobajtov na požiadavku. V priebehu tisícok zablokovaných požiadaviek za hodinu, úspory šírky pásma sa hromadia do zmysluplného zníženia nákladov, obzvlášť pre aplikácie hostované na poskytovateľoch, ktorí účtujú za gigabajt prenosu.

Využitie CPU klesá, pretože server už nevykonáva PHP kód, spúšťa databázové dopyty a vykresľuje šablóny pre požiadavky, ktoré neprinášajú žiadnu hodnotu. Zníženie je najviac viditeľné počas mimo-špičky, keď je ľudská prevádzka nízka, ale bot prevádzka zostáva konštantná. Pred implementáciou middleware, server udržiaval základnú CPU utilitu aj o tretej ráno, pretože boty nespávajú. Po implementácii, mimo-špičky utilita klesá takmer na nulu, čo dáva serveru priestor pre legitímnu prevádzku počas špičky.

Časy odpovede pre legitímnych návštevníkov sa zlepšujú ako priamy dôsledok zníženia záťaže servera. Webový server spracúvajúci päťsto požiadaviek za sekundu, z ktorých tristo sú falošní boty, má menej kapacity dostupnej pre dvestí reálnych návštevníkov ako server spracúvajúci iba dvesto požiadaviek za sekundu, všetky sú legitímne. Middleware nie je iba oslobodenie zdrojov na zablokovaní požiadavkách. Zlepšuje kvalitu služby pre každú požiadavku, ktorá prejde, pretože server má viac kapacity dostupnej pre skutočnú prácu.

Záťaž na databáze klesá proporcionálne. Ak aplikácia sa query databázu pre každú požiadavku stránky, blokovanie tristo falošných požiadaviek za sekundu eliminuje tristo nepotrebných databázových dopytov za sekundu. Pre aplikácie s komplexnými dopytami alebo obmedzenými pripojeniami databázy, toto zníženie môže byť rozdielom medzi stabilným prevádzkou a periodickým preťažením. Middleware chráni celý zásobník, od webového servera cez aplikačnú vrstvu do databázy, zastavením nežiadanej prevádzky skôr, ako dosiahne ktorýkoľvek z nich.