[РЕШЕНО] Вебсервер: логика маршрутизации

[V1KT0P]

Я в другой теме форума написал запрос о поиске подобной проги. Пока только SoapUI предложили. С ней может тогда попробую разобраться. Мне собственно пока хватило бы, чтобы сервер просто досили, а я бы смотрел ответное поведение. Самого себя досить тоже не свят-свят. А купишь сервер, начнёшь "развлекаться" - улыбки от местных админов не жди ))

Вот с ходу нашел тему: http://habrahabr.ru/post/116056/. Там и про OWASP HTTP POST Tool, и SYN flood. И детальное описание.

[alexis031182]

Вот с ходу нашел тему: http://habrahabr.ru/post/116056/. Там и про OWASP HTTP POST Tool, и SYN flood. И детальное описание.

Очень интересно, спасибо

[alexis031182]

Ну вроде не так плохо у меня в случае с этой атакой. Трэд не создаётся, пока запрос не будет сформирован полностью. Единственное, может быть стоит в файл по примеру nginx записывать недопринятые запросы, чтобы в памяти не висели. Хоть и небольшой там размер, но всё же. И конечно нужно добавить слежку за "тормозными" соединениями.

[V1KT0P]

Ну вроде не так плохо у меня в случае с этой атакой. Трэд не создаётся, пока запрос не будет сформирован полностью. Единственное, может быть стоит в файл по примеру nginx записывать недопринятые запросы, чтобы в памяти не висели. Хоть и небольшой там размер, но всё же. И конечно нужно добавить слежку за "тормозными" соединениями.

Тогда сделай очень много запросов(тут важно с нескольких компов или с линукса с увеличинным количеством сокетных дескрипторов). Если у тебя сервер на винде, то достаточно скоро сокетные дескрипторы закончатся =).

[alexis031182]

Тогда сделай очень много запросов(тут важно с нескольких компов или с линукса с увеличинным количеством сокетных дескрипторов).

Да, обязательно проведу тест и отпишусь о результате. Я сделал голословный вывод в общем-то, то есть пока без реальной проверки, т.к. в атаке там именно POST-запрос используется. Думаю поддержку его завтра сделать на сервере. Завтра же и попробую завалить.

Если у тебя сервер на винде, то достаточно скоро сокетные дескрипторы закончатся =).

Комп на линуксе. У меня скорее проблема в отсутствии виндовса для тестов ))

[fuCtor]

Сервер который разрабатываете больше похож на сервер приложения, читай бэкэнд. Он не должен быть супер пупер устойчивым с DoS, главное чтобы работал стабильно, не поедал ресурсы и выполнял свою задачу. Общение с миром задача фронтенда, в частности толи это кеширующий прокси, либо балансировщики по типу nginx/haproxy. Каждый должен заниться своей задачей.

По поводу apache и nginx, в апаче есть методы для отдачи статики, отдает он ее нормально. НО до некоторого количества запросов в секунду, дальше дают о себе знать архитектурные особенности, заложенные еще в самом начале. У данных продуктов абсолютно разные модели работы, если у nginx не создает под каждый запрос поток, а старается по максмуму работать асинхронно (чтение/запись в сокеты/файла), то Apache наоборот пораждает много потоков, как результат большое потребление ресурсов и накладные расходы. Поэтому его сейчас использую в качестве сервера приложений.

Почему рекомендовал посмотреть на архитектуру Ruby/Python фреймворков, т.к. по сути они запускают сервера приложений (Webrick, Thin, Mongrel, Unicord и тд) и их ВСЕГДА прячут за балансировщиком, т.к. их главная задача динамика, со статикой справятся другие.

К примеру у меня сервис (для работы) крутящийся на приличном железе выдает в динамике 6000 RPS (1000 запросов 500 конкурентных). При этом загрузка увеличивается лишь процентов на 10. Всю балансировку на себя берет Nginx, в том числе отбой лишних запросов.

ЗЫ и главный вопрос, закладываете ли основу для горизонтального масштабирования? Без него сложнее сайта визитки/портфолио и тп делать не стал бы, а для данного решения главная ниша это различные HTTP сервисы, а тут вопрос масштабирования очень остро стоит.

[alexis031182]

Сервер который разрабатываете больше похож на сервер приложения, читай бэкэнд. Он не должен быть супер пупер устойчивым с DoS, главное чтобы работал стабильно, не поедал ресурсы и выполнял свою задачу. Общение с миром задача фронтенда, в частности толи это кеширующий прокси, либо балансировщики по типу nginx/haproxy. Каждый должен заниться своей задачей.

