Palvelinvälimuistutus, joka pysäyttää väärennettyjä tiedustelijoita ennen sovellukseen saapumista

Verkkosovelluksen pyynnön käsittelyputki on kaunis asia. Pyyntö saapuu verkkopalvelimelle, kulkee välimuistutusten pinon läpi, saapuu ohjaimen luo ja palauttaa vastauksen. Pinon jokainen välimuistutus voi tarkastaa pyynnön, muokata sitä, välittää sen eteenpäin tai hylätä sen kokonaan. Tämä arkkitehtuuri on täydellinen tekoälyrobottien havaitsemiselle, koska vahvistus tapahtuu ennen kuin pyyntö koskettaa sovelluslogiikkaa. Väärä tiedustelijа, joka väittää olevansa Googlebot, tunnistetaan ja estetään välimuistutusten tasolla, eikä ohjain edes tiedä pyynnön olemassaolosta. Yhtään suorittimen sykliä ei tuhlata sivun renderöintiin. Yhtään tietokantahakua ei suoriteta. Yhtään välimuistin merkintää ei täytetä. Väärä robotti pysäytetään ovella, ja palvelimen resurssit, jotka olisivat kulutettu, säästetään laillisille vierailijoille.

Tämän välimuistutuksen rakentamisen motivaatio tuli konkreettisesta ja kalliista ongelmasta. Suuri sovellus kulutetti kaistanleveyttä ja palvelimen resursseja nopeuksilla, jotka eivät vastanneet sen todellista käyttäjäkantaa. Pääsylokit paljastivat valtavat määrät pyyntöjä käyttäjäagenteilta, jotka väittivät olevansa Googlebot, Bingbot ja muita oikeutettujen tiedustelijoiden nimiä. Tutkimuksessa vahvistettiin, että suurin osa näistä oli väärennettyä ja peräisin pilvipalvelun tarjoajilta sen sijaan että ne olisivat peräisin hakukoneista, joiden nimissä ne esiintyivät. Jokainen väärä pyyntö kulutti samat palvelimen resurssit kuin oikea: saman PHP-suoritusajan, samat tietokantakyselyn, saman muistinvarauksen, saman kaistanleveyden vastaukselle. Tuhansien väärennettyjä pyyntöjen kertaa tunti, hinta oli huomattava. Välimuistutusratkaisu suunniteltiin poistamaan tämä tuhlaus pysäyttämällä väärät tiedustelijat ennen kuin ne kuluttivat sovellusresursseja.

Toteutus noudattaa yksinkertaista mallia, jota kaikki palvelinpuolen kehittäjät voivat mukauttaa. Välimuistutus sieppaa jokaisen saapuvan pyynnön, tarkistaa, vastaako käyttäjäagentin merkkijono tunnetun hakukoneen tiedustelijoiden kaavaa, ja jos näin on, vahvistaa pyynnön IP-osoitteen tiedustelijoiden tunnetusta infrastruktuurista käyttämällä robotin havaitsemisen API:a. Pyynnöt, jotka väittävät olevansa tiedustelijoita mutta epäonnistuvat vahvistuksessa, estetään 403-vastauksella. Pyynnöt, jotka läpäisevät vahvistuksen tai jotka eivät väitä olevansa tiedustelijoita, jatkavat välimuistutuspinojen läpi normaalisti. Koko tarkistus lisää minimaalisen latenssin, koska vahvistustulokset välimuistiin tallennetaan IP-osoitetta kohden, mikä tarkoittaa, että jokainen ainutlaatuinen IP vahvistetaan vain kerran.

Välimuistutuksessa estämisen taustalla oleva päätösten logiikka

Päätös estää välimuistutuksessa palvelimen tasolla (Nginx tai Apache) tai sovellustasolla (ohjaimen sisällä) on tietoinen arkkitehtuurin valinta, jonka taustalla ovat erityiset kompromissit. Palvelimen tasolla estäminen on tehokkain vaihtoehto resurssien kulutuksen kannalta, koska pyyntö ei koskaan saavuta PHP:ta. Palvelimen konfigurointi robotin havaitsemiselle sisältää kuitenkin tavallisesti staattisia IP-mustia listoja tai yksinkertaista käyttäjäagentin vastaavuutta, eikä kumpikaan tarjoa dynaamista, API-ajamaa vahvistusta, joka tarvitaan todellisten tiedustelijoiden ja väärennösten välisen eron tekemiseen tarkasti. Miljoonien IP-osoitteiden staattisen mustan listan ylläpitäminen on käytännöllistä, ja käyttäjäagentin vastaavuus yksin ei voi vahvistaa identiteettiä, koska käyttäjäagentit ovat triviaalisti petettävissä.

