Сървърен Middleware, Който Спира Фалшивите Краулери Преди Да Достигнат Приложението Ви

Тръбопроводът на заявки в уеб приложение е елегантен процес. Заявката пристига на уеб сървъра, преминава през стек от middleware компоненти, достига контролер и връща отговор. Всеки middleware в стека има възможност да инспектира заявката, модифицира я, предава я по-нататък или я отхвърля напълно. Тази архитектура е идеална за внедряване на открояване на ботове, защото проверката се случва преди заявката да докосне любой код на приложението. Фалшив краулер, твърдящ че е Googlebot, се идентифицира и блокира в middleware слоя, и контролерът дори не знае че заявката е съществувала. Няма загубени CPU цикли за рендериране на страница. Няма изпълнени SQL заявки. Няма попълнени запомнени записи. Фалшивият бот е спран на вратата, а ресурсите на сървъра, които биха fueron потребени, се запазват за легитимни посетители.

Мотивацията за построяване на този middleware дошла от конкретен и скъп проблем. Голямо приложение консумира мрежова честина и ресурси на сървъра в темпове, които не съответстват на действителната си базата потребители. Логовете на достъп разкриха огромни обеми от заявки от потребителски агенти, претендиращи че са Googlebot, Bingbot и различни други легитимни краулери. Проверката потвърди че мнозинството от тях бяха фалшиви, идвайки от облачни хостинг доставчици вместо от търсачките, които те твърдяха че представляват. Всяка фалшива заявка консумира същите ресурси на сървъра като истинска: същото PHP време на изпълнение, същите SQL заявки, същото разпределение на паметта, същата мрежова честина за отговора. Умножено по хиляди фалшиви заявки на час, цената беше значителна. Решението с middleware беше разработено за елиминиране на това разхищение чрез хващане на фалшивите краулери преди те да консумират какъвто и да е ресурс на приложението.

Внедряването следва ясна схема, която всеки backend разработчик може да адаптира. Middleware пресичат всяка входяща заявка, проверяват дали текстът на потребителския агент съответства на известен модел на краулер на търсачка, и ако това е случаят, проверяват IP адреса на заявката спрямо известната инфраструктура на краулера с използване на API за открояване на ботове. Заявки, които твърдяват че са краулери, но не успяват верификацията, се блокират с отговор 403. Заявки, които преминават верификацията или които не твърдяват че са краулери, продължават през стека на middleware нормално. Цялата проверка добавя минимална закъснение, защото резултатите от верификацията се кешират по IP адрес, което означава че всеки уникален IP се проверява само веднъж.

Логиката на Решението Зад Блокирането на Middleware Слоя

Избирането на блокиране на middleware слоя вместо на уеб сървърния слой (Nginx или Apache) или на слоя на приложението (в контролери) е умишлено архитектурно решение със специфични компромиси. Блокирането на уеб сървърния слой е най-ефективният вариант по отношение на консумацията на ресурси, защото заявката никога не достига PHP. Но конфигурацията на уеб сървърния слой за открояване на ботове обикновено включва статични списъци за блокиране на IP адреси или просто съпоставяне на потребителски агенти, нито един от които не предоставя динамичната, управлявана през API, верификация необходима за точно разпознаване на истинските краулери от фалшивите. Поддържане на статичен списък с милиони IP адреси е непрактично, а съпоставянето само на потребителските агенти не може да проверят самоличност, защото потребителските агенти са тривиално подправяни.

Блокирането на слоя на приложението, в контролери или класове от сервиси, е най-гъвкавият вариант, но най-малко ефективен. Когато заявката достигне контролер, стека на middleware вече е изпълнен, маршрутът е разрешен и потенциално скъпи операции като инициализиране на сесия и автентикация вече се случили. Блокирането в този момент спестява времето на изпълнение на контролера, но разхищва всичко което се случи преди него. За уеб приложения с висок трафик, където фалшивите заявки на ботове номерирани в хиляди на час, това разхищено предварително процесиране се натрупва.

