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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru