Re: limit_req_zone, переменный rate

[Sergej Kandyla]

Maxim Dounin wrote:
>> 1) если стоит директива  limit_req_log_level notice;
>> то в error_log о limits не пишитеся вообще ничего.
>> (Linux 2.6.18-164.11.1.el5.028stab068.3  nginx/0.8.34)
>>     
>
> error_log при этом включён с каким уровнем логгирования?
>   
error_log        /var/log/nginx/error.log  notice;



>> Т.е. как видно на основе ответов курла и записей в error_log,
>> каждый последующий запрос обрабатывается в среднем на секунду
>> больше, чем предыдущий, по истечению моего burst=10,
>> получаю 503, что законно.
>>
>> каждый мой последующий запрос должен задерживаться на минуту
>> (согласно rate=1r/m) или N минут если это N запрос в пределах burst.
>> В принципе текущее поведение с задержкой на секунду сделано вполне
>> мудро, но вопрос в том, как оно на самом деле  должно
>> обрабатываеться.
>> Фича\баг ?
>>     
>
> Бага.  Чтобы получить описанный в доках CBR должно задерживаться 
> на (сейчас в корзине) / rate, по факту задерживается на (сейчас в 
> корзине).
>
> Впрочем, мне лично всегда казалось вообще неправильным пытаться 
> задерживать запросы.  Возможности для DoS'а это только 
> увеличивает.  Гораздо правильнее использовать описанный в доках 
> nodelay.
>
>   
это верно,
я его и использую для обычных клиентов ;)

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

да и  burst без nodelay по сути будет являться  неким backlogом для бекенда,
и может использоваться чтобы лимитировать нагрузку на бекенд.

Ведь если ботнет ломанется на сервак, и будет слать по пачке запросов с 
каждого айпишника
раз в несколько минут - то  delay тут как нельзя лучше. (дальше 
скриптами анализируем
error и access log на предмет агресивных ботов - и блокируем на уровне 
nginx, а лучше firewall)

А для обычных клиентов - nodelay, определенно.

Благо, делить клиентов, как оказалось, совсем не так сложно, спасибо вам!