Здравствуйте, Maxim.

>> Простите, что встреваю в Ваш разговор. Хочу заметить, что весьма
>> возможно очень многим людям подойдут не идеальные варианты, когда
>> при ограничении в 1000 запросов в минуту проскочит не ровно 1000, а
>> 1001 или даже 1002. Или наоборот, заблокирует 998 или 998-ый
>> запрос. Т.е. весьма вероятно, что исключительная точностью в
>> подобном вопросе востребована очень немногими, и потому возможно
>> сэкономить на блокировках и написать код, работающий не с
>> абсолютной точностью, но зато хорошо заточенный под недалёкое
>> будущее, когда количество ядер будет исчисляться сотнями. Саму же
>> небрежность в работе описать в документации, снабдив причинами,
>> почему выбрана именно такая реализация.

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

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

Число деревье фиксировано. Счётчик для каждого дерева находится в
заранее известной ячейке памяти и потому менять его можно без
блокировок.

> Maxim Dounin

> p.s. Ты вот лучше кейсов накидай - как ты будешь использовать
> несколько одновременных limit_req, когда они будут?

Накидал бы уже давно, если б использовал limit_req. От ботов отбиваюсь
почти-realtime анализом логов. Ну может использовал бы для борьбы со
спам-ботами, когда они через прокси или из левых страны лезут. Ещё,
было б интересно блокировать тех, кто ходит по одним локейшнам, а по
другим почему-то не ходит, хотя должен был бы. Или ходит по тем, по
которым обычный юзер не может пойти. Или приходит по HTTP/1.0 и
постоянно норовит зайти на страницу регистрации то с одного домена, то
с другого. В итоге всё это выливается в то, что находятся и
блокируются через ipfw подсети хостинг-провайдеров, где эти боты
живут. Ограничивать количество запросов по нескольким признакам имеет
смысл для доморощенных спамеров, которые с домашнего компа краулят или
спамят сайт. Ибо их блокировать по ip нельзя, а вот замедлить их или
ограничить количеством запросов хорошо бы.


В том nginx, который из коробки, не хватает твоих патчей для поддержки
директив
memcached_gzip_flag 2;
gunzip on;
set $memcached_namespace beon;

и в аптриме балансировщика
memcached_hash;

чтобы nginx с мемкешедом работал точно также как Perl. Ну и в
перспективе comet из коробки хотелось бы.

А если совсем помечтать, то DNS-сервер, аналог мемкешеда и простую БД
аля-mysql.

Ещё сейчас в голову пришла мысль сделать модуль для борьбы с мусорным
трафиком. Очень приближённо схема такая. Задаётся так же переменная,
как в limit_req_zone , которая состоит, например, из
uri+ip+user_agent+coockies или из всех http-заголовков+ip. Задаётся
зона, где будет храниться нейросеть. И две директивы: learn и protect.
Первая занимается обучением нейросети правильными запросами, вторая
дропает все запросы, похожие на мусор. Ну и хорошо бы периодически
сохранять обученную нейросеть на диск, чтобы при рестарте nginx не
учить её на трафике, который мог уже стать мусорным. Учить можно на
тех запросах, на которых успевает учиться, а не на всех. Модуль этот
можно и за деньги продавать, кстати. И саппорт к нему тоже за деньги,
если человеку сложно самому всё настроить. Это выгоднее, чем постоянно
платить сервисам защиты от DDOS. ИМХО, такой модуль вполне может убить
DDOS, как средство влияния на сайты.

--
С уважением,
Михаил mailto:postmaster@softsearch.ru

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