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

[alexis031182]

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

Нет, монетизировать не буду. В конце-концов ничего оригинального я не придумал. Отправлю исходники по запросу, если будет у кого интерес. Однако сам использовать для своих сайтов буду точно... ну конечно, если будет резон. Пока наблюдаю, что резон есть. Впрочем, всё равно надо доделать, чтобы можно было полноценные сайты писать (пока даже POST-запроса нету ).

[fuCtor]

Проще всего для этого использовать nginx, он для этого и создавался.

Статику мой сервер отдаст прекрасно и без nginx. Дополнительная прослойка не нужна в данном случае. Это больше для Апача актуально, где множество предварительных "настроечных" действий выполняется, прежде чем возникнет решение об отдаче.

Спасибо

Какая модель работы с подключениями? Не будет ли такого что встав на одном запросе повесятся все, или начнется утечка ресурсов.

По поводу что отдавать, то при любом раскладе первым проверяется существования запрашиваемого как файла на диске, иначе идет в обработчик. Как пример можно посмотреть на фреймворки на Ruby/Python, они будут ближе по идеологии к тому что пытаетесь реализовать. Ну и конечно посматривать на существующее. Например http://www.webtoolkit.eu/

PS а скорость в 20мс это многовато. В идеале должно укладываться в до 5мс.

[alexis031182]

Какая модель работы с подключениями? Не будет ли такого что встав на одном запросе повесятся все, или начнется утечка ресурсов.

Сокеты "живут" в главном потоке, но под каждый запрос (http request) создаётся отдельная нитка. Кол-во ниток устанавливается в конфигурационном файле приложения (по умолчанию QThread::idealThreadCount). Если кол-во работающих ниток достигают установленного максимума, то новые запросы помещаются в очередь и уже их нитки будут созданы и запущены при завершении работы предыдущих.

Нитки, конечно, независимы, но не настолько, как процессы. Я сознательно иду на это. Проще говоря, мой проект не предполагает использование одного instance сервера разными людьми (концепция: один владелец множества сайтов), поэтому, если сервер "рухнет" по вине одного из плагинов сайтов, виновного разраба найти будет легко

По поводу что отдавать, то при любом раскладе первым проверяется существования запрашиваемого как файла на диске, иначе идет в обработчик.

Да, так и сделал. Но пожалуй сделаю и некоторые исключения. Например, для файлов favicon.ico и robots.txt

Как пример можно посмотреть на фреймворки на Ruby/Python, они будут ближе по идеологии к тому что пытаетесь реализовать.

К сожалению, плохо знаком с этими языками. PHP знаю, но он просто достал.

Ну и конечно посматривать на существующее. Например http://www.webtoolkit.eu/

Да, да, эта библиотека у меня в закладках. В своём проекте я не хочу ограничивать разраба сайта никакими правилами. Лишь минимальный интерфейс взаимодействия с сервером и всё. Не нужно определять заранее никаких виджетов, поскольку вебмастерам, зачастую, требуется уникальность в этом вопросе, начиная от внешнего вида и заканчивая поведением.

PS а скорость в 20мс это многовато. В идеале должно укладываться в до 5мс.

Пока 1 мс. А там, посмотрим.

[V1KT0P]

Пока 1 мс. А там, посмотрим.

Тут вот почему тебе советуют фронтэнд поставить:
1) Представь себе что к тебе подключились 100 медленных клиентов, запрос обработался 1 мс но 10 секунд отдается результат. В итоге у тебя 100 ниток висят мертвым грузом 10 секунд. В итоге тебе потребуется оптимизировать. Плюс еще получаешь кучу проблем с уязвимостями. Например такая уязвимость ддос: на одном компе с медленным каналом запускается программа которая генерирует подключения к серверу, делает запрос и ОЧЕНЬ МЕДЛЕННО получает этот запрос, в итоге у тебя начинает накапливаться очень много ниток, память расходуется и все сервер накрылся. Там еще куча всяких способов "нагнуть" сервер. А вот поставив nginx ты решаешь все эти проблемы моментально.
2) А теперь тоже что и п.1 но у тебя стоит фронтэнд nginx. подключаются 100 медленных клиентов, запрос обрабатывается за 1 мс, все 100 запросов сразу отдается nginx-у, твои ресурсы освобождаются а nginx специально заточен и потребляет минимум памяти и проц. времени и потихоньку отдает контент. Если происходит ддос путем медленного коннекта или любого другого то nginx тупо режет такое соединение.

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

