Борьба с нарушителями одного коннекта.

[Anton Kuznetsov]

Добрый день!

Многие здесь, как и я, занимаются раздачей больших файлов, этому занятию как
правило сопутствует настройка limit_conn one 1; чтобы диски совсем не
порвало.
Следствие этой настройки - постоянная долбежка сервера паразитными
коннектами. Эдакая DDOS атака от настроенных по умолчанию в 5-10 конектов
"Download Master" & etc... Сложно сказать о вреде, но если смотеть в лог
куда сливается 503 - то при моих нагузках становится страшно. Лог наверно
вообще надо отключить, но это отдельный вопрос. У меня при 1к-1,5к полезных
коннектов, 2к-3к - паразитных и это если еще по башке стучать и заставлять
читать правила настройки качалок. Вопрос в том, как минимизировать вред от
этого явления. Я до этого момента честно занимался баном - 50 попаданий в
лог-503 - правило в ipfw на день-неделю и чувство жалости давно
атрофировалось. Качают те, кто умеют настраивать. Но... жалко по прежнему
сервер, ему даже и так плохо. Чистый эксперимент показал что включение pf
без правил на сервере при скорости 500 мегабит добавляют процессу "irq30:
em0" (top -S) сразу добрых 20%, а этот процесс у меня и без этого близок к
100%.
Сейчас я отключил ipfw & pf и пробую тихо игнорировать эту долбежку на самом
nginx - вопрос как это лучше делать? Сейчас у меня стоит
location = /503.html {limit_rate 1 ;} Но меня гложут смутные сомнения -
хорошо ли nginx-у каждую секунду думать о том как в 2к-3к соединений отдать
по байту?
Вторая напасть похоже некоторые качалки (помню такое было в reget) не любят
когда коннект отдает им слишком медленно и делают реконнект. Может я не
прав, но в логе основная масса строчек "HTTP/1.0  503 0" - вроде как вообще
не удалось ничего отдать, хотя время выполнения этих запросов солидное - в
среднем более 100 секунд.
Можно придумать что-то еще более легкое и эффективное или отключить лог и
забыть?


-- 
Best regards,
Anton Kuznetsov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090315/cf65825a/attachment.html>