Отбил небольшой DDOS ;)
DDOS на HTTP 20 Мбит входящего. Отбито софтварным костылем
Конфигурация машины: Quad Core Xeon / 4G RAM, CentOS 5.3 x86_64
Сервисы: apache(back) + nginx(front)
DDOS на HTTP 20 Мбит входящего. Отбито софтварным костылем
Конфигурация машины: Quad Core Xeon / 4G RAM, CentOS 5.3 x86_64
Сервисы: apache(back) + nginx(front)
Возможно эта статья ниочем, подумал я. Но тут намедни вопросы появились насчет разделения front-back отдачи контента. И я понял что есть еще люди…
И они всегда будут. А значит есть о чем написать.
Все знают наш любимый и почитаемый веб сервер Apache. К сожалению время его сделало до такой степени “навороченым”, что порой поражаешься сколько памяти и ресурсов вообще он может кушать на довольно простых задачах. И иногда сервер просто не справляется с нагрузкой (в основном не хватает памяти).
Нужно констатировать факт – Apache совершенно неэкономно расходует память при отдаче статического контента (картинки, HTML файлы, стили и т.д. – любой контент, который не содержит в себе серверного кода).
Благо есть с чем сравнить. Уже давно появился легкий веб-сервер Nginx. Он написан изначально оптимизированным под отдачу статики и, в сравнении с Apache, совершенно не расходует память. И везде, где только можно кусок памяти временно скинуть на диск, он это делает не выедая лишних системных ресурсов.
Но Nginx не содержит каких либо модулей для обработки динамического контента (кроме SSI). Он может только “проксировать” (передавать) обработку контента “бекенду” – собранному на заднем плане обработчику динамики Apache (или любому другом веб серверу). Так же Nginx умеет общаться с Fast-CGI сервером на бекенде.
Я не раз сцеплялся в админских обсуждениях на тему нецелесообразности PHP-FastCGI. Споров много, реальных данных мало. Замечу сразу, да, я лицо заинтересованное. Но подтасовкой не занимался и в ходе теста, три раза готов был признать свою ошибку
Немного теории. Я вообще не знаю, почему все FastCGI реализации PHP носят префикс “Fast”. Ведь Fast-CGI это целый интерфейс работы скрипта, под него нужно оптимизировать скрипты, чтобы получить его достоинства. Но мало того что этого никто не делает, для этого в PHP вообще не существует никаких интерфейсов. Ну на эту тему можно почитать статью: почему FastCGI не ускоряет PHP
Я решил сравнить апач с широкоизвестным fpm менеджером. В плане производительности.
Мне довольно часто достают какие то боты непонятной природы, которые как саранча быстро наваливаются на сервер, качают все что можно в сотни потоков и так же быстро исчезают.
Решил написать простенькую банилку. Обращаю внимание, банилка простенькая, в качестве БД используется MySQL – не рекомендуется как защита от DDoS атак. Возможно позже переведу ее на Berkeley DB.
Платформа: Nginx + ipfw + MySQL + свой скрипт. Впрочем, подойдет любой другой веб сервер, который умеет выборочно писать логи, например, apache+mod_setenv_if
Работает? Не трогай!