En Server Middleware Der Stopper Falske Crawlers, Før de Når Din Applikation

Anmodningspipelinen i en webapplikation er elegant. En anmodning ankommer til webserveren, passerer gennem en stack af middleware, når en controller og returnerer et svar. Hvert middleware i stakken har mulighed for at inspicere anmodningen, ændre den, videregive den eller helt afvise den. Denne arkitektur er perfekt til implementering af bot-detektions, fordi verifikationen sker før anmodningen berører nogen applikationslogik. En falsk crawler, der udgiver sig for at være Googlebot, bliver identificeret og blokeret i middleware-laget, og controlleren ved aldrig engang, at anmodningen eksisterede. Ingen CPU-cykler spildt på sidering. Ingen databaseforespørgsel udført. Ingen cache-indgange populeret. Den falske bot bliver stoppet ved døren, og de serverressourcer, der ville være blevet forbrugt, bliver bevaret til legitime besøgende.

Motivationen for at bygge denne middleware kom fra et konkret og dyrt problem. En stor applikation forbrugte båndbredde og serverressourcer med hastigheder, der ikke korrelerede med dens faktiske brugerbasis. Adgangsloggene afslørede massive mængder af anmodninger fra brugeragenter, der påstod at være Googlebot, Bingbot og forskellige andre legitime crawlers. Undersøgelser bekræftede, at størstedelen af disse var falske og stammede fra cloud-hostingudbydere i stedet for de søgemaskiner, de påstod at repræsentere. Hver falsk anmodning forbrugte de samme serverressourcer som en rigtig: samme PHP-eksekveringstid, samme databaseforespørgsler, samme hukommelsestildeling, samme båndbredde til responsen. Multipliceret over tusinder af falske anmodninger per time var omkostningen væsentlig. Middleware-løsningen blev designet til at eliminere dette spild ved at fange falske crawlers før de forbrugte nogen applikationsressourcer.

Implementeringen følger et ligetil mønster, som enhver backend-udvikler kan tilpasse. Middleware afbyder hver indgående anmodning, tjekker om brugeragent-strengen matcher et kendt søgemaskine-crawler-mønster, og hvis den gør, verificerer den anmodningens IP-adresse mod crawlernes kendte infrastruktur ved hjælp af bot-detektions-API'et. Anmodninger, der påstår at være crawlers, men fejler verifikationen, bliver blokeret med en 403-respons. Anmodninger, der består verifikationen, eller som slet ikke påstår at være crawlers, fortsætter gennem middleware-stakken normalt. Hele kontrollen tilføjer minimal latens, fordi verifikationsresultaterne er cachet pr. IP-adresse, hvilket betyder, at hver unik IP kun verificeres én gang.

Beslutningslogikken Bag Blokering på Middleware-Niveauet

Valget om at blokere på middleware-niveauet i stedet for på webserver-niveau (Nginx eller Apache) eller på applikationsniveauet (inden for controllers) er en bevidst arkitektonisk beslutning med specifikke afvejninger. Blokering på webserver-niveau er det mest effektive i forhold til ressourceforbrug, fordi anmodningen aldrig når PHP. Men webserver-konfiguration til bot-detektions involverer typisk statiske IP-sortelister eller simpel brugeragent-matching, som ingen af dem giver den dynamiske, API-drevet verifikation, der er nødvendig for nøjagtigt at skelne ægte crawlers fra falske. Det er upraktisk at vedligeholde en statisk sortelist over millioner af IP-adresser, og brugeragent-matching alene kan ikke verificere identitet, fordi brugeragenter er trivielt forfalsket.

Blokering på applikationsniveauet, inden for controllers eller serviceklasser, er det mest fleksible alternativ, men det mindst effektive. På det tidspunkt, hvor anmodningen når en controller, har middleware-stakken allerede udført, ruten er løst, og potentielt dyre operationer som sessioninitialisering og godkendelse er allerede sket. Blokering på dette punkt sparer controlleren eksekveringstid, men spilder alt det, der skete før det. For højtrafik-applikationer, hvor falske bot-anmodninger tæller tusinder per time, tilsammenlignes dette spildte præ-behandling.

Middleware-laget sidder på det optimale punkt i pipelinen. Det udføres før sessionstyring, før godkendelse, før rute-specifikt middleware og helt sikkert før nogen controllerlogik. Men det har adgang til det fulde anmodningsobjekt, herunder headers, IP-adresser og forespørgselsparameter, hvilket betyder, at det kan udføre sofistikeret verifikationslogik i stedet for simpel mønstergenkendelse. Middleware kan kalde et eksternt API, cache-resultater, anvende betinget logik baseret på den påstået identitet og logge verifikationsresultater til analyse. Denne kombination af effektivitet og fleksibilitet gør middleware til det naturlige hjem for bot-detektions i en webapplikation.

Cache-strategien er særlig vigtig for ydeevne. Uden cachelagring ville hver anmodning fra en påstået crawler kræve et API-kald for at verificere IP-adressen. Selv med et hurtigt API ville dette tilføje latens til hver anmodning. Løsningen er at cache verifikationsresultater efter IP-adresse med en time-to-live på flere timer eller endda en hel dag. Søgemaskine-crawlers opererer fra stabile IP-områder, der ændres sjældent, så et cachet verifikationsresultat forbliver gyldigt i længere periode. Når en anmodning ankommer fra en påstået Googlebot, tjekker middleware først cachen. Hvis IP'en blev verificeret som legitim inden for cache-perioden, tillades anmodningen gennem øjeblikkeligt. Hvis IP'en blev verificeret som falsk, bliver den blokeret øjeblikkeligt. Kun første-gangs IP-adresser kræver et faktisk API-kald, og efter det initiale kald bliver resultatet serveret fra cache med ubetydelig latens-omkostning.

Hvad Sker der med de Anmodninger, Der Bliver Blokeret

At blokere en falsk crawler er ikke blot et spørgsmål om at returnere en 403-respons og gå videre. Blokerings-beslutningen og dens kontekst bør logges til analyse. Hver blokeret anmodning repræsenterer et datapunkt om, hvem der forsøger at få adgang til stedet, hvad de udgiver sig for at være, og hvor de kommer fra. Over tid afsløres mønstret, der informerer bredere sikkerhedsbeslutninger. Måske er et specifikt ASN ansvarligt for en disproportion andel af falske crawlers. Måske falske Googlebot-anmodninger stiger på bestemte tidspunkter på dagen. Måske en bestemt URL-sti tiltrækker flere falske crawlers end andre, hvilket tyder på, at bots målretter specifikt indhold.

Responsen til en blokeret anmodning kan også være mere nuanceret end en ubetinget 403. Nogle implementeringer returnerer en 429 (For Mange Anmodninger) for at maskere det faktum, at botten er blevet identificeret, hvilket gør det sværere for bot-operatøren at justere deres tilgang. Andre returnerer en 200 med en tom tekst, som spilder minimal båndbredde, mens det forhindrer botten i at vide, at den er blevet detekteret. Mere aggressive tilgange returnerer en 403 med en meddelelse, der angiver, at crawler-verifikationen mislykkedes, som er transparent, men giver bot-operatører information om detektionsmekanismen. Valget afhænger af websted-operatørens filosofi om gennemsigtighed versus operationel sikkerhed.

For bots, der påstår at være crawlers, men som faktisk er legitime tjenester, der tilfældigvis bruger søgemaskine-brugeragent-strenge forkert, kan blokering være mere forstyrrende end tilsigtet. Nogle SEO-overvågningsværktøjer bruger for eksempel Googlebot-lignende brugeragenter til at simulere, hvordan Google ser en side. Disse værktøjer vil fejle verifikation, fordi de ikke er Google, selvom deres formål er legitimt fra websted-operatørens perspektiv. Middleware kan rumme dette ved at vedligeholde en hvidliste over kendte IP-områder for betroede tredjepartstjenester, eller ved at anvende verifikation kun på specifikke brugeragent-mønstre, mens andre ignoreres. Fleksibiliteten af middleware-tilgangen tillader denne slags nuanceret politik uden at kræve ændringer i webserver-konfiguration eller applikationskode.

Synkron Versus Asynkron Verifikation

Spørgsmålet om, hvorvidt bots skal verificeres synkront eller asynkront, påvirker både effektiviteten af blokering og præstationspåvirkningen på applikationen. Synkron verifikation betyder, at middleware pauser anmodningen, kalder verifikations-API'et, venter på responsen, og derefter enten tillader eller blokerer anmodningen baseret på resultatet. Denne tilgang giver øjeblikkelig blokering, men tilføjer latens til den første anmodning fra hver IP-adresse. Med cachelagring påvirker latensen kun den første anmodning, men for højtrafik-applikationer kan selv den lejlighedsvise forsinkelse være uacceptabel.