Middleware слоя седи на оптималната точка в тръбопровода. Той се изпълнява преди обработката на сесията, преди автентикацията, преди middleware специфично за маршрута, и разбира се преди логиката на контролера. Но има достъп до пълния обект на заявката, включително заглавки, IP адреси и параметри на заявката, което означава че може да извърши софистицирана логика на верификация вместо просто съпоставяне на шаблони. Middleware могат да повикат външни API, кешират резултати, прилагат условна логика базирана на твърдяната самоличност и логват резултатите на верификация за анализ. Това съчетание от ефективност и гъвкавост прави middleware естественият дом за открояване на ботове в уеб приложение.

Стратегията на кеширане е особено важна за производителността. Без кеширане, всяка заявка от твърдян краулер ще изискваше API повикване за верификация на IP адреса. Дори със бърза API, това щеше да добави закъснение към всяка заявка. Решението е кеширане на резултатите от верификацията, ключувано по IP адрес, с времевизък живот от няколко часа или дори цял ден. Краулерите на търсачки работят от стабилни диапазони IP адреси, които се променят рядко, така че кеширан резултат от верификация остава валиден за разширени периоди. Когато заявка пристигне от твърдян Googlebot, middleware първо проверяват кеша. Ако IP адресът е бил проверен като легитимен в рамките на периода на кеша, заявката е позволена веднага. Ако IP адресът е бил проверен като фалшив, той е блокиран веднага. Само нови IP адреси изискват действително API повикване, и след това начално повикване, резултатът е служен от кеша при незначително закъснение.

Какво Се Случва с Заявките, Които Са Блокирани

Блокирането на фалшив краулер не е просто връщане на отговор 403 и приемане на случилото се. Решението за блокиране и контекстът му трябва да бъдат логирани за анализ. Всяка блокирана заявка представлява точка от данни за това кой се опитва да достъпи сайта, какво претендира че е, и откъде идва. През времето, този лог разкрива модели, които информират по-широки решения за сигурност. Может би специфична ASN е отговорна за непропорционален дял от фалшивите краулери. Може би фалшивите заявки на Googlebot скокват в определени времена на ден. Може би специфична пътека на URL привлича повече фалшивите краулери от други, предполагайки че ботовете целят конкретно съдържание.

Отговорът на блокирана заявка може също да бъде по-нюансиран отколкото пълен отговор 403. Някои внедрявания връщат 429 (Твърде много заявки) за маскиране на факта че ботът е идентифициран, правеики по-трудно за оператора на бота да коригира своя подход. Други връщат 200 с празно тяло, което разхищава минимална мрежова честина докато предотвратява ботът от познаване че е открит. По-агресивни подходи връщат 403 със съобщение указващо че верификацията на краулера е неудачна, което е прозрачно, но дава на операторите на ботове информация за механизма на открояване. Избирането зависи от философията на оператора на сайта относно прозрачност спрямо оперативна сигурност.

За ботове, които твърдяват че са краулери, но всъщност са легитимни услуги, които случайно използват текстове на потребителски агенти на краулер неправилно, блокирането може да бъде по-разрушително отколкото предполаганото. Някои SEO наблюдаващи инструменти, например, използват потребителски агенти подобни на Googlebot за симулиране на това как Google вижда страницата. Тези инструменти ще пропаднат верификацията, защото те не са Google, дори и техния намерение е легитимно от гледна точка на оператора на сайта. Middleware могат да вместят това чрез поддържане на списък на доверени IP диапазони за известни легитимни услуги на трета страна, или чрез прилагане на верификация само на специфични модели на потребителски агенти докато пропускат други. Гъвкавостта на middleware подхода позволява този вид нюансирана политика без изискване за промени на конфигурацията на уеб сървъра или кода на приложението.

Синхронна Спрямо Асинхронна Верификация

Въпросът дали да верифицирам ботовете синхронно или асинхронно засяга както ефективността на блокирането, така и влиянието на производителността на приложението. Синхронна верификация означава че middleware паузира заявката, повиква верификационната API, чака отговора и след това позволяват или блокират заявката базирана на резултата. Този подход обезпечава незабавно блокиране, но добавя закъснение към първата заявка от всеки IP адрес. С кеширане, закъснението засяга само първата заявка, но за уеб приложения с висок трафик дори това редко закъснение може да бъде неприемливо.

