Re: Реализация multiple limit_req

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Dec 14, 2011 at 07:39:19PM +0400, Валентин Бартенев wrote:

> On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote:
> > Давай для начала распишем последствия обычного "последовательного"
> > применения лимитов, чтобы было понятно что так нельзя.  Или,
> > наоборот, можно, но с какими ограничениями.
> > 
> > Что касается принципа, то он мне не нравится: нам либо нужно всё
> > это делать держа локи (deadlock expected), либо имеем race между
> > проверкой и обновлением (и, опять же, локи придётся брать два
> > раза, что тоже не очень хорошо).
> > 
> 
> В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд,
> всё можно сделать по тому же принципу.

В limit_conn они второй раз берутся, когда мы откатываем лимиты - 
либо по завершению запроса, либо по наступанию на лимит.  И race'а 
там соответственно нет.

> Опять же, всё упирается в то, хотим ли мы считать отклоненные запросы или
> не хотим.
> 
> "Счёт" только еще можно разделить на два уровня:
>  - обновление времени последнего запроса;
>  - увеличение очереди.
> 
> Если мы будем просто последовательно проверять лимиты до первого
> срабатывания, то у нас получается ситуация, когда "иссякший" лимит
> стоящий на втором месте будет работать достаточно странно, имея
> причудливую зависимость от предшествующих.

Это понятно, и именно эти "странности" я и предлагаю 
проиллюстрировать на конкретных примерах, чтобы сомнений не 
оставалось.

E.g. типичная ситуация для хостинга, когда лимиты хочется на 
каждый $host (чтобы один атакуемый сайт не мог съесть все 
ресурсы), и на ip (чтобы с одного ip-адреса, вздремнув на ^R, 
нельзя было съесть все ресурсы):

   limit_req <per-host>;
   limit_req <per-ip>;

Если атакуют $host, то всё хорошо.

Если ^R, то проблема: легко "выедается" лимит на $host (хотя 
запросы реально не обслуживаются), и тем самым нужный хост 
фактически блокируется.

В данном конкретном случае - проблема легко решается сменой 
порядка применения лимитов: сначала per-ip, потом per-host.

Вопрос: есть ли в реальной жизни задачи, где проблема так *не*  
решается?

(С теоретической точки зрения - понятно, что такие задачи есть.  
Интересуют сколько-нибудь относящиеся к реальной жизни примеры.)

> Странность заключается в том, что запросы будут отклоняться, когда
> предшествующие вообще не сработали, и не отклоняться, если предшествующие
> сработали на задержание. Иными словами, меньший rate по предшествующим
> лимитам будет приводить к более суровым мерам.

Вот как раз в примере выше - подобное поведение вполне нормально, 
при условии правильного порядка лимитов.  Мы хотим пускать людей 
на сайт, пока не превышен лимит на этот сайт, и мы хотим отсекать 
людей с ^R, чтобы они вообще никому никаких проблем не доставляли.  
Т.е. конструкция

    limit_req <per-ip>;
    limit_req <per-host>;

не должна никак считать в per-host лимит запросы, отклонённые на основании 
"ip-адресом не вышел".  И в то же время должна считать суммарный 
лимит для хоста, и отклонять при необходимости запросы за него 
выходящие.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru