alexander пишет:
Привет.
Трафик стал сильно хаваться. Это был syn-flooding на мой веб-сервак.
При этом dmesg выдал картинко:
[30942.485594] possible SYN flooding on port 80. Sending cookies.
[30951.969322] TCPv6: Possible SYN flooding on port 80. Sending cookies.
[30960.029739] TCPv6: Possible SYN flooding on port 80. Sending cookies.
[30966.058466] TCPv6: Possible SYN flooding on port 80. Sending cookies.
[31003.499854] possible SYN flooding on port 80. Sending cookies.
Я тут добавил директивы limit для сервака, а потом вдруг возникла идея
nginx. Почитал как его хвалят. Если он такой хороший, то что его не
используют многие для своих нужд, например debian.org? :( Есть ли смысл
ставить nginx? Поможет ли он уменьшить syn-flooding и вообще нагрузку
на сервер?
Смысл syn-flood атаки:
На порт сервиса, который нужно повалить, отсылается syn-пакет. TCP-стек
, в уверенности, что это начало нового соединения, выделяет в памяти
место, отсылает в ответ ask и ждет какое-то время стабилизации
соединения. То есть обработка каждого syn-пакета требует некоторых
ресурсов. Навалить много syn-пакетов - ресурсов в системе может не
хватить. Навалить syn-пакетов с разных адресов - не поможет ничто.
Поэтому от synflood защиты на уровне приложения нет. Надо крутить
параметры ядра (google в помощь,
http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks)
Нагрузку на сервер nginx может уменьшить. Например, некоторый запрос
обрабатывается апачем (который требует N ресурсов) за n секунд.
Результат отдается клиенту за m секунд. Если m>>n (например, канал у
клиента плохой; пусть m=n*3) . Тогда для обработки этого запроса+отдача
клиенту требуется N*n*3 ресурсов. Если между толстым апачем и клиентом
есть тонкий прокси (nginx), требующий P ресурсов - тогда на 1 запрос
потребуется N*n+P*m ресурсов. Выгодно это или нет - надо смотреть.. Если
нет запросов, которые дооолго выполняются - nginx может и не помочь
(теоретически).
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
