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

[Maxim Dounin]

Hello!

On Fri, Dec 16, 2011 at 08:08:32PM +0400, Михаил Монашёв wrote:

[...]

> > Совсем  без  блокировок  -  не  обойтись,  т.к.  там  обход дерева в
> > разделяемой  памяти,  и  потом ещё и обновление нескольких значений.
> > Без  блокировок  будет не просто неточно, а в лучшем случае - просто
> > мусор, в худшем - segmentation fault.
> 
> Это  говорит  о  том,  что  используемый  алгоритм плохо подходит. Как

Нет, это лишь говорит о том, что без блокировок в этом месте не 
обойтись.

> вариант  его  латания  могу  предложить сделать вместо одного дерева -
> тысячу  деревьев.  С  однозначным отображением значения зоны в одно из
> деревьев.  И  блокировки  соответственно  ставить  на каждое отдельное
> дерево,  а  не  на  весь  лес.  Тогда  вероятность ожидания блокировки
> приблизится к нулю и их можно будет держать дольше, чем обычно.
> 
> Число  деревье  фиксировано.  Счётчик  для  каждого дерева находится в
> заранее  известной  ячейке  памяти  и  потому  менять  его  можно  без
> блокировок.

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

> > p.s. Ты вот лучше кейсов накидай - как ты будешь использовать 
> > несколько одновременных limit_req, когда они будут?
> 
> Накидал бы уже давно, если б использовал limit_req. От ботов отбиваюсь
> почти-realtime  анализом  логов. Ну может использовал бы для борьбы со
> спам-ботами,  когда  они  через прокси или из левых страны лезут. Ещё,
> было  б  интересно блокировать тех, кто ходит по одним локейшнам, а по

[...]

> Ещё  сейчас в голову пришла мысль сделать модуль для борьбы с мусорным
> трафиком.  Очень  приближённо схема такая. Задаётся так же переменная,

[...]

Ну вот limit_req - это один из простых модулей для борьбы с DoS'ом и 
всякими переборами паролей, расчитанный на то, чтобы работать "из 
коробки" с минимальными затратами на конфигурирование.

Понятно, что "в идеале" нужна гораздо более сложная логика по 
детектированию и предотвращению мусорного трафика, но это a) за 
рамками задач этого модуля и б) в сложных случаях, боюсь, всё 
равно не поможет, т.к. до nginx'а просто не дойдёт трафик.

Maxim Dounin