Estäminen sovellustasolla, ohjaimen tai palveluluokkien sisällä, on joustavin vaihtoehto mutta tehoton. Siihen mennessä kun pyyntö saapuu ohjaimen luo, välimuistutuspiino on jo suoritettu, reitti on ratkaistu, ja mahdollisesti kalliit toiminnot, kuten istunnon alustus ja todennus, ovat jo tapahtuneet. Estäminen tässä pisteessä säästää ohjaimen suoritusaikaa, mutta tuhlaa kaiken, mikä tapahtui ennen sitä. Korkean liikenteen sovelluksissa, joissa väärät robotit pyyntöjen määrä on tuhansissa tunnissa, tämä tuhlattu esikäsittely lisääntyy.

Välimuistutus istuu optimaalisessa pisteessä putkilinjassa. Se suoritetaan ennen istunnon käsittelyä, ennen todennusta, ennen reittikohtaista välimuistutusta ja varmasti ennen mitään ohjaimien logiikkaa. Mutta sillä on pääsy täydelliseen pyynnön objektiin, mukaan lukien otsikot, IP-osoitteet ja kyselyparametrit, mikä tarkoittaa, että se voi suorittaa kehittynyttä vahvistuslogiikkaa yksinkertaisen mallintamisen sijaan. Välimuistutus voi kutsua ulkoista API:a, välimuistiin tuloksia, soveltaa ehdollista logiikkaa väitetyn henkilöllisyyden perusteella ja kirjata vahvistustulokset analyysiin. Tämä tehokkuuden ja joustavuuden yhdistelmä tekee välimuistutuksesta luonnollisen kodin robottien havaitsemiselle verkkosoveluksessa.

Välimuistutusstrategia on erityisen tärkeä suorituskyvylle. Ilman välimuistutusta jokainen väitetty tiedustelijoiden pyynnöstä vaatisi API-kutsu IP-osoitteen vahvistamiseksi. Jopa nopealla API:lla, tämä lisäisi viive jokaiseen pyyntöön. Ratkaisu on välimuistiin tallentaa vahvistustulokset IP-osoitteen perusteella avaimella, joiden TTL on useita tunteja tai jopa koko päivä. Hakukoneiden tiedustelijat toimivat vakailta IP-alueilta, jotka muuttuvat harvoin, joten välimuistissa oleva vahvistustulos pysyy kelvollisena pitkiä aikoja. Kun pyyntö saapuu väitetystä Googlebotista, välimuistutus ensin tarkistaa välimuistin. Jos IP vahvistettiin lailliseksi välimuistikaudella, pyyntö sallitaan välittömästi. Jos IP vahvistettiin väärennetyksi, se estetään välittömästi. Vain ensimmäisen kerran IP-osoitteet vaativat todellisen API-kutsu, ja sen jälkeen tulos palvellaan välimuistista merkityksettömällä latenssikululla.

Mitä tapahtuu estettyille pyynnöille

Väärän tiedustelijoiden estäminen ei ole vain 403-vastauksen antamista ja eteenpäin siirtymistä. Estämispäätös ja sen konteksti tulisi kirjata analyysille. Jokainen estetty pyyntö edustaa tietopistettä siitä, kuka yrittää käyttää sivustoa, mitä he väittävät olevansa ja mistä he ovat peräisin. Ajan myötä tämä loki paljastaa kaavoja, jotka ilmoittavat laajemmista tietoturvan päätöksistä. Ehkä tietty ASN on vastuussa suhteettoman suuren osan väärennösten tiedustelijoista. Ehkä väärennösten Googlebot-pyynnöt piikkivät tiettyinä aikoina päivää. Ehkä tietty URL-polku houkuttelee enemmän väärennösten tiedustelijoita kuin muut, mikä viittaa siihen, että robotit kohdistuvat tiettyyn sisältöön.