Пока получается симбиоз фронта и тыла. С одной стороны идея проекта соответствует серверу приложений. С другой - принцип обработки поступающих запросов близок фронту.

По поводу apache и nginx, в апаче есть методы для отдачи статики, отдает он ее нормально. НО до некоторого количества запросов в секунду, дальше дают о себе знать архитектурные особенности, заложенные еще в самом начале. У данных продуктов абсолютно разные модели работы, если у nginx не создает под каждый запрос поток, а старается по максмуму работать асинхронно (чтение/запись в сокеты/файла), то Apache наоборот пораждает много потоков, как результат большое потребление ресурсов и накладные расходы. Поэтому его сейчас использую в качестве сервера приложений.

Стадия обработки поступающих запросов в моём проекте получается ближе именно к nginx. Парсинг данных каждого запроса выполняется асинхронно в главном потоке приложения. Отдельный поток создаётся только в случае полной уверенности в корректности запроса. Разница с nginx получается в том, что последний транслирует запрос бэкэнду, в то время как у меня дальнейшая обработка осуществляется тем же процессом (но в отдельном потоке, конечно). Разница с Апачем заключается в том, что я не создаю отдельных процессов на запросы, работаю с потоками в едином адресном пространстве. Это уменьшает накладные расходы, но делает сервер менее устойчивым в случае, например, возникновения segmentation fault в любом из подключенных в роли плагинов сайтов (можно сказать даже абсолютно неустойчивым, и налагает соответствующую ответственность на разработчика плагина сайта). Кстати, если предполагается использовать лишь один сайт, то его код можно внедрить непосредственно в код сервера и не использовать никаких плагинов вообще. Это, по идее, поспособствует ещё большему снижению накладных расходов.

Почему рекомендовал посмотреть на архитектуру Ruby/Python фреймворков, т.к. по сути они запускают сервера приложений (Webrick, Thin, Mongrel, Unicord и тд) и их ВСЕГДА прячут за балансировщиком, т.к. их главная задача динамика, со статикой справятся другие.

К примеру у меня сервис (для работы) крутящийся на приличном железе выдает в динамике 6000 RPS (1000 запросов 500 конкурентных). При этом загрузка увеличивается лишь процентов на 10. Всю балансировку на себя берет Nginx, в том числе отбой лишних запросов.

Другими словами, заморачиваться с анализом на предмет зловредства slow post atack и ddos не стоит, правильно я понимаю?

ЗЫ и главный вопрос, закладываете ли основу для горизонтального масштабирования? Без него сложнее сайта визитки/портфолио и тп делать не стал бы, а для данного решения главная ниша это различные HTTP сервисы, а тут вопрос масштабирования очень остро стоит.

Считаю эту задачу обязательной к разрешению. Одного сервера недостаточно в случае реализации серьёзного вебпроекта. Мне бы хотелось, если это возможно, услышать Ваши рекомендации по данной теме. Со своей стороны приведу следующие рассуждения.

В вопросе с горизонтальным масштабированием необходимо разделить вычисления (другими словами формирование страниц сайтов) и отдачу статики. Действительно, это разные задачи со своими особенностями в процессе исполнения, которые мешать в кучу не следует. Я был не прав, признаю. В случае со статикой масштабирование может производиться при помощи фронта и использования сетевых файловых систем. Иными словами, эту часть вопроса можно закрыть при помощи сторонних по отношению к вебсерверу средств. Таким образом, следует обратить внимание именно на динамику, задачу реализации которой можно развести на три составляющие:

• база данных;
• текущие данные о работе пользователя (например, сессии);
• необходимость использования сторонних ресурсов.

Первый пункт может быть закрыт средствами самого сервера БД. Наверное все популярные БД поддерживают репликацию. Некоторые могут быть объединены в кластер. Однако это не обязательно, и распределение данных на разные сервера БД можно производить непосредственно плагином сайта. Плюсы и минусы обоих решений оставлю за кадром, лишь подчеркну, что оба метода поддерживаются проектом вебсервера по определению.

Над вторым пунктом мне необходимо подумать. Здесь можно использовать как и сторонний сервис, например, memcache, так и собственную реализацию взаимодействия между различными instance вебсервера, разнесёнными на разные хосты. Может быть имеет смысл реализовать поддержку обоих методов. Возможно, у Вас есть собственные соображения на этот счёт.