[alexis031182]

V1KT0P, я с тобой согласен. nginx я бы обязательно поставил как фронтэнд к своему серверу, если бы планировал запускать на нём какой-нибудь сайт сейчас. Пока же, в этом нет необходимости, да и я планирую реализовать жёсткий временной контроль над временем работы каждой нитки, плюс выявление всяческих злодейств, какие только смогу описать. Насколько это получится/не получится - покажет время. nginx-же можно установить в любой момент, но мне хочется попытаться обойтись без него. К тому же ddos - это задача уже скорее сисадмина, нежели вебмастера. Никакой nginx не устоит против серьёзного ddos'а.

[V1KT0P]

К тому же ddos - это задача уже скорее сисадмина, нежели вебмастера. Никакой nginx не устоит против серьёзного ddos'а.

Дело в том что есть способы "положить" сервер с одного компа с каналом в 5-10 мегабит. Есть даже некоторые программы для этого, но они не используются по причине того что популярных веб-серверов несколько штук, все они писались грамотными специалистами и все уязвимости(даже гипотетические) закрыты. А вот тебе прийдется серьезно подумать над безопасностью.

[alexis031182]

Дело в том что есть способы "положить" сервер с одного компа с каналом в 5-10 мегабит. Есть даже некоторые программы для этого, но они не используются по причине того что популярных веб-серверов несколько штук, все они писались грамотными специалистами и все уязвимости(даже гипотетические) закрыты. А вот тебе прийдется серьезно подумать над безопасностью.

Могу с уверенностью утверждать, что на этих серверах уязвимости закрыты прежде всего не ПО вебсервера, а специально предназначенными для этого программами, действующими на пакетном уровне и на тот момент, когда данные эти ещё даже не отосланы приложению. Я не силён в сисадминстве, но именно с помощью таких анализаторов (или как их ещё назвать), сидящих может быть на одном (или сразу за) уровне файервола, знакомый админ отбивал ddos'ы. Да, какие-то общие оптимизации для вебсервера определённо необходимы, но это скорее традиционные меры безопасности... э-э-э... правила хорошего тона, что-ли. Некий лёгкий заслон, защищающий от "детей".

Почему разрабы Apache не занимаются такими вопросами, как отдача статики? С их-то финансированием могли бы и озадачиться (опять недавно мелькало в новостях об очередном спонсоре). Почему желательно использовать nginx с ним в паре? Ведь любая связка - это лишняя нагрузка, пусть и незначительная, но всё же. Однозначно запрос обрабатывался бы ещё быстрее, если бы функционал nginx был встроен в апач.

И безусловно, положить можно любой ресурс, но весь вопрос в адекватности затрат.

[V1KT0P]

Могу с уверенностью утверждать, что на этих серверах уязвимости закрыты прежде всего не ПО вебсервера, а специально предназначенными для этого программами, действующими на пакетном уровне и на тот момент, когда данные эти ещё даже не отосланы приложению. Я не силён в сисадминстве, но именно с помощью таких анализаторов (или как их ещё назвать), сидящих может быть на одном (или сразу за) уровне файервола, знакомый админ отбивал ddos'ы. Да, какие-то общие оптимизации для вебсервера определённо необходимы, но это скорее традиционные меры безопасности... э-э-э... правила хорошего тона, что-ли. Некий лёгкий заслон, защищающий от "детей".

