ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tuning FreeBSD 7.2 amd64 for high load nginx web server.



23.12.2009 12:23, Anton Yuzhaninov wrote:
Михаил Монашёв wrote:

                listen          83.222.4.74:80 default accept_filter=httpready 
rcvbuf=4096 sndbuf=131072;

Как сдесь уже неоднократно обсуждалось accept_filter довольно спорная вещь при
наличии nginx. С одной стороны коннекция в ядре дешевле коннекции в ядре. С
другой стороны коннекцией nginx легче управлять (обрывать по таймуту).

Соединения, которые не прошли accept_filter могут висеть долго, возможно вечно.

в случае dataready это соединения в которых получено 0 байт?
Т. е. если есть accept_filter то DDoS-ер можно подключаться и слать запрос по
одному байту в 10 минут. В итоге его коннекция будет очень долго висеть на
сервере и кушать его ресурсы (т. е. атакующий может просто открыть
kern.ipc.maxsockets коннекция и расходуя мало трафика их поддерживать 
открытыми).

если коннект не проходит accept_filter, у которого лимит backlog( *1.5 ?), то он там висит вечно или до тех пор пока не вытеснится новым коннектом по превышении размера backlog'а? В любом случае не вижу, как это связано с maxsockets, если accept()'а ещё не было. А если коннект прошёл accept_filter и случился accept, то таймауты nginx'а вступают в игру.
Если accept_filter нет, то nginx просто закроет такое соединение когда истечет
таймаут client_header_timeout (который в условиях DoS можно сделать небольшим).



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


 




Copyright © Lexa Software, 1996-2009.