Asynkron verifikation tager en anden tilgang. Den første anmodning fra en ny IP tillades gennem, mens et verifikationsjob sættes i køen i baggrunden. Når verifikationsresultatet kommer tilbage, bliver det cachet, og alle efterfølgende anmodninger fra den IP'en håndteres i henhold til resultatet. Denne tilgang tilføjer nul latens til anmodnings-pipelinen, men tillader, at et lille antal initiale anmodninger fra falske bots passerer gennem, før verifikationen er fuldført. For de fleste applikationer er denne afvejning acceptabel. En falsk bot, der sender tre anmodninger, før den bliver blokeret, har forbrugt langt færre ressourcer end en, der sender tusinder af anmodninger uden hindring.

Kø-systemet gør den asynkrone tilgang ligetil. Middleware sender et verifikationsjob, der kalder bot-detektions-API'et, gemmer resultatet i cachen og affyrer eventuelt en begivenhed, som andre dele af applikationen kan lytte til. Jobbet køres på sekunder, hvilket betyder, at vinduet under hvilket uverificeret bot-trafik kan passere gennem, er ekstremt snævert. For applikationer, der bruger en hurtig in-memory cache, er det cachede resultat tilgængeligt for alle applikationsinstanser øjeblikkeligt, så selv i et load-balanced miljø behøver verifikationen kun at ske én gang pr. IP-adresse på tværs af alle servere.

En hybrid tilgang kombinerer det bedste fra begge. Kendte bot-brugeragenter, der matcher høj-tillid-mønstre, udløser synkron verifikation med cachede resultater, der tilføjer minimal latens. Lavere-tillid-mønstre udløser asynkron verifikation, hvilket tillader den første anmodning gennem, mens verifikationen køres i baggrunden. Denne trin-for-trin-tilgang optimerer for det almindelige tilfælde, mens kanttilfælde håndteres elegant. Middleware's position i anmodnings-pipelinen gør det til det ideelle sted at implementere denne logik, fordi det har adgang til alle de oplysninger, der er nødvendige for at træffe routings-beslutningen, og det udføres før nogen dyr applikationslogik.

Den Målbare Indvirkning af Blokering ved Døren

Resultaterne af implementering af bot-detektions-middleware er næsten øjeblikkeligt synlige i servermetrikker. Den mest dramatiske ændring er i båndbredde-forbrug. Falske crawlers anmoder om komplette HTML-sider, herunder alle de assets, der refereres til i responsen. Hver blokeret anmodning sparer den båndbredde, der ville være blevet brugt til at sende det fulde svar, som for indholdsrige sider kan være adskillige eller hundreder kilobyte pr. anmodning. I løbet af tusinder af blokerede anmodninger pr. time akkumuleres båndbreddesparingen til meningsfulde omkostningsreduktioner, især for applikationer, der hostes på udbydere, der opkræver pr. gigabyte overførsel.

CPU-udnyttelsen falder, fordi serveren ikke længere udfører PHP-kode, kører databaseforespørgsler og gengiver skabeloner for anmodninger, der ikke producerer værdi. Reduktionen er mest mærkbar under let tidsrum, når menneskelig trafik er lav, men bot-trafik forbliver konstant. Før implementering af middleware vedligeholdt serveren en baseline CPU-udnyttelse selv klokken tre om natten, fordi bots ikke sover. Efter implementering falder det let tidsrum tæt på nul, hvilket giver serveren hovedrum til legitim trafik under spidstider.

Svartiderne for legitime besøgende forbedres som en direkte følge af reduceret serverbelastning. En webserver, der håndterer fem hundrede anmodninger pr. sekund, tre hundrede af hvilke er falske bots, har mindre kapacitet til rådighed for de to hundrede rigtige besøgende end en server, der håndterer kun to hundrede anmodninger pr. sekund, som alle er legitime. Middleware spare ikke blot ressourcer på de blokerede anmodninger. Det forbedrer kvaliteten af service for hver anmodning, der passerer gennem, fordi serveren har mere kapacitet til rådighed for rigtigt arbejde.

Databasebelastningen falder proportionalt. Hvis applikationen forespørger databasen for hver sideanmodning, eliminerer blokering af tre hundrede falske anmodninger pr. sekund tre hundrede unødvendige databaseforespørgsler pr. sekund. For applikationer med komplekse forespørgsler eller begrænsede databaseforbindelser kan denne reduktion være forskellen mellem stabil drift og periodisk overbelastning. Middleware beskytter hele stakken, fra webserveren gennem applikationslaget til databasen, ved at stoppe uønsket trafik før den når nogen af dem.