> И на основании ж чего такой вывод? На каждый сокет требуется энный
> размер памяти - загнётся что угодно, не только nginx.Только в случае апача требуется еще и куча памяти на сами процессы апача и загибон наступает намного быстрее. Если меряться буферами сокетов - мощный сервант ваш нетбук переспорит на раз и успешная атака потребует кучу оборудования (==стоит дорого). А вот если там еще и апачовые процессы будут память жрать то единственный вшивый нетбук спокойно завалит многопроцессорный xeon пнув воркеров по максимуму и узурпировав их.
>> отрастает на входе нжинкс почему-то.
> У пионерских сайтов, подвергающихся пионерским досам. Fixed.
Ну да, конечно, только у вас сайты не пионерские. А вот у всех остальных - пионеры. Особенно если не по вашему делают.
>> В случае с апачем ее жрач кардинально больший - на форки процессов.
> Логично. Но сути это не меняет.
Это меняет затраты атакующего на атаку. Если в одном случае ему хватит чуть ли не мобильника с GPRS, во втором ему надо ставить уже парк серверов примерно равный по мощности тому что у конторы чтобы просто ощутимо затормозить это, т.к. буфера сокетов на обоих концах линка примерно одинаково жрутся. Гуглить про "усиление атаки". Вот апач дает некислое плечо атакующему, позволяя валить мощные сервера с всякой ерунды. Откровенная такая атака на ресурсы с большим плечом получается.
> проблемы с размером хедеров, либо выделяем большой буфер, и имеем хороший
> такой жрач по памяти на запрос.
А нефиг слать большие хидеры. Ну нет у легитимного клиента валидного повода так делать, а проблемы ботов волнуют только ботов. За такое вообще сразу банан и пусть бот/хаксор отдыхает.
>> сие и на клиенте жрется
> Не-а. Клиент может вообще не использовать буферы - в случае DoS ему
> поддержание псевдо-соединения нужно только до момента отправки запроса.
На этот момент он должен помнить о соединении и держать под него буфера, etc. Более того, если совсем не забирать данные из соединение и не трекать его, со стороны сервера можно довольно оперативно давить такое по таймауту, просто установив его достаточно скромным.
> После того, как запрос ушел, сервер взялся за работу. Против таких гавриков
> неплохо помогает небуферизованная отправка первого пакета с хедерами перед
> какой-либо тяжелой обработкой динамики.
Ну спасибо тебе кэп. Обычно при пионерской атаке гаврик начинает просто неспешно качать твои 300 кб простыни на скорости 1Кб/сек. Это просто, делается типовыми утилями и требует минимум и ресурсов и мозгов. А вот на 1 свой буфер сокета такой гаврик займет 1 воркер апача + некую память под буфер сокета на сервере. И озадачивая собой воркера на 5 минут. А если 1000 воркеров так форкануть - сервер чудно сколлапсирует, или потому что память на серваке кончается, или потому что все воркеры заняты обслуживанием хакера на ближайшие 5 минут. Ну а юзер зайдя на сайт и так и сяк получает таймаут и отползает восвояси. Цель атами достигнута - сайт недоступен :). А машине состояние пофиг. Ну висит 1000 малоактивных соединений - и пусть висит. Она вообще на них дергается лишь когда состояние меняется.
>> Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс
>> свистка воткнуть кластер за несколько десятков килобаксов не вопрос
> Кластеры делаются из-за тяжелой динамики, а не "для защиты". Для защиты ставятся
> фронтенды с рядом модулей. А чаще - вообще аппаратные решения на периметр.
Ну да, ну да. А у юзеров нжинксы один сраный 10-баксовый вдсник выдерживает хабраслэшдотэффекты если сделано с умом. Во сколько раз затраты бабла отличаются - сами посчитаете.