Ну ну, вот попробуй хоты бы представить программу которая на пакетном уровне отслеживает что-то по протоколу https.

Почему разрабы Apache не занимаются такими вопросами, как отдача статики? С их-то финансированием могли бы и озадачиться (опять недавно мелькало в новостях об очередном спонсоре). Почему желательно использовать nginx с ним в паре? Ведь любая связка - это лишняя нагрузка, пусть и незначительная, но всё же. Однозначно запрос обрабатывался бы ещё быстрее, если бы функционал nginx был встроен в апач.

Вот тут ты неправ, как я выше приводил пример nginx как раз и уменьшает нагрузку на Apache. А мешать все в кучу тоже не стоит. Мало того что nginx и Apache можно в одно приложение скрестить, следуя твоей мысли можно пойти дальше и вообще в ядро ОС встроить это все =).
nginx почти всегда ставится для снижения нагрузки, а у тебя почему-то она только возрастает =).

И безусловно, положить можно любой ресурс, но весь вопрос в адекватности затрат.

Вот честно скажи у тебя сейчас стоит лимит на размер запроса и время запроса. Если я начну слать гигабайтные запросы и последние 10 мегабайт отдавать в течении часа что будет?

[alexis031182]

Ну ну, вот попробуй хоты бы представить программу которая на пакетном уровне отслеживает что-то по протоколу https.

А какая разница http, https или ещё какой высокоуровневый протокол, если речь идёт о пакетах. Насколько я понял из объяснений, анализируется что-куда-кому-зачем с учётом времени.

Вот тут ты неправ, как я выше приводил пример nginx как раз и уменьшает нагрузку на Apache.

Уменьшает конечно, потому что в Апаче нет кода для быстрой отдачи статики.

А мешать все в кучу тоже не стоит. Мало того что nginx и Apache можно в одно приложение скрестить, следуя твоей мысли можно пойти дальше и вообще в ядро ОС встроить это все =).

Мера - мудрость Вселенной Ну а вообще, такие ли уж принципиально разные Апач с nginx задачи выполняют?

nginx почти всегда ставится для снижения нагрузки, а у тебя почему-то она только возрастает =).

nginx висит отдельным процессом. Как ни крути, затраты на взаимодействие его с Апачем - имеются. Буде в Апаче код nginx встроен корректно, этих бы затрат не было. Другими словами, это мог бы быть программный слой, срабатывающий на статику и не грузящий дальнейший код в случае успеха, но внутри Апача. Вполне вероятно, что даже как dll-ка такой встроенный код работал бы быстрее.

Вот честно скажи у тебя сейчас стоит лимит на размер запроса и время запроса. Если я начну слать гигабайтные запросы и последние 10 мегабайт отдавать в течении часа что будет?

Сейчас у меня нет никаких лимитов. Я об этом написал чуть выше. Естественно грохнется сервер. И нет у меня никаких защитных программ на компе, т.к. desktop это обычный.

[V1KT0P]

А какая разница http, https или ещё какой высокоуровневый протокол, если речь идёт о пакетах. Насколько я понял из объяснений, анализируется что-куда-кому-зачем с учётом времени.

Разница в том что применяется шифрование =). Как минимум надо расшифровывать, значит нудна поддержка https. Тоесть из простого понемногу начинает получаться мутант =). Допустим посмотрим момент с "медленным доссом" пакеты идут от клиента на сервер, они ничего подозрительного не содержат. Но сервер все ждет пока получит последний пакет, а его все нет и нет. =). А защитная программа следит и видит что все правильно, клиент передает пакеты не превышая лимита =), а сервак понемногу погибает.

Уменьшает конечно, потому что в Апаче нет кода для быстрой отдачи статики.
 
Мера - мудрость Вселенной Ну а вообще, такие ли уж принципиально разные Апач с nginx задачи выполняют?
 