Vastaus estettyyn pyyntöön voi olla myös vivahteikkaampi kuin koko 403. Jotkut toteutukset palauttavat 429:n (liikaa pyyntöjä) peittääkseen sitä, että robotti on tunnistettu, mikä vaikeuttaa robotti-operaattorin lähestymistavan mukauttamista. Toiset palauttavat 200 tyhjällä rungolla, joka tuhlaa minimaalisen kaistanleveyden samalla kun robotit estävät sen tietämästä havaittavan. Aggressiivisemmät lähestymistavat palauttavat 403:n viestillä, joka ilmoittaa, että tiedustelijoiden vahvistus epäonnistui, mikä on läpinäkyvä mutta antaa robotti-operaattoreille tietoa havainnista. Valinta riippuu sivuston operaattorin filosofiasta läpinäkyvyyden ja toimintaturvallisuuden välillä.

Roboteille, jotka väittävät olevansa tiedustelijoita mutta ovat itse asiassa oikeutettujen palvelut, jotka käyttävät tiedustelijoiden kaltaisia käyttäjäagenteja väärin, estäminen voi olla häiritsevämpi kuin tarkoitus. Jotkut SEO-valvontavälineet käyttävät esimerkiksi Googlebot-kaltaisia käyttäjäagenteja simuloidakseen, kuinka Google näkee sivun. Nämä työkalut epäonnistuvat vahvistuksessa, koska ne eivät ole Google, vaikka niiden tarkoitus on laillinen sivuston operaattorin näkökulmasta. Välimuistutus voi mukauttaa tämän ylläpitämällä tunnettujen kolmansien osapuolten palvelujen IP-alueiden valkoista listaa, tai soveltamalla vahvistusta vain tiettyihin käyttäjäagentin kaavoihin ja sivuuttamalla muut. Välimuistutuskaavauksen joustavuus sallii tämän kaltaisen hienostutetun politiikan ilman muutoksia palvelimen konfiguraatioon tai sovelluskoodi.

Synkroninen ja asynkroninen vahvistus

Kysymys siitä, vahvistetaanko robotit synkronisesti vai asynkronisesti, vaikuttaa sekä estämisen tehokkuuteen että sovellukseen kohdistuvan suorituskykyvaikutukseen. Synkroninen vahvistus tarkoittaa, että välimuistutus keskeyttää pyynnön, kutsuu vahvistus-API:a, odottaa vastausta ja sallii tai estää pyynnön tulosten perusteella. Tämä lähestymistapa tarjoaa välittömän estämisen, mutta lisää viivettä jokaisen IP-osoitteen ensimmäisestä pyynnöstä. Välimuistutus, viive vaikuttaa vain ensimmäiseen pyyntöön, mutta korkean liikenteen sovelluksissa jopa tämä satunnainen viive voi olla hyväksymätön.

Asynkroninen vahvistus ottaa erilaisen lähestymistavan. Ensimmäinen pyyntö uudesta IP-osoitteesta sallitaan läpi, kun taas vahvistustyö jonon jonoon taustalla. Kun vahvistustulos tulee takaisin, se välimuistiin tallennetaan, ja kaikki seuraavat pyynnöt tästä IP-osoitteesta käsitellään tulosten mukaisesti. Tämä lähestymistapa lisää nollaa viivettä pyynnön putkilinjaan, mutta sallii pienen määrän alkuperäisiä pyyntöjä väärä roboteista kulkea läpi ennen vahvistusta. Suurimmille sovelluksille tämä kompromissi on hyväksyttävä. Väärä robotti, joka lähettää kolme pyyntöä ennen estämistä, on kuluttanut paljon vähemmän resursseja kuin yksi, joka lähettää tuhansia pyyntöjä estämättä.

Jonoitusjärjestelmä tekee asynkronisesta lähestymistavasta yksinkertaisen. Välimuistutus lähettää vahvistustyön, joka kutsuu robotin havaitsemisen API:a, tallentaa tuloksen välimuistiin ja valinnaisesti laukaista tapahtuman, johon sovelluksen muut osat voivat kuunnella. Työ suoritetaan sekunnissa, mikä tarkoittaa, että ikkuna, jona tarkistettu robotti-liikenne voi kulkea, on erittäin kapea. Sovelluksille, jotka käyttävät nopeaa muistissa välimuistia, välimuistissa oleva tulos on käytettävissä kaikille sovelluksen ilmentymille välittömästi, joten jopa kuormituksen tasapainottavissa ympäristöissä, vahvistus täytyy tapahtua vain kerran IP-osoitetta kohden kaikilla palvelimilla.

