ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: борьба с ботами средствам и nginx


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: борьба с ботами средствам и nginx
  • From: Roman Hlynovskiy <roman.hlynovskiy@xxxxxxxxx>
  • Date: Mon, 16 Mar 2009 22:07:01 +0600
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nwZs2xYOg8DP/tfeCBx+XL6Nd12fGiQbdHaJt+Nj4DY=; b=dfCmLAsWnDqaPkT39eSlSjtA9xkY/I+UkHLEh7/UpmFRYYfS8g9j+z04Nis1VPNpmU hiQt54tcfYV+erzhaK2eBuoWHNcH/ak72CMi3/LcIhFpKtSNcjDATiwbGmW0allgoX5J wxbI8Yqzx1rBr9woKKZEZ+f0Lt6mXwZ3ayeHc=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=rotiNGfw+qh4OTOdPL0OEriGgaoGUGDNi7UxVAvVHURXkGszNweSejCp6rlt/3b+wt WjWruCdWmvLTs/vcj13/RK3vdAvlQkrOxsVrwW3sNIZWt0AKxC4C5tpmbS0ZgiZQDxm3 ydNc5vIgUQ5WYl//PwglxVJuu2JDrkCSa/09w=
  • In-reply-to: <a7cd64c30903160650t1d85242fj92b81f3c7e1fd73@xxxxxxxxxxxxxx>
  • References: <afa4ab8a0903160607m1403fc19hc4d61e8ccd411f61@xxxxxxxxxxxxxx> <a7cd64c30903160650t1d85242fj92b81f3c7e1fd73@xxxxxxxxxxxxxx>

добрый вечер,

речь как раз не о том, чтобы резать роботов совсем. это естественно
будет некорректным.
речь о том как ограничить воздействие ботов на систему шаред хостинга в целом.
исходя из моего опыта задача выставления планки загрузки системы в
условиях шаред хостинга достаточно тяжело осуществима. слишком много
параметров на которые нельзя влиять прямо. к, примеру тот-же mysql.

если я могу повлиять на то кто должен первым получить запрошенный
ресурс - обычный пользователь или бот, то я выберу первого, т.к.
второй имеет имеет свои собственные механизмы индексации и может
придти позже, а пользователь который открывает страничку рассчитывает
ее получить здесь и сейчас.

16 марта 2009 г. 19:50 пользователь Nikolay Grebnev <nick@xxxxxxxxxxxx> написал:
> Мне кажется что это некорректная постановка задачи.
> Роботы - это кормильцы. Резать их неправильно.
> Вам надо решать задачу с другой стороны - надо чтобы клиент имел некую
> планку по загрузке системы, и в ней уже мог извращаться как ему угодно. Если
> совсем никак то проще отказаться от клиента. Это и для него лучше.
> Уверен, что он заплатил за раскрутку( чтобы пришли роботы) во много десятков
> раз больше, чем за Ваш хостинг. И если Вы будете его резать, это неправильно
>
> 2009/3/16 Roman Hlynovskiy <roman.hlynovskiy@xxxxxxxxx>
>>
>> добрый день,
>>
>> а у кого какой опыт есть борьбы с поисковыми ботами средствами nginx?
>>
>> сегодня столкнулись с интересной проблемой - дурной клиент то-ли купил
>> сервис по seo-оптимизации, то-ли сам где-то научился, но его ресурс
>> обступили вкруговую поисковые боты.
>> одновременно 10-15 разных поисковых ботов начали активно индексировать
>> ресурс. все-бы ничего, но ресурс поднят на базе одного очень дурного
>> CMS разработчики которого видимо не в курсе что существуют понятия
>> индексов в БД.
>> в итоге получился небольшой DOS. сервер выдержал, но 'осадок' остался,
>> в виде очень нехороших iowait'ов.
>>
>> хотел-бы узнать кто-как решает подобные наплывы ботов у себя?
>> закрывать полностью ip-адреса ботов тоже не вариант, т.к. речь идет о
>> шаред хостинге.
>>
>> соответственно у меня возникло 2 различные идеи воплощения этой задачи;
>>
>> 1) разрешить только одному боту в одну единицу времени получать свой
>> честный 200, всем остальным - 503
>> 2) разрешить не более одного коннекта с одного ip-адреса при условии
>> что user_agent соответствует некому набору бот-шаблонов.
>>
>> попытался реализовать второй вариант через limit_conn следующим образом:
>>
>> http {
>>    limit_zone   bots  $binary_remote_addr  16m;
>>
>>   . . .
>>
>>   server {
>>
>>    if ($http_user_agent ~* "StackRambler|Yandex") {
>>    limit_conn bots 1;
>>   }
>>
>>
>>  }
>>
>> }
>>
>> на практике получил облом, т.к. limit_conn не может быть внутри if-а.
>> какие варианты тут могуть быть?
>>
>> реализовывал-ли кто-нибудь что-нибудь подобное первому варианту?
>> у меня вообще не приходят мысли как может выглядеть подобная конфигурация.
>>
>>
>> --
>> ...WBR, Roman Hlynovskiy
>
>



-- 
...WBR, Roman Hlynovskiy


 




Copyright © Lexa Software, 1996-2009.