nginx висит отдельным процессом. Как ни крути, затраты на взаимодействие его с Апачем - имеются. Буде в Апаче код nginx встроен корректно, этих бы затрат не было. Другими словами, это мог бы быть программный слой, срабатывающий на статику и не грузящий дальнейший код в случае успеха, но внутри Апача. Вполне вероятно, что даже как dll-ка такой встроенный код работал бы быстрее.

Ну согласись там разработчики не идиоты =). Зачем им делать то что, раз есть уже готовое и бесплатное, к тому-же прекрасно справляется. И зачем им встраивать nginx, если они вдруг захотят использовать lighttpd, или еще какой-нибудь малоизвестный продукт =). Тут используется философия Unix-way каждой задаче своя программа. Что позволяет комбинировать программы между собой как-то: nginx+Apache, lighttpd+Apache, nginx+unicorn. Как видишь раздельные программы очень гибкие, а если начать писать библиотеки для каждого сервера, то это будет настоящий программистский ад.

Сейчас у меня нет никаких лимитов. Я об этом написал чуть выше. Естественно грохнется сервер. И нет у меня никаких защитных программ на компе, т.к. desktop это обычный.

Честно не слышал ни про какие специальные защитные программы для веб-серверов. Назови хотя-бы парочку. Везде обычно используется правильно настроенный nginx.

[alexis031182]

Разница в том что применяется шифрование =). Как минимум надо расшифровывать, значит нудна поддержка https. Тоесть из простого понемногу начинает получаться мутант =).

Зачем расшифровывать пакет? O_o В TCP пакете вся необходимая инфа имеется. Иначе как по твоему через роутеры зашифрованные данные шлются, расшировываются на лету что-ли?

Допустим посмотрим момент с "медленным доссом" пакеты идут от клиента на сервер, они ничего подозрительного не содержат. Но сервер все ждет пока получит последний пакет, а его все нет и нет. =). А защитная программа следит и видит что все правильно, клиент передает пакеты не превышая лимита =), а сервак понемногу погибает.

Я вроде написал выше, что контроль пакетов с учётом времени.

Ну согласись там разработчики не идиоты =). Зачем им делать то что, раз есть уже готовое и бесплатное, к тому-же прекрасно справляется.

Могло бы и лучше, к тому же nginx появился позже Апача. Есть спрос, возникло предложение. Почему разработчики Апача не стали уделять внимания этой проблеме - другой вопрос.

И зачем им встраивать nginx, если они вдруг захотят использовать lighttpd, или еще какой-нибудь малоизвестный продукт =). Тут используется философия Unix-way каждой задаче своя программа. Что позволяет комбинировать программы между собой как-то: nginx+Apache, lighttpd+Apache, nginx+unicorn. Как видишь раздельные программы очень гибкие, а если начать писать библиотеки для каждого сервера, то это будет настоящий программистский ад.

Если следовать философии Unix-way, то потребуется ещё и Апач поделить на пару десятков приложений и мелких утилит. А уж если в основе конструктор, то, как говорится, изволь быть последовательным.

Честно не слышал ни про какие специальные защитные программы для веб-серверов. Назови хотя-бы парочку. Везде обычно используется правильно настроенный nginx.

Назвать не могу, поскольку не занимаюсь этими вопросами. Беседа просто интересная, поэтому поддерживаю

Ну давай логически. Http и те, что рядышком - лишь одна из дверей, так ведь? А кто может заниматься сетевым стеком на уровне ядра системы, приоткрывая/закрывая эти самые двери? По идее файервол. Но его мало, поскольку он устанавливает правила безотносительно ко времени (если не ошибаюсь). Значит, это что-то с возможностями файервола, но опирающееся при анализе на временную величину. Можно погуглить. Могу точно сказать, что и на Хабре таковые вопросы мелькали. Даже сравнивали варианты, спорили, какой круче в защите от ddos'а. nginx там не фигурировал, он не для этого.

[V1KT0P]