Третий пункт частично связан со вторым пунктом. Здесь подразумевается возможность плагина сайта подключаться к любому другому сервису в сети (да хоть к самому же вебсерверу по HTTP ) для осуществления каких-либо вычислений, необходимых ему при формировании конечного результата своей работы. Тут как бы получается, что данная возможность тоже по определению поддерживается, поскольку вебсервер никоим образом не ограничивает плагины сайтов в их собственных мытарствах.

Таким образом, задача поддержки вебсервером горизонтального масштабирования в моём случае сводится ко второму пункту.

[alexis031182]

Подключил POST-запрос. Напишите, пожалуйста, кто может протестить мой сервер через slow post atack. По этой ссылке можно скачать прогу юного хакера: http://habrahabr.ru/post/116056/

У себя запускаю - открывается максимум 4000 соединений с копейками. Видимо ограничения какие-то срабатывают в системе. Пробовал в /etc/security/limits менять значение до 100000 на hard и soft. Вроде ставится, но всё равно больше 4000 соединений не создаётся, больше - операционка напрочь вырубает сервер. Это наверняка настраивается как-то, но я не стал вдаваться в подробности пока.

На 4000 соединениях вебсервер пашет без проблем (и это при том, что я через внешний адрес сам к себе подключаюсь).

[alexis031182]

Возникла идея защиты от fast ддоса (традиционного, в противовес slow). Например, если детектится подозрительная активность с какого-либо хоста, то автоматом вносится соответствующая запись в настройки файервола, и нехороший бот банится, не успев навредить.

Правда, это решение также автоматом выносит приложение из разряда кроссплатформенных. С виндовсом я знаком очень плохо, и там мне такое не реализовать точно. Впрочем, виндовс-вебсервер лично для меня нонсенс

В проект добавил сжатие контента через deflate и gzip (в планах sdch, и не знаю, стоит ли добавлять compress). Также добавил функционал по раздаче контента частями (Content-Range). Надо будет заняться вплотную документацией (http://78.81.31.38/html/index.html). Пожалуй сайт первый сделаю о проекте вебсервера и прямо на нём же, как у WT

[V1KT0P]

Традиционный это когда весь канал забивают мусором. Ну будешь ты отсекать этот мусор, но ведь мало кто через него пробьется к тебе из реальных пользователей.

[alexis031182]

Традиционный это когда весь канал забивают мусором. Ну будешь ты отсекать этот мусор, но ведь мало кто через него пробьется к тебе из реальных пользователей.

На уровне файервола по конкретному айпишнику пресекать доступ. Запросы с этого хоста не дойдут до приложения, а всем остальным - пожалуйста.

[V1KT0P]

На уровне файервола по конкретному айпишнику пресекать доступ. Запросы с этого хоста не дойдут до приложения, а всем остальным - пожалуйста.

Мы говорим о разных вещах. То что отсекаются боты для предотвращения загрузки процессора это понятно. Но допустим у тебя канал в 100 Мб/с, тебе боты шлют запросы с скоростью 200 Мб/с. В результате канал забивается и нормальные пользователи не могут послать запрос к тебе, ибо и так канал перегружен. Да единицы может и достучатся в течении продолжительного времени, но это будут именно единицы. Так что есть еще куда расти =).

[alexis031182]

Мы говорим о разных вещах. То что отсекаются боты для предотвращения загрузки процессора это понятно. Но допустим у тебя канал в 100 Мб/с, тебе боты шлют запросы с скоростью 200 Мб/с. В результате канал забивается и нормальные пользователи не могут послать запрос к тебе, ибо и так канал перегружен. Да единицы может и достучатся в течении продолжительного времени, но это будут именно единицы.

Мне это известно, и я не заявлял о 100% защите. Да, завалят (как и любой другой вебпрокси), но чтобы завалить вебсервер с э-э-э... таким активным файерволом (назовём это так) потребуется гораздо больше ресурсов, нежели чем без него. Мне кажется, что резон тут имеется.

Так что есть еще куда расти =).

Есть более интересные идеи?

[V1KT0P]

Есть более интересные идеи?

Если есть несколько серверов, то можно какую-нибудь схему придумать =).

[alexis031182]

Если есть несколько серверов, то можно какую-нибудь схему придумать =).

Это да, масштабирование хорошая вещь. Но если есть возможность делать на одной машине то, для чего в другой ситуации потребуется две или даже несколько, то по идее отказываться от такого варианта не гут. Да и не противоречит "активный" файервол связкам. А очень хорошо дополняет. Другое дело, что наверное тогда это решение стоит вынести в отдельное приложение, и дать вебсерверу возможность им управлять. Или пусть самостоятельным будет полностью. Но тогда проще взять готовое.