Асинхронна верификация следва различен подход. Първата заявка от нов IP адрес е позволена, докато верификационна работа е попълнена в гърба. Когато резултатът на верификацията се връща, той е кеширан, и всички следващи заявки от този IP адрес се обработват според резултата. Този подход добавя нула закъснение към тръбопровода на заявката, но позволява малко количество начални заявки от фалшивите ботове да преминат преди верификацията да завършват. За повечето приложения, този компромис е приемлив. Фалшив бот, който изпраща три заявки преди да бъде блокиран, е консумирал далеч по-малко ресурси отколкото един, който изпраща хиляди неимпедирани заявки.

Системата на изчаквания прави асинхронния подход прав. Middleware разпределят верификационна работа, която повиква API за открояване на ботове, съхраняват резултата в кеша, и незадължително активирват събитие, което други части на приложението могат да слушат. Работата се изпълнява в секунди, което означава че прозорецът, в който неверифицирана трафика на ботове може да преминат, е крайно тесен. За приложения използващи бърза памет кеш в памет, кеширания резултат е наличен на всички инстанции на приложението веднага, така че дори в разпределена среда, верификацията трябва да се случи само веднъж по IP адрес по всички сървъри.

Хибридния подход съчетава най-добрия на двете. Известни текстове на потребителски агенти на ботове, които съответстват на модели с висока уверност, активирват синхронна верификация с кеширани резултати, добавяйки минимално закъснение. Модели с по-нска уверност активирват асинхронна верификация, позволявайки първата заявка да преминат, докато верификацията се изпълнява в гърба. Този многослоен подход оптимизира за обичайния случай, докато обработва пограничните случаи благодатно. Позицията на middleware в тръбопровода на заявката го прави идеалното място за внедряване на тази логика, защото има достъп до всички информации необходима за направене на решението за маршрутиране и се изпълнява преди скъпа логика на приложението.

Измеримото Влияние на Блокирането на Вратата

Резултатите от внедряване на middleware за открояване на ботове са видими почти веднага в метриките на сървъра. Най-драматичната промяна е в консумацията на мрежова честина. Фалшивите краулери искат пълни HTML страници, включително всички активи, на които се позовава отговора. Всяка блокирана заявка спестява мрежовата честина, която щеше да се използва за предаване на пълния отговор, което за съдържание-тежки страници може да бъде десетки или стотици килобайта по заявка. Над хиляди блокирани заявки на час, спестяванията на мрежова честина натрупване в значителни спестявания на разходи, особено за приложения хоствани на доставчици, които таксират по гигабайт прехвърляне.

Utilizatiите на CPU пада, защото сървърът вече не изпълнява PHP код, изпълнява SQL заявки и рендира шаблони за заявки, които произвеждат никаква стойност. Намаляването е най-видимо в извънпиковите часове, когато човешкия трафик е нисък, но трафика на ботове остава постоянен. Преди внедряване на middleware, сървърът поддържа базово използване на CPU дори в три сутринта, защото ботовете не спят. След внедряване, извънпиковото използване пада към близо нула, давайки на сървърът място за легитимен трафик в пикови часове.

Времевата на отговор за легитимни посетители се подобрява като преки последица от намаленото натоварване на сървъра. Уеб сървър, обработвайки петстотин заявки в секунда, триста от които са фалшивите ботове, има по-малко капацитет наличен за двеста реални посетители отколкото сървър, който обработва само двеста заявки в секунда, всички от които са легитимни. Middleware не просто спестява ресурси на блокирани заявки. Той подобрява качеството на услуга за всяка заявка, която преминават, защото сървърът има по-много капацитет наличен за истинска работа.

Натоварването на базата данни намалява пропорционално. Ако приложението съобщава базата данни за всяка поисък на страница, блокирането триста фалшивих заявки в секунда елиминира триста ненужни заявки на база данни в секунда. За приложения със сложни заявки или ограничени връзки на базата данни, това намаление може да бъде разликата между стабилна работа и периодично претоварване. Middleware защитават целия стек, от уеб сървърния слой през слоя на приложението към базата данни, чрез спиране на нежеланата трафика преди да достигне някой от тях.