Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Борьба с нарушителями одно го коннекта.
- To: Anton Kuznetsov <nginx-ru@xxxxxxxxx>
- Subject: Re: Борьба с нарушителями одно го коннекта.
- From: Gena Makhomed <gmm@xxxxxxxxx>
- Date: Mon, 16 Mar 2009 21:52:11 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=csdoc.com; s=dkim; t=1237233185; bh=PTN3SoRRFy/lLrFSbD9Oz+8D4uq+r+aFpzVe/PfVuoc=; h=Date:From:X-Mailer:X-Priority:Message-ID:To:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kt9ThElCX6HB1gyPAXKyUSaSfkFalprayWw6StJJlXFXjs+2CYTY+3moYb1fMxoBm tv4Yod5xsMu9W5XSHO2jfOjA6r/V/eduyrxn/RMfHk7JHlSWbLcb9IB2QuhBHGBq4wq uQ8F0jMg7SyfzQblG87e88gQxY14CBp/FH++isA=
- In-reply-to: <91818af80903150638l73a3677clf25524ad03fb92ba@xxxxxxxxxxxxxx>
- References: <91818af80903150638l73a3677clf25524ad03fb92ba@xxxxxxxxxxxxxx>
On Sunday, March 15, 2009 at 15:38:55, Anton Kuznetsov wrote:
AK> Многие здесь, как и я, занимаются раздачей больших файлов, этому
AK> занятию как правило сопутствует настройка limit_conn one 1;
AK> чтобы диски совсем не порвало.
AK> Следствие этой настройки - постоянная долбежка сервера
AK> паразитными коннектами. Эдакая DDOS атака от настроенных по
AK> умолчанию в 5-10 конектов "Download Master" & etc... Сложно
AK> сказать о вреде, но если смотеть в лог куда сливается 503 -
AK> то при моих нагузках становится страшно. Лог наверно вообще надо
AK> отключить, но это отдельный вопрос. У меня при 1к-1,5к полезных
AK> коннектов, 2к-3к - паразитных и это если еще по башке стучать и
AK> заставлять читать правила настройки качалок. Вопрос в том, как
AK> минимизировать вред от этого явления. Я до этого момента честно
AK> занимался баном - 50 попаданий в лог-503 - правило в ipfw на
AK> день-неделю и чувство жалости давно атрофировалось. Качают те, кто
AK> умеют настраивать. Но... жалко по прежнему сервер, ему даже и так
AK> плохо. Чистый эксперимент показал что включение pf без правил на
AK> сервере при скорости 500 мегабит добавляют процессу "irq30: em0"
AK> (top -S) сразу добрых 20%, а этот процесс у меня и без этого близок к 100 %.
AK> Сейчас я отключил ipfw & pf и пробую тихо игнорировать эту
AK> долбежку на самом nginx - вопрос как это лучше делать?
AK> Сейчас у меня стоит location = /503.html {limit_rate 1 ;}
AK> Но меня гложут смутные сомнения - хорошо ли nginx-у
AK> каждую секунду думать о том как в 2к-3к соединений отдать по байту?
AK> Вторая напасть похоже некоторые качалки (помню такое было
AK> в reget) не любят когда коннект отдает им слишком медленно
AK> и делают реконнект. Может я не прав, но в логе основная масса
AK> строчек "HTTP/1.0 503 0" - вроде как вообще не удалось ничего отдать,
AK> хотя время выполнения этих запросов солидное - в среднем более 100 секунд.
AK> Можно придумать что-то еще более легкое и эффективное или отключить лог и
забыть?
я бы сделал так:
1. если не больше N паразитных коннектов к серверу с какого-то ip
за определенный промежуток времени - просто возвращал бы 503 ответ.
2. при превышении этого лимита - возможно return 444 - качалка ведь всеравно
сделает retry через 60 секунд вне зависимости от того, получила она в ответ
503 или просто произошел обрыв соединения, - а серверу от этого будет легче.
"нестандартный код 444 закрывает соединение без передачи заголовка ответа."
http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.html#return
3. если какие-то качалки будут совсем часто долбиться, например,
больше K запросов за определенный период времени - тогда можно
будет вместо запрашиваемого файла отдавать редирект на мелкий файл
в котором будут описаны правила работы с сервисом - не более 1 потока
скачивания для каждого файла с одного ip. - "DOS атака" сразу прекратится.
при уменьшении частоты запросов - fallback до уровня 2, а потом и до уровня 1.
PS возможно будет лучше, если ограничиться только п.2 или только п.3 после п.1.
PPS но это всё workaround`ы, solution`ом тут может быть
наверное только использование протокола BitTorrent.
--
Best regards,
Gena
|