Hybridilähestymistapa yhdistää parhaat molemmista. Tunnettujen botilta käyttäjäagentit, jotka vastaavat korkean luottamuksen kaavoja, käynnistävät synkronisen vahvistuksen välimuistettujen tulosten kanssa, lisäämällä minimaalisen latenssin. Alemman luottamuksen kaavat käynnistävät asynkronisen vahvistuksen, mikä sallii ensimmäisen pyynnön läpi vahvistuksen ajon taustalla. Tämä tiered lähestymistapa optimoii yleisen tapauksen käsittelyssä samalla kun käsittelee reunatapauksia hyvin. Välimuistutuksen sijainti pyynnön putkilinjassa tekee siitä ihanteellisen paikan tämän logiikan toteuttamiselle, koska sillä on pääsy kaikkiin tietoihin, joita reitityspäätökseen tarvitaan ja suoritetaan ennen mitään kallista sovelluslogiikkaa.

Oven estämisen mitattavissa oleva vaikutus

Robotti-havaitsemisen välimuistutuksen toteuttamisen tulokset näkyvät lähes välittömästi palvelimen mittareissa. Dramaattisin muutos on kaistanleveyden kulutuksessa. Väärät tiedustelijat pyytävät täydellisiä HTML-sivuja, mukaan lukien kaikki vastauksessa viitatut varat. Jokainen estetty pyyntö säästää kaistanleveyttä, joka olisi käytetty koko vastauksen lähettämiseen, joka sisältöä raskaille sivuille voi olla kymmeniä tai satoja kilotavuja per pyyntö. Tuhansien estettyjen pyyntöjen poikki tunnissa, kaistanleveyden säästöt keräävät mielekkäiksi kustannussäästöiksi, erityisesti sovelluksille, jotka on isännöity palveluntarjoajilla, jotka veloittavat gigataavun siirtoa kohti.

CPU-käyttö laskee, koska palvelin ei enää suorita PHP-koodia, aja tietokantahakuja ja renderöi malleja pyynnoille, jotka eivät tuota arvoa. Vähennys on selkein huippuaikoja ulkopuolella, kun ihmisten liikenne on alhainen, mutta robotti-liikenne pysyy vakiona. Ennen välimuistutuksen toteuttamista, palvelin ylläpiti peruslinjaisen CPU-käytön jopa kolmessa yöllä, koska robotit eivät nuku. Toteutuksen jälkeen, huippuajan ulkopuolella käyttö laskee lähelle nolla, antaen palvelimelle liikkumavaraa laillisen liikenteen huippuajoille.

Laillisille vierailijoille vasteajat paranevat suoraan palvelimen kuormituksen vähenemisen seurauksena. Verkkopalvelin, joka käsittelee viisisataa pyyntöä sekunnissa, kolmesataa joista ovat väärä robotit, on vähemmän kapasiteettia saatavilla kahdelleSataelle todelliselle vierailijoille kuin palvelin, joka käsittelee vain kaksisataa pyyntöä sekunnissa, joista kaikki ovat oikeutettujakin. Välimuistutus ei vain säästä resursseja estettyjen pyyntöjen kanssa. Se parantaa jokaisen pyynnön palvelun laatua, joka kulkee sen läpi, koska palvelimella on enemmän kapasiteettia todellista työtä varten.

Tietokantakuormitus vähenee suhteellisesti. Jos sovellus kyselyt tietokannasta jokaisesta sivun pyynnöstä, kolmesadan väärä robotin pyynnön estäminen sekunnissa eliminoi kolmesataa tarpeetonta tietokantahakua sekunnissa. Sovelluksille, joilla on monimutkaisia kyselyjä tai rajallisia tietokantayhteyksiä, tämä vähennys voi olla ero vakaan toiminnan ja määräaikaisten ylikuormituksien välillä. Välimuistutus suojaa koko pinoa, verkkopalvelimesta sovelluskerrokseen tietokantaan, pysäyttämällä ei-toivotun liikenteen ennen kuin se saavuttaa mitään heistä.