Ладно давай продолжим дальше четко про фронтэнды и бэкэнды.

Если следовать философии Unix-way, то потребуется ещё и Апач поделить на пару десятков приложений и мелких утилит. А уж если в основе конструктор, то, как говорится, изволь быть последовательным.

Тут дело в том что у каждого сервера свои особенности и поэтому код из апача врятли можно было бы успешно использовать в том-же unicorn-е.
Дальше надо четко определить что фронэнд и что бэкэнд. Бэкэнд это сам веб-сервер, а фронтэнд это прокси-сервер для веб-серверов. Как видишь это разные категории и сделаны для разных целей. Один фронтэнд может обеспечивать работу сразу двух серверов, например Apache и unicorn. При чем они могут быть не на той-же машине а быть в локальной сети на разных. Можно пойти дальше, нужно увеличить производительность бэкенд сервера в 10 раз и очень быстро. Без проблем настраиваем фронтэнд и он распределяет нагрузку на 10 машин в локальной сети, на каждой запущен свой экземпляр Apache.
Ты не думай что nginx сделан только для быстрой отдачи статики, он еще умеет кешировать, распределять нагрузку, всякие фильтры, обеспечивает поддержку SSL(то-есть бэкенд не обязан знать что работает по шифрованному каналу, да он и не узнает).
Как видишь nginx не так прост как тебе кажется =). Вот понадобится тебе использовать SSL в своем сервере, а с nginx всего-то надо настройки изменить, и в коде сервера менять не надо.

[alexis031182]

Ладно давай продолжим дальше четко про фронтэнды и бэкэнды.

Хорошо.

Тут дело в том что у каждого сервера свои особенности и поэтому код из апача врятли можно было бы успешно использовать в том-же unicorn-е.
Дальше надо четко определить что фронэнд и что бэкэнд. Бэкэнд это сам веб-сервер, а фронтэнд это прокси-сервер для веб-серверов. Как видишь это разные категории и сделаны для разных целей. Один фронтэнд может обеспечивать работу сразу двух серверов, например Apache и unicorn. При чем они могут быть не на той-же машине а быть в локальной сети на разных. Можно пойти дальше, нужно увеличить производительность бэкенд сервера в 10 раз и очень быстро. Без проблем настраиваем фронтэнд и он распределяет нагрузку на 10 машин в локальной сети, на каждой запущен свой экземпляр Apache.

Про это не подумал, честно. Тогда конечно ты абсолютно прав. Деление имеет смысл.

Ты не думай что nginx сделан только для быстрой отдачи статики, он еще умеет кешировать, распределять нагрузку, всякие фильтры, обеспечивает поддержку SSL(то-есть бэкенд не обязан знать что работает по шифрованному каналу, да он и не узнает).
Как видишь nginx не так прост как тебе кажется =). Вот понадобится тебе использовать SSL в своем сервере, а с nginx всего-то надо настройки изменить, и в коде сервера менять не надо.

У меня и разрабов nginx разные весовые категории. Разумеется, что всё, что есть в nginx, я не смогу всецело реализовать у себя. Да и попросту не нужно это мне. На эту тёмную сторону мой академический интерес не распространяется. Однако, без зазрения совести установлю фронтом nginx, если будет резон.

З.Ы. V1KT0P, можно будет тебя попросить потестить сервер, когда я защитный функционал нацеплю? В боевых условиях оно лучше видно, где в очередной раз накосячил. Ну и конечно при отрицательных результатах теста оставлю тогда идею реализации собственной защиты, если окажется, что ничего толкового предложить не могу.

[V1KT0P]

З.Ы. V1KT0P, можно будет тебя попросить потестить сервер, когда я защитный функционал нацеплю? В боевых условиях оно лучше видно, где в очередной раз накосячил. Ну и конечно при отрицательных результатах теста оставлю тогда идею реализации собственной защиты, если окажется, что ничего толкового предложить не могу.

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

[alexis031182]

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