|
Название: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 11:58 День добрый
Пишу Вебсервер. Знаю про велосипеды, но у меня чисто академический интерес, поэтому прошу воздержаться от соответствующих комментариев. К делу... Идея моего вебсервера исключает использование каких бы то ни было интерпретаторов на своей стороне (да, знаю, что это не ново). Сайты будут на С++, и будут подключаться (динамически) в виде плагинов. Конечно HTML и Javascript будут передаваться клиентам. Просто идея в замене того же PHP на C++. Резон - скорость. Однако тут имеется подводный камень, заключающийся в том, что, например, пыхпых так или иначе привязан к конкретным файлам скриптов, они... э-э-э... как точки входа. В случае же с C++ таковое не получается. Файлы, являющиеся точками входа не существуют. Их заменяет, по сути, вызов функции из динамически подключаемой библиотеки. Однако, файловые ресурсы всё же могут быть. Например, совершенно ни к чему хранить в файле-библиотеке (dll-ке) сайта картинки или видеоролики. Создатель сайта просто закидывает такие файлы в выделенную этому сайту папку и может быть уверен, что те будут переданы клиенту на его соответствующий запрос. Мой вопрос относится к той ситуации, когда запрос клиента может содержать указание на файловый ресурс (например "/favicon.ico", который непременно автоматом отсылается тем же Google Chrome), но такового файла в папке сайта может и не быть. И как тут лучше поступить? Выдать "Not Found"? Или передать запрос по цепочке от сервера сайту, и тот, мол, пусть сам разбирается с этой проблемой? Но тогда получается, что необходимо делегировать сайту права на выставление статуса ответа, поскольку уже автомат сайта сам может придти к выводу, что "Not Found" - лучший ответ. Корректно ли это решение? А может быть есть ещё какие-либо варианты поведения в рассмотренной ситуации? Название: Re: Вебсервер: логика маршрутизации Отправлено: Bepec от Май 01, 2012, 18:18 Делать то же самое, что делает и нормальный сервер. Выдать пустую картинку, если нет файла. Или ты хочешь что - то другое придумать? :D
Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 01, 2012, 18:31 Сайты будут на С++, и будут подключаться (динамически) в виде плагинов. Ты собираешься какой-то готовый C++ фреймворк использовать? Или что-то свое писать собрался?Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 18:33 Делать то же самое, что делает и нормальный сервер. Выдать пустую картинку, если нет файла. Или ты хочешь что - то другое придумать? :D Картинка - просто пример, с видеофайлом... э-э-э... выдать пустой видеофайл? :) Речь не об этом. Вопрос заключался в том, на чьей стороне (сервера или сайта-плагина) лучше, оптимальнее оформлять ответ на означенную ситуацию. Ведь может случиться, что сайт приемлет запросы на несуществующие ресурсы (файлы, страницы) за счёт заранее сформированных правил перенаправления (в Apache - это .htaccess). А может и не приемлет...Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 18:36 Ты собираешься какой-то готовый C++ фреймворк использовать? Или что-то свое писать собрался? Полностью своё, поскольку есть интерес именно с нуля. Знаю, что существуют подобные проекты (один даже где-то в закладках имеется), но не хочу тянуть в проект ничего другого, кроме Qt.Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 18:47 Да, если кому-нибудь нужно соответствия маймтипов файловым расширениям, то в аттаче приложил xml, собранные с апачевского mimetypes файла. Знаю, что парсится исходник легко, но может xml для собственных задач кому-нибудь сгодится
Название: Re: Вебсервер: логика маршрутизации Отправлено: Bepec от Май 01, 2012, 19:23 В любом случае будет идти запрос на сервер. В любом случае будет проверка. И тут уже вопрос третий - что выдавать вместо несуществующих.
А так по идее, конечно же сервер должен проверять и отдавать файлы. Хотя на вкус и цвет все шмели разные ;) Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 19:51 В любом случае будет идти запрос на сервер. В любом случае будет проверка. И тут уже вопрос третий - что выдавать вместо несуществующих. Вот я и подошёл к этому третьему моменту вплотную.А так по идее, конечно же сервер должен проверять и отдавать файлы. Хотя на вкус и цвет все шмели разные ;) Да, этому следую, но вопрос с несуществующими файлами пока нерешён у меня. Как определить, что запрос клиента указывает не на несуществующий файл на диске, а просто на динамически формируемую страницу? По наличию расширения файла в запросе? Тогда разработчику сайта придётся следовать негласному правилу, что динамически формируемые страницы не должны в своём наименовании выглядеть как наименования файлов... Другими словами символ точки содержать... Или типа того... Иначе до сайта запрос не дойдёт, сервер будет отсылать "404 Not Found". Какое-то левое правило, и очень хотелось бы извратиться как-нибудь по-другому.Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 01, 2012, 20:29 Да, этому следую, но вопрос с несуществующими файлами пока нерешён у меня. Как определить, что запрос клиента указывает не на несуществующий файл на диске, а просто на динамически формируемую страницу? По наличию расширения файла в запросе? Тогда разработчику сайта придётся следовать негласному правилу, что динамически формируемые страницы не должны в своём наименовании выглядеть как наименования файлов... Другими словами символ точки содержать... Или типа того... Иначе до сайта запрос не дойдёт, сервер будет отсылать "404 Not Found". Какое-то левое правило, и очень хотелось бы извратиться как-нибудь по-другому. Я не могу понять что тебя ставит в тупик? Твой сервер получает запрос, согласно своему правилу разбирает запрос и выполняет его. Тут проще пример привести. К примеру выполняется такой запрос: site.com/somequery для начала ищется файл в директории сайта и если не обнаруживается то передается на разбор в данном случае вычленяется somequery. Далее передается управление плагину который зарегистрировал запрос somequery. Если ни один плагин не регистрировал, то тупо 404 вощвращай. Если регистрировал то он и должен решать что возвращать.Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 20:50 Я не могу понять что тебя ставит в тупик? Твой сервер получает запрос, согласно своему правилу разбирает запрос и выполняет его. Тут проще пример привести. К примеру выполняется такой запрос: site.com/somequery для начала ищется файл в директории сайта и если не обнаруживается то передается на разбор в данном случае вычленяется somequery. Ну вот банальный пример с иконкой в Google Chrome:1. шлётся запрос "site.com/" - тут всё понятно, сайт, если в нём предусмотрен контроллер по умолчанию (а это как правило так и есть) корректно отработает. 2. тут же браузер автоматом шлёт второй запрос (может даже не дожидаться ответа на первый, стандартом это разрешено) "site.com/favicon.ico" - и вот что произойдёт в этом случае, если передать этот запрос сайту? Он его отработает также, как и первый запрос, то есть второй раз сработает контроллер по умолчанию, и будет снова отправлена, например, главная страница сайта. Это плохо. Конечно ситуацию эту на стороне сайта можно обойти. Написать там правила соответствующие, но мне бы хотелось именно на уровне сервера исключить подобное, чтобы создатель сайта не заморачивался по данной теме (вообще, по идее, его это не должно касаться). Далее передается управление плагину который зарегистрировал запрос somequery. У меня сайты не регистрируют ничего на сервере. Я стараюсь добиться минимума вариантов взаимодействия. Каждый запрос отправляется конкретному сайту. Определение соответствия производится от имени хоста. Просто в конфигурационном файле пишем, какие хосты/доменные имена "слушает" сайт.Если ни один плагин не регистрировал, то тупо 404 вощвращай. Если регистрировал то он и должен решать что возвращать. Вот здесь и получается, что если сервер ничего о внутренностях сайтов не знает (и это желательно сохранить), то обработку того, относится ли запрос к файлу или динамической странице становится определить проблематично. Если ничего не получится придумать, то наверное придётся на стороне сервера проверять, является ли запрос на файл (по наличию файлового расширения), и если нет, то отправлять запрос сайту.Название: Re: Вебсервер: логика маршрутизации Отправлено: Bepec от Май 01, 2012, 21:12 Ну как бе, насколько я знаю, стандарт состоит в хранении иконок /файлов и прочего в одном(паре) мест, для одного сайта.
Не вижу в этом ничего плохого. А далее стандартный разбор, как тебе говорит Виктор. PS у тебя сейчас вопрос стоит простой: Я хочу, чтобы клиент запрашивал о чём то сервер, а сервер, в свою очередь запрашивал плагины, а плагины в свою очередь запрашивали файл (мп3, ико, несуществующий фал, нужное подчеркнуть), а далее плагин отправлял серверу, а сервер отправлял клиенту. Не? :) Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 01, 2012, 21:34 Ну вот банальный пример с иконкой в Google Chrome: У тебя проблемы на ровном месте. К примеру ставим nginx как фронтенд, при site.com/favicon.ico если в директории есть иконка он ее возвращает если нету, то передает твоему серверу, твой сервер уже по твоим правилам решает что делать.1. шлётся запрос "site.com/" - тут всё понятно, сайт, если в нём предусмотрен контроллер по умолчанию (а это как правило так и есть) корректно отработает. 2. тут же браузер автоматом шлёт второй запрос (может даже не дожидаться ответа на первый, стандартом это разрешено) "site.com/favicon.ico" - и вот что произойдёт в этом случае, если передать этот запрос сайту? Он его отработает также, как и первый запрос, то есть второй раз сработает контроллер по умолчанию, и будет снова отправлена, например, главная страница сайта. Это плохо. Конечно ситуацию эту на стороне сайта можно обойти. Написать там правила соответствующие, но мне бы хотелось именно на уровне сервера исключить подобное, чтобы создатель сайта не заморачивался по данной теме (вообще, по идее, его это не должно касаться). У меня сайты не регистрируют ничего на сервере. Я стараюсь добиться минимума вариантов взаимодействия. Каждый запрос отправляется конкретному сайту. Определение соответствия производится от имени хоста. Просто в конфигурационном файле пишем, какие хосты/доменные имена "слушает" сайт. Ну вот конфигурационный файл и играет роль регистратора.Вот здесь и получается, что если сервер ничего о внутренностях сайтов не знает (и это желательно сохранить), то обработку того, относится ли запрос к файлу или динамической странице становится определить проблематично. Если ничего не получится придумать, то наверное придётся на стороне сервера проверять, является ли запрос на файл (по наличию файлового расширения), и если нет, то отправлять запрос сайту. Снова проблема на ровном месте. Если есть файл по указанному пути, то отдаем этот файл. Если нету то передает твоему серверу, если нет обработчика запроса то возвращаем 404, если обработчик есть то передаем ему. Если он решает что получил невалидный запрос то возвращает 404, если валидный то результат. В чем проблема-то?Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 21:39 Ну как бе, насколько я знаю, стандарт состоит в хранении иконок /файлов и прочего в одном(паре) мест, для одного сайта. Для каждого сайта всё индивидуально будет. Взять для аналогии всяческие PHP фреймворки. Картинки расположены как Бог пошлёт, и тот же Апач не ведает что к чему, пока очередной запрос не заставит его смотреть конкретные папки-файл на присутствие соответствующей картинки. У Апача нет проблемы в определении из запроса, что есть файл, а что - страница. Он работает исключительно с файлами (ну если только в .htaccess не начать писать перенаправления, но, правда, всё равно на файлы). У Апача например, если запрос касается PHP динамической страницы, всё равно точка входа файлом является. У меня же этого нет. Отсутствует чёткое определение, что есть файл на диске, а что есть страница.Не вижу в этом ничего плохого. А далее стандартный разбор, как тебе говорит Виктор. Повторная выдача одной и той же информации, причём запросом в данном конкретном случае с favicon.ico предусмотрено получение вполне конкретных данных, и вовсе не страницы. Это не очень хорошо.PS у тебя сейчас вопрос стоит простой: Нет. Вопрос в том, как сервер может отличить адрес файла от адреса динамически формируемой в плагине сайта страницы даже в том случае, если запрашиваемого файла не существует.Я хочу, чтобы клиент запрашивал о чём то сервер, а сервер, в свою очередь запрашивал плагины, а плагины в свою очередь запрашивали файл (мп3, ико, несуществующий фал, нужное подчеркнуть), а далее плагин отправлял серверу, а сервер отправлял клиенту. Не? :) Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 21:49 У тебя проблемы на ровном месте. К примеру ставим nginx как фронтенд, при site.com/favicon.ico если в директории есть иконка он ее возвращает если нету, то передает твоему серверу, твой сервер уже по твоим правилам решает что делать. Можно и так конечно, но этот вариант мне не нравится. Ради простейшей в общем-то ситуации...Ну вот конфигурационный файл и играет роль регистратора. Регистратора соответствия хостов сайтам - да. Но не запросов. Хост - составная часть в запросе.Снова проблема на ровном месте. Если есть файл по указанному пути, то отдаем этот файл. Если нету то передает твоему серверу, если нет обработчика запроса то возвращаем 404, если обработчик есть то передаем ему. Если он решает что получил невалидный запрос то возвращает 404, если валидный то результат. В чем проблема-то? То есть делегировать плагинам возможность устанавливать статус ответа? Этот вариант мне понятен, он вроде как сам собой напрашивается, но мне не хочется передавать таковые полномочия плагинам. В Апаче, вроде, этого нет. Заголовки там всякие - это пожалуйста, а вот статус... Да и ситуация с иконкой говорит о том, что могут возникнуть всяческие недоразумения, что приведёт к снижению производительности. То есть подобные вещи, по идее, не должны касаться сайта. Он там у себя колупается в своей песочнице, и не особо лезет на сервер. Это было бы гут.Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 22:06 Пожалуй остановлюсь на парсинге имени файла из запроса. Если имеется файловое расширение - значит файл. Если же нет - кидаю запрос плагину, который сформирует страницу. Конечно это наложит ограничение на имена страниц - они не должны будут точку содержать (например, site.com/documents/main.document). Из такого запроса сервер решит, что это файл на диске, а не страница. Ёк-королёк... а ещё ведь могут быть и динамически формируемые картинки (аналогия imagick на пыхпыхе). Тоже плохо :(
Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 01, 2012, 22:13 Можно и так конечно, но этот вариант мне не нравится. Ради простейшей в общем-то ситуации... Регистратора соответствия хостов сайтам - да. Но не запросов. Хост - составная часть в запросе. То есть делегировать плагинам возможность устанавливать статус ответа? Этот вариант мне понятен, он вроде как сам собой напрашивается, но мне не хочется передавать таковые полномочия плагинам. В Апаче, вроде, этого нет. Заголовки там всякие - это пожалуйста, а вот статус... Да и ситуация с иконкой говорит о том, что могут возникнуть всяческие недоразумения, что приведёт к снижению производительности. То есть подобные вещи, по идее, не должны касаться сайта. Он там у себя колупается в своей песочнице, и не особо лезет на сервер. Это было бы гут. Снова ты не понимаешь. Допустим запускается сервер. У сервера есть два плагина forumPlugin и newsPlugin. Каждый из них регистрирует обработчик.forumPlugin просто регистрирует forum. newsPlugin регистрирует регулярку которая проверяет что запрос имеет вид даты типа 2012/05/01. Далее рассмотри запросы: forum/thread_9000 Сервер сперва проверяет наличие обработчика forum, находит его и передает ему запрос thread_9000. Обработчик парсит его и получает thread и 9000. По логике первое значение это команда, в данном случае thread возвращает страницу с темой номер 9000. forum/post_100500 Тоже самое но возвращается страница показывающая только одно собщение номер 100500. forum/blabla Тоже самое но плагин не находит команду blabla. Если плагин не предусмотрел вывод сообщения о том что темы нет, то просто возращает серверу ошибку. Сервер уже разбирается что делать, то ли кидать на главную то-ли ошибку 404. Если же плагин предусмотрел ошибку то либо показ ошибки либо переброска на главную страницу форума. 2012/05/01/Super_News Сервер сперва проверяет наличие обработчика 2012, не находит. Дальше проверяет обработчик регулярок. Находит обработчик newsPlugin, и передает ему строку 2012/05/01/Super_News. Новостной плагин парсит строку и выдает страницу новости. Если нету то либо сообщение об ошибке из плагина, либо переадрисация на главную новостей или сайта либо отдача ошибки серверу, который сам решит что делать на главную переадресовать или ошибку послать. 2013/05/01/Blabla Тоже самое но ошибка. favicon.ico Сервер проверяет на наличие обработчика favicon.ico, не находит. Дальше проверяет обработчик регулярок. Тоже не находит. Дальше проверяет на наличие файла на диске. Если не находит то отсылает 404 (как это делает апач). blablabla/bla Тоже самое не находит обработчик blablabla и нет совпадений в регулярках. И файла такого нету, возвращает 404 (как это делает апач), либо перекидывает на главную сайта. Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 22:44 Да, понял теперь, что ты имеешь ввиду, но у меня как бы немного иначе построено. Рассматриваемые плагины forumPlugin и newsPlugin - это не что иное, как, например, forum.ru и news.ru (при этом на тот же forumPlugin может указывать и другой хост - forum.com). То есть плагин - это сайт.
Всё, что идёт после имени хоста относится уже к конкретному плагину. Допустим я предварительно зарегистрирую его обработчик. Тогда как-то на регулярках сайт должен будет описать все возможные варианты, ведь favicon и favicon.ico - могут присутствовать вместе: первый, как страница, а второй, как файл. И если, допустим, сейчас я, как разработчик конкретного сайта, не использую этот злосчастный favicon.ico, а потом добавлю его в папку на сервере, то мне придётся править код плагина, и выполнять перекомпиляцию dll-ки. Это конечно вариант. Надо обмозговать идею с обработчиками, спасибо, V1KT0P. Просто я хотел сделать так, чтобы разработчик сайта по минимуму определял вариации, ограничившись, например, лишь чем-то подобным: /action и/или /controller/action и/или /module/controller/action. Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 01, 2012, 22:57 Тогда как-то на регулярках сайт должен будет описать все возможные варианты, ведь favicon и favicon.ico - могут присутствовать вместе: первый, как страница, а второй, как файл. Повторю еще раз сперва проверяется наличие файла на диске, если его нет то происходит попытка вызова динамического контента. Проще всего для этого использовать nginx, он для этого и создавался.Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 01, 2012, 23:08 Повторю еще раз сперва проверяется наличие файла на диске, ... Да, да, это само собой. Я так и сделал пока.... если его нет то происходит попытка вызова динамического контента. Да, пожалуй. Только управление статусом ответа пихать в плагины не буду, лишь просто возврат ошибки, а сервер подытожит: 404 или ещё какой вариант.Проще всего для этого использовать nginx, он для этого и создавался. Статику мой сервер отдаст прекрасно и без nginx. Дополнительная прослойка не нужна в данном случае. Это больше для Апача актуально, где множество предварительных "настроечных" действий выполняется, прежде чем возникнет решение об отдаче.Спасибо :) Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: Bepec от Май 02, 2012, 06:57 Совет - используй уже имеющиеся наработки. Сотни, если не тысячи разработчиков реализовали почти все идеи, которые можно реализовать в веб направлении. Ну или описали, почему не стоит реализовывать. ;) Собственный велосипед - хорошо, поехали. А вот собственный танк уже плохо - то с места не сдвинется, то боезапас взорвётся ;)
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 02, 2012, 09:59 Совет - используй уже имеющиеся наработки. Тогда и писать ничего не надо :)Сотни, если не тысячи разработчиков реализовали почти все идеи, которые можно реализовать в веб направлении. Ну или описали, почему не стоит реализовывать. ;) Да наверное и без "почти" реализовали. Но мне сам процесс интересен. Разработка ради разработки - это не великий гут, но если прёт, то и хорошо ))Собственный велосипед - хорошо, поехали. А вот собственный танк уже плохо - то с места не сдвинется, то боезапас взорвётся ;) Этот результат может получить в итоге и не только велосипедо-ваятель :)А вообще, я поставил скорость работы программы в наивысший приоритет. Очень приятно смотреть, как в считанные миллисекунды формируется страница. Скорость передачи - тут уж не улучшить, от сетей зависит (сжатие само собой использовать буду), но наблюдать за скоростью работы сайта на С++ очень интересно. Особливо, когда вспоминаешь потуги пыхпыха. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: Bepec от Май 02, 2012, 10:09 Извиняюсь, а можно результаты в студию?
Страница сгенерирована за 0.059 секунд. Запросов: 19. - Это форумный php выдаёт. А у вас? Стоило того? Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 02, 2012, 10:25 Извиняюсь, а можно результаты в студию? Пока в худшем и редком случае 0.002, а так 0.000 - 0.001. Но справедливости ради следует заметить, что я лишь собрал пока простенький статический документ и без обращения к БД (начал писать проект недавно). Ориентируюсь для себя на скорость 0.020 - таковую заметил у главной страницы гугла.Страница сгенерирована за 0.059 секунд. Запросов: 19. - Это форумный php выдаёт. А у вас? Стоило того? Форум на кеше сидит, если его отключить, вообще каюк будет. А если на кеше, да на С++, я думаю определённо имеет смысл хотя бы поэкспериментировать.Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 02, 2012, 14:02 Статику мой сервер отдаст прекрасно и без nginx. Дополнительная прослойка не нужна в данном случае. Это больше для Апача актуально, где множество предварительных "настроечных" действий выполняется, прежде чем возникнет решение об отдаче. Я бы не стал недооценивать nginx. Ты вообще знаешь зачем стали ставить фронтэнды? Причина банальна: быстрое освобождение простаиваемых мощностей из-за того что отдача контента не моментальна. Решили все путем добавления фронтэнда которому сразу отдается запрос и осовобождаются ресурсы. А уж фронтэнд оптимизирован под отдавание контента. Также я бы на твоем месте сразу начертил на листе А1 архитектуру сервера. И по максимуму использовал бы динамическое подключение всего и вся. Чтоб одной кнопкой можно было на лету например заменить старый плагин форума на новый. Да да я все-таки за плагины. Зачем перекомпиливать весь сервер если можно всего навсего перекомпилить один плагин и заменить его без перезапуска онного сервера?Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 02, 2012, 14:42 Я бы не стал недооценивать nginx. Ты вообще знаешь зачем стали ставить фронтэнды? Причина банальна: быстрое освобождение простаиваемых мощностей из-за того что отдача контента не моментальна. Решили все путем добавления фронтэнда которому сразу отдается запрос и осовобождаются ресурсы. А уж фронтэнд оптимизирован под отдавание контента. Нет, нет, я не недооцениваю. Если понадобится, будет резон, то почему бы и нет. А статический контент я у себя отдаю сразу же, без дополнительных телодвижений в плагинах.Также я бы на твоем месте сразу начертил на листе А1 архитектуру сервера. Это хорошая идея. Документированием я не занимался ещё. Через одно место получается делаю ))И по максимуму использовал бы динамическое подключение всего и вся. Чтоб одной кнопкой можно было на лету например заменить старый плагин форума на новый. Да да я все-таки за плагины. Зачем перекомпиливать весь сервер если можно всего навсего перекомпилить один плагин и заменить его без перезапуска онного сервера? Именно так и сделано. Для изменения сайта достаточно заменить файл либы, ну и выполнить на сервере функция загрузки. То есть, что-то типа "горячего" переподключения имеется.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 06, 2012, 17:48 Всем привет
Кто может сейчас протестировать вебсервер? Помогите, пожалуйста По этому адресу - http://78.81.31.38/qqq.webm - видеоролик (осторожно, 20 Мб) Здесь http://78.81.31.38/novgorod.jpg - картинка Спасибо Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 06, 2012, 18:12 По этому адресу - http://78.81.31.38/qqq.webm - видеоролик (осторожно, 20 Мб) Firefox 11, Chrome 18, картинка и видео работает нормально.Здесь http://78.81.31.38/novgorod.jpg - картинка Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 06, 2012, 18:19 Firefox 11, Chrome 18, картинка и видео работает нормально. Спасибо :) Сделал отдачу статики через смену буферов. Пока один наполняется, другой отдаёт данные в сеть. Затем меняются местами. Всё в отдельном потоке, чтобы не тормозить основной на приём новых соединений.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 07, 2012, 18:37 Добавил пару сайтов:
http://78.81.31.38/html/index.html (http://78.81.31.38/html/index.html) http://78.81.31.38/karma/index-3d-1.html (http://78.81.31.38/karma/index-3d-1.html) Заметил гуглобота. Пришла мысль вести информацию о ботах прямо на сервере (что, мол, такой-то приходил), и предоставлять её сайтам по требованию. Имеет смысл? Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 07, 2012, 18:45 Заметил гуглобота. Пришла мысль вести информацию о ботах прямо на сервере (что, мол, такой-то приходил), и предоставлять её сайтам по требованию. Имеет смысл? Если собираешься монетизировать прогу, то чем больше статистики тем лучше. Клиенты будут довольны если ее будет много =).Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 07, 2012, 18:53 Если собираешься монетизировать прогу, то чем больше статистики тем лучше. Клиенты будут довольны если ее будет много =). Нет, монетизировать не буду. В конце-концов ничего оригинального я не придумал. Отправлю исходники по запросу, если будет у кого интерес. Однако сам использовать для своих сайтов буду точно... ну конечно, если будет резон. Пока наблюдаю, что резон есть. Впрочем, всё равно надо доделать, чтобы можно было полноценные сайты писать (пока даже POST-запроса нету :) ).Название: Re: Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 08, 2012, 10:35 Проще всего для этого использовать nginx, он для этого и создавался. Статику мой сервер отдаст прекрасно и без nginx. Дополнительная прослойка не нужна в данном случае. Это больше для Апача актуально, где множество предварительных "настроечных" действий выполняется, прежде чем возникнет решение об отдаче.Спасибо :) Какая модель работы с подключениями? Не будет ли такого что встав на одном запросе повесятся все, или начнется утечка ресурсов. По поводу что отдавать, то при любом раскладе первым проверяется существования запрашиваемого как файла на диске, иначе идет в обработчик. Как пример можно посмотреть на фреймворки на Ruby/Python, они будут ближе по идеологии к тому что пытаетесь реализовать. Ну и конечно посматривать на существующее. Например http://www.webtoolkit.eu/ PS а скорость в 20мс это многовато. В идеале должно укладываться в до 5мс. Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 11:15 Какая модель работы с подключениями? Не будет ли такого что встав на одном запросе повесятся все, или начнется утечка ресурсов. Сокеты "живут" в главном потоке, но под каждый запрос (http request) создаётся отдельная нитка. Кол-во ниток устанавливается в конфигурационном файле приложения (по умолчанию QThread::idealThreadCount). Если кол-во работающих ниток достигают установленного максимума, то новые запросы помещаются в очередь и уже их нитки будут созданы и запущены при завершении работы предыдущих.Нитки, конечно, независимы, но не настолько, как процессы. Я сознательно иду на это. Проще говоря, мой проект не предполагает использование одного instance сервера разными людьми (концепция: один владелец множества сайтов), поэтому, если сервер "рухнет" по вине одного из плагинов сайтов, виновного разраба найти будет легко :) По поводу что отдавать, то при любом раскладе первым проверяется существования запрашиваемого как файла на диске, иначе идет в обработчик. Да, так и сделал. Но пожалуй сделаю и некоторые исключения. Например, для файлов favicon.ico и robots.txtКак пример можно посмотреть на фреймворки на Ruby/Python, они будут ближе по идеологии к тому что пытаетесь реализовать. К сожалению, плохо знаком с этими языками. PHP знаю, но он просто достал.Ну и конечно посматривать на существующее. Например http://www.webtoolkit.eu/ Да, да, эта библиотека у меня в закладках. В своём проекте я не хочу ограничивать разраба сайта никакими правилами. Лишь минимальный интерфейс взаимодействия с сервером и всё. Не нужно определять заранее никаких виджетов, поскольку вебмастерам, зачастую, требуется уникальность в этом вопросе, начиная от внешнего вида и заканчивая поведением.PS а скорость в 20мс это многовато. В идеале должно укладываться в до 5мс. Пока 1 мс. А там, посмотрим.Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 15:29 Пока 1 мс. А там, посмотрим. Тут вот почему тебе советуют фронтэнд поставить:1) Представь себе что к тебе подключились 100 медленных клиентов, запрос обработался 1 мс но 10 секунд отдается результат. В итоге у тебя 100 ниток висят мертвым грузом 10 секунд. В итоге тебе потребуется оптимизировать. Плюс еще получаешь кучу проблем с уязвимостями. Например такая уязвимость ддос: на одном компе с медленным каналом запускается программа которая генерирует подключения к серверу, делает запрос и ОЧЕНЬ МЕДЛЕННО получает этот запрос, в итоге у тебя начинает накапливаться очень много ниток, память расходуется и все сервер накрылся. Там еще куча всяких способов "нагнуть" сервер. А вот поставив nginx ты решаешь все эти проблемы моментально. 2) А теперь тоже что и п.1 но у тебя стоит фронтэнд nginx. подключаются 100 медленных клиентов, запрос обрабатывается за 1 мс, все 100 запросов сразу отдается nginx-у, твои ресурсы освобождаются а nginx специально заточен и потребляет минимум памяти и проц. времени и потихоньку отдает контент. Если происходит ддос путем медленного коннекта или любого другого то nginx тупо режет такое соединение. Так что поначалу советую тебе спрятать свой сервер за nginx-ом. Когда закончишь допиливать и решишь все проблемы которые решает nginx, тогда и уберешь. Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 15:54 V1KT0P, я с тобой согласен. nginx я бы обязательно поставил как фронтэнд к своему серверу, если бы планировал запускать на нём какой-нибудь сайт сейчас. Пока же, в этом нет необходимости, да и я планирую реализовать жёсткий временной контроль над временем работы каждой нитки, плюс выявление всяческих злодейств, какие только смогу описать. Насколько это получится/не получится - покажет время. nginx-же можно установить в любой момент, но мне хочется попытаться обойтись без него. К тому же ddos - это задача уже скорее сисадмина, нежели вебмастера. Никакой nginx не устоит против серьёзного ddos'а.
Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 16:19 К тому же ddos - это задача уже скорее сисадмина, нежели вебмастера. Никакой nginx не устоит против серьёзного ddos'а. Дело в том что есть способы "положить" сервер с одного компа с каналом в 5-10 мегабит. Есть даже некоторые программы для этого, но они не используются по причине того что популярных веб-серверов несколько штук, все они писались грамотными специалистами и все уязвимости(даже гипотетические) закрыты. А вот тебе прийдется серьезно подумать над безопасностью.Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 16:41 Дело в том что есть способы "положить" сервер с одного компа с каналом в 5-10 мегабит. Есть даже некоторые программы для этого, но они не используются по причине того что популярных веб-серверов несколько штук, все они писались грамотными специалистами и все уязвимости(даже гипотетические) закрыты. А вот тебе прийдется серьезно подумать над безопасностью. Могу с уверенностью утверждать, что на этих серверах уязвимости закрыты прежде всего не ПО вебсервера, а специально предназначенными для этого программами, действующими на пакетном уровне и на тот момент, когда данные эти ещё даже не отосланы приложению. Я не силён в сисадминстве, но именно с помощью таких анализаторов (или как их ещё назвать), сидящих может быть на одном (или сразу за) уровне файервола, знакомый админ отбивал ddos'ы. Да, какие-то общие оптимизации для вебсервера определённо необходимы, но это скорее традиционные меры безопасности... э-э-э... правила хорошего тона, что-ли. Некий лёгкий заслон, защищающий от "детей".Почему разрабы Apache не занимаются такими вопросами, как отдача статики? С их-то финансированием могли бы и озадачиться (опять недавно мелькало в новостях об очередном спонсоре). Почему желательно использовать nginx с ним в паре? Ведь любая связка - это лишняя нагрузка, пусть и незначительная, но всё же. Однозначно запрос обрабатывался бы ещё быстрее, если бы функционал nginx был встроен в апач. И безусловно, положить можно любой ресурс, но весь вопрос в адекватности затрат. Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 17:13 Могу с уверенностью утверждать, что на этих серверах уязвимости закрыты прежде всего не ПО вебсервера, а специально предназначенными для этого программами, действующими на пакетном уровне и на тот момент, когда данные эти ещё даже не отосланы приложению. Я не силён в сисадминстве, но именно с помощью таких анализаторов (или как их ещё назвать), сидящих может быть на одном (или сразу за) уровне файервола, знакомый админ отбивал ddos'ы. Да, какие-то общие оптимизации для вебсервера определённо необходимы, но это скорее традиционные меры безопасности... э-э-э... правила хорошего тона, что-ли. Некий лёгкий заслон, защищающий от "детей". Ну ну, вот попробуй хоты бы представить программу которая на пакетном уровне отслеживает что-то по протоколу https.Почему разрабы Apache не занимаются такими вопросами, как отдача статики? С их-то финансированием могли бы и озадачиться (опять недавно мелькало в новостях об очередном спонсоре). Почему желательно использовать nginx с ним в паре? Ведь любая связка - это лишняя нагрузка, пусть и незначительная, но всё же. Однозначно запрос обрабатывался бы ещё быстрее, если бы функционал nginx был встроен в апач. Вот тут ты неправ, как я выше приводил пример nginx как раз и уменьшает нагрузку на Apache. А мешать все в кучу тоже не стоит. Мало того что nginx и Apache можно в одно приложение скрестить, следуя твоей мысли можно пойти дальше и вообще в ядро ОС встроить это все =).nginx почти всегда ставится для снижения нагрузки, а у тебя почему-то она только возрастает =). И безусловно, положить можно любой ресурс, но весь вопрос в адекватности затрат. Вот честно скажи у тебя сейчас стоит лимит на размер запроса и время запроса. Если я начну слать гигабайтные запросы и последние 10 мегабайт отдавать в течении часа что будет?Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 17:34 Ну ну, вот попробуй хоты бы представить программу которая на пакетном уровне отслеживает что-то по протоколу https. А какая разница http, https или ещё какой высокоуровневый протокол, если речь идёт о пакетах. Насколько я понял из объяснений, анализируется что-куда-кому-зачем с учётом времени.Вот тут ты неправ, как я выше приводил пример nginx как раз и уменьшает нагрузку на Apache. Уменьшает конечно, потому что в Апаче нет кода для быстрой отдачи статики.А мешать все в кучу тоже не стоит. Мало того что nginx и Apache можно в одно приложение скрестить, следуя твоей мысли можно пойти дальше и вообще в ядро ОС встроить это все =). Мера - мудрость Вселенной :) Ну а вообще, такие ли уж принципиально разные Апач с nginx задачи выполняют?nginx почти всегда ставится для снижения нагрузки, а у тебя почему-то она только возрастает =). nginx висит отдельным процессом. Как ни крути, затраты на взаимодействие его с Апачем - имеются. Буде в Апаче код nginx встроен корректно, этих бы затрат не было. Другими словами, это мог бы быть программный слой, срабатывающий на статику и не грузящий дальнейший код в случае успеха, но внутри Апача. Вполне вероятно, что даже как dll-ка такой встроенный код работал бы быстрее.Вот честно скажи у тебя сейчас стоит лимит на размер запроса и время запроса. Если я начну слать гигабайтные запросы и последние 10 мегабайт отдавать в течении часа что будет? Сейчас у меня нет никаких лимитов. Я об этом написал чуть выше. Естественно грохнется сервер. И нет у меня никаких защитных программ на компе, т.к. desktop это обычный.Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 18:08 А какая разница http, https или ещё какой высокоуровневый протокол, если речь идёт о пакетах. Насколько я понял из объяснений, анализируется что-куда-кому-зачем с учётом времени. Разница в том что применяется шифрование =). Как минимум надо расшифровывать, значит нудна поддержка https. Тоесть из простого понемногу начинает получаться мутант =). Допустим посмотрим момент с "медленным доссом" пакеты идут от клиента на сервер, они ничего подозрительного не содержат. Но сервер все ждет пока получит последний пакет, а его все нет и нет. =). А защитная программа следит и видит что все правильно, клиент передает пакеты не превышая лимита =), а сервак понемногу погибает.Уменьшает конечно, потому что в Апаче нет кода для быстрой отдачи статики. Ну согласись там разработчики не идиоты =). Зачем им делать то что, раз есть уже готовое и бесплатное, к тому-же прекрасно справляется. И зачем им встраивать nginx, если они вдруг захотят использовать lighttpd, или еще какой-нибудь малоизвестный продукт =). Тут используется философия Unix-way каждой задаче своя программа. Что позволяет комбинировать программы между собой как-то: nginx+Apache, lighttpd+Apache, nginx+unicorn. Как видишь раздельные программы очень гибкие, а если начать писать библиотеки для каждого сервера, то это будет настоящий программистский ад. Мера - мудрость Вселенной :) Ну а вообще, такие ли уж принципиально разные Апач с nginx задачи выполняют? nginx висит отдельным процессом. Как ни крути, затраты на взаимодействие его с Апачем - имеются. Буде в Апаче код nginx встроен корректно, этих бы затрат не было. Другими словами, это мог бы быть программный слой, срабатывающий на статику и не грузящий дальнейший код в случае успеха, но внутри Апача. Вполне вероятно, что даже как dll-ка такой встроенный код работал бы быстрее. Сейчас у меня нет никаких лимитов. Я об этом написал чуть выше. Естественно грохнется сервер. И нет у меня никаких защитных программ на компе, т.к. desktop это обычный. Честно не слышал ни про какие специальные защитные программы для веб-серверов. Назови хотя-бы парочку. Везде обычно используется правильно настроенный nginx.Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 18:30 Разница в том что применяется шифрование =). Как минимум надо расшифровывать, значит нудна поддержка https. Тоесть из простого понемногу начинает получаться мутант =). Зачем расшифровывать пакет? O_o В TCP пакете вся необходимая инфа имеется. Иначе как по твоему через роутеры зашифрованные данные шлются, расшировываются на лету что-ли? :)Допустим посмотрим момент с "медленным доссом" пакеты идут от клиента на сервер, они ничего подозрительного не содержат. Но сервер все ждет пока получит последний пакет, а его все нет и нет. =). А защитная программа следит и видит что все правильно, клиент передает пакеты не превышая лимита =), а сервак понемногу погибает. Я вроде написал выше, что контроль пакетов с учётом времени.Ну согласись там разработчики не идиоты =). Зачем им делать то что, раз есть уже готовое и бесплатное, к тому-же прекрасно справляется. Могло бы и лучше, к тому же nginx появился позже Апача. Есть спрос, возникло предложение. Почему разработчики Апача не стали уделять внимания этой проблеме - другой вопрос.И зачем им встраивать nginx, если они вдруг захотят использовать lighttpd, или еще какой-нибудь малоизвестный продукт =). Тут используется философия Unix-way каждой задаче своя программа. Что позволяет комбинировать программы между собой как-то: nginx+Apache, lighttpd+Apache, nginx+unicorn. Как видишь раздельные программы очень гибкие, а если начать писать библиотеки для каждого сервера, то это будет настоящий программистский ад. Если следовать философии Unix-way, то потребуется ещё и Апач поделить на пару десятков приложений и мелких утилит. А уж если в основе конструктор, то, как говорится, изволь быть последовательным.Честно не слышал ни про какие специальные защитные программы для веб-серверов. Назови хотя-бы парочку. Везде обычно используется правильно настроенный nginx. Назвать не могу, поскольку не занимаюсь этими вопросами. Беседа просто интересная, поэтому поддерживаю :)Ну давай логически. Http и те, что рядышком - лишь одна из дверей, так ведь? А кто может заниматься сетевым стеком на уровне ядра системы, приоткрывая/закрывая эти самые двери? По идее файервол. Но его мало, поскольку он устанавливает правила безотносительно ко времени (если не ошибаюсь). Значит, это что-то с возможностями файервола, но опирающееся при анализе на временную величину. Можно погуглить. Могу точно сказать, что и на Хабре таковые вопросы мелькали. Даже сравнивали варианты, спорили, какой круче в защите от ddos'а. nginx там не фигурировал, он не для этого. Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 18:49 Ладно давай продолжим дальше четко про фронтэнды и бэкэнды.
Если следовать философии Unix-way, то потребуется ещё и Апач поделить на пару десятков приложений и мелких утилит. А уж если в основе конструктор, то, как говорится, изволь быть последовательным. Тут дело в том что у каждого сервера свои особенности и поэтому код из апача врятли можно было бы успешно использовать в том-же unicorn-е.Дальше надо четко определить что фронэнд и что бэкэнд. Бэкэнд это сам веб-сервер, а фронтэнд это прокси-сервер для веб-серверов. Как видишь это разные категории и сделаны для разных целей. Один фронтэнд может обеспечивать работу сразу двух серверов, например Apache и unicorn. При чем они могут быть не на той-же машине а быть в локальной сети на разных. Можно пойти дальше, нужно увеличить производительность бэкенд сервера в 10 раз и очень быстро. Без проблем настраиваем фронтэнд и он распределяет нагрузку на 10 машин в локальной сети, на каждой запущен свой экземпляр Apache. Ты не думай что nginx сделан только для быстрой отдачи статики, он еще умеет кешировать, распределять нагрузку, всякие фильтры, обеспечивает поддержку SSL(то-есть бэкенд не обязан знать что работает по шифрованному каналу, да он и не узнает). Как видишь nginx не так прост как тебе кажется =). Вот понадобится тебе использовать SSL в своем сервере, а с nginx всего-то надо настройки изменить, и в коде сервера менять не надо. Название: Re: Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 19:12 Ладно давай продолжим дальше четко про фронтэнды и бэкэнды. Хорошо.Тут дело в том что у каждого сервера свои особенности и поэтому код из апача врятли можно было бы успешно использовать в том-же unicorn-е. Про это не подумал, честно. Тогда конечно ты абсолютно прав. Деление имеет смысл.Дальше надо четко определить что фронэнд и что бэкэнд. Бэкэнд это сам веб-сервер, а фронтэнд это прокси-сервер для веб-серверов. Как видишь это разные категории и сделаны для разных целей. Один фронтэнд может обеспечивать работу сразу двух серверов, например Apache и unicorn. При чем они могут быть не на той-же машине а быть в локальной сети на разных. Можно пойти дальше, нужно увеличить производительность бэкенд сервера в 10 раз и очень быстро. Без проблем настраиваем фронтэнд и он распределяет нагрузку на 10 машин в локальной сети, на каждой запущен свой экземпляр Apache. Ты не думай что nginx сделан только для быстрой отдачи статики, он еще умеет кешировать, распределять нагрузку, всякие фильтры, обеспечивает поддержку SSL(то-есть бэкенд не обязан знать что работает по шифрованному каналу, да он и не узнает). У меня и разрабов nginx разные весовые категории. Разумеется, что всё, что есть в nginx, я не смогу всецело реализовать у себя. Да и попросту не нужно это мне. На эту тёмную сторону мой академический интерес не распространяется. Однако, без зазрения совести установлю фронтом nginx, если будет резон.Как видишь nginx не так прост как тебе кажется =). Вот понадобится тебе использовать SSL в своем сервере, а с nginx всего-то надо настройки изменить, и в коде сервера менять не надо. З.Ы. V1KT0P, можно будет тебя попросить потестить сервер, когда я защитный функционал нацеплю? В боевых условиях оно лучше видно, где в очередной раз накосячил. Ну и конечно при отрицательных результатах теста оставлю тогда идею реализации собственной защиты, если окажется, что ничего толкового предложить не могу. Название: Re: Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 19:21 З.Ы. V1KT0P, можно будет тебя попросить потестить сервер, когда я защитный функционал нацеплю? В боевых условиях оно лучше видно, где в очередной раз накосячил. Ну и конечно при отрицательных результатах теста оставлю тогда идею реализации собственной защиты, если окажется, что ничего толкового предложить не могу. Дело в том что я веб-разработкой не занимаюсь, но в инете можешь найти уже готовые программы которые тестируют на разные уязвимости, в основном на алгоритмические(нет предела размеру, времени и т.д.). На хабре с пол года назад была тема про такие уязвимости, поищи там думаю будет куча ссылок.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 19:30 Я в другой теме форума написал запрос о поиске подобной проги. Пока только SoapUI (http://www.soapui.org/) предложили. С ней может тогда попробую разобраться. Мне собственно пока хватило бы, чтобы сервер просто досили, а я бы смотрел ответное поведение. Самого себя досить тоже не свят-свят. А купишь сервер, начнёшь "развлекаться" - улыбки от местных админов не жди ))
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 19:45 Я в другой теме форума написал запрос о поиске подобной проги. Пока только SoapUI (http://www.soapui.org/) предложили. С ней может тогда попробую разобраться. Мне собственно пока хватило бы, чтобы сервер просто досили, а я бы смотрел ответное поведение. Самого себя досить тоже не свят-свят. А купишь сервер, начнёшь "развлекаться" - улыбки от местных админов не жди )) Вот с ходу нашел тему: http://habrahabr.ru/post/116056/ (http://habrahabr.ru/post/116056/). Там и про OWASP HTTP POST Tool, и SYN flood. И детальное описание.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 19:52 Вот с ходу нашел тему: http://habrahabr.ru/post/116056/ (http://habrahabr.ru/post/116056/). Там и про OWASP HTTP POST Tool, и SYN flood. И детальное описание. Очень интересно, спасибо :)Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 20:21 Ну вроде не так плохо у меня в случае с этой атакой. Трэд не создаётся, пока запрос не будет сформирован полностью. Единственное, может быть стоит в файл по примеру nginx записывать недопринятые запросы, чтобы в памяти не висели. Хоть и небольшой там размер, но всё же. И конечно нужно добавить слежку за "тормозными" соединениями.
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 08, 2012, 20:27 Ну вроде не так плохо у меня в случае с этой атакой. Трэд не создаётся, пока запрос не будет сформирован полностью. Единственное, может быть стоит в файл по примеру nginx записывать недопринятые запросы, чтобы в памяти не висели. Хоть и небольшой там размер, но всё же. И конечно нужно добавить слежку за "тормозными" соединениями. Тогда сделай очень много запросов(тут важно с нескольких компов или с линукса с увеличинным количеством сокетных дескрипторов). Если у тебя сервер на винде, то достаточно скоро сокетные дескрипторы закончатся =).Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 08, 2012, 20:37 Тогда сделай очень много запросов(тут важно с нескольких компов или с линукса с увеличинным количеством сокетных дескрипторов). Да, обязательно проведу тест и отпишусь о результате. Я сделал голословный вывод в общем-то, то есть пока без реальной проверки, т.к. в атаке там именно POST-запрос используется. Думаю поддержку его завтра сделать на сервере. Завтра же и попробую завалить.Если у тебя сервер на винде, то достаточно скоро сокетные дескрипторы закончатся =). Комп на линуксе. У меня скорее проблема в отсутствии виндовса для тестов ))Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 09, 2012, 11:25 Сервер который разрабатываете больше похож на сервер приложения, читай бэкэнд. Он не должен быть супер пупер устойчивым с DoS, главное чтобы работал стабильно, не поедал ресурсы и выполнял свою задачу. Общение с миром задача фронтенда, в частности толи это кеширующий прокси, либо балансировщики по типу nginx/haproxy. Каждый должен заниться своей задачей.
По поводу apache и nginx, в апаче есть методы для отдачи статики, отдает он ее нормально. НО до некоторого количества запросов в секунду, дальше дают о себе знать архитектурные особенности, заложенные еще в самом начале. У данных продуктов абсолютно разные модели работы, если у nginx не создает под каждый запрос поток, а старается по максмуму работать асинхронно (чтение/запись в сокеты/файла), то Apache наоборот пораждает много потоков, как результат большое потребление ресурсов и накладные расходы. Поэтому его сейчас использую в качестве сервера приложений. Почему рекомендовал посмотреть на архитектуру Ruby/Python фреймворков, т.к. по сути они запускают сервера приложений (Webrick, Thin, Mongrel, Unicord и тд) и их ВСЕГДА прячут за балансировщиком, т.к. их главная задача динамика, со статикой справятся другие. К примеру у меня сервис (для работы) крутящийся на приличном железе выдает в динамике 6000 RPS (1000 запросов 500 конкурентных). При этом загрузка увеличивается лишь процентов на 10. Всю балансировку на себя берет Nginx, в том числе отбой лишних запросов. ЗЫ и главный вопрос, закладываете ли основу для горизонтального масштабирования? Без него сложнее сайта визитки/портфолио и тп делать не стал бы, а для данного решения главная ниша это различные HTTP сервисы, а тут вопрос масштабирования очень остро стоит. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 09, 2012, 13:59 Сервер который разрабатываете больше похож на сервер приложения, читай бэкэнд. Он не должен быть супер пупер устойчивым с DoS, главное чтобы работал стабильно, не поедал ресурсы и выполнял свою задачу. Общение с миром задача фронтенда, в частности толи это кеширующий прокси, либо балансировщики по типу nginx/haproxy. Каждый должен заниться своей задачей. Пока получается симбиоз фронта и тыла. С одной стороны идея проекта соответствует серверу приложений. С другой - принцип обработки поступающих запросов близок фронту.По поводу apache и nginx, в апаче есть методы для отдачи статики, отдает он ее нормально. НО до некоторого количества запросов в секунду, дальше дают о себе знать архитектурные особенности, заложенные еще в самом начале. У данных продуктов абсолютно разные модели работы, если у nginx не создает под каждый запрос поток, а старается по максмуму работать асинхронно (чтение/запись в сокеты/файла), то Apache наоборот пораждает много потоков, как результат большое потребление ресурсов и накладные расходы. Поэтому его сейчас использую в качестве сервера приложений. Стадия обработки поступающих запросов в моём проекте получается ближе именно к nginx. Парсинг данных каждого запроса выполняется асинхронно в главном потоке приложения. Отдельный поток создаётся только в случае полной уверенности в корректности запроса. Разница с nginx получается в том, что последний транслирует запрос бэкэнду, в то время как у меня дальнейшая обработка осуществляется тем же процессом (но в отдельном потоке, конечно). Разница с Апачем заключается в том, что я не создаю отдельных процессов на запросы, работаю с потоками в едином адресном пространстве. Это уменьшает накладные расходы, но делает сервер менее устойчивым в случае, например, возникновения segmentation fault в любом из подключенных в роли плагинов сайтов (можно сказать даже абсолютно неустойчивым, и налагает соответствующую ответственность на разработчика плагина сайта). Кстати, если предполагается использовать лишь один сайт, то его код можно внедрить непосредственно в код сервера и не использовать никаких плагинов вообще. Это, по идее, поспособствует ещё большему снижению накладных расходов.Почему рекомендовал посмотреть на архитектуру Ruby/Python фреймворков, т.к. по сути они запускают сервера приложений (Webrick, Thin, Mongrel, Unicord и тд) и их ВСЕГДА прячут за балансировщиком, т.к. их главная задача динамика, со статикой справятся другие. Другими словами, заморачиваться с анализом на предмет зловредства slow post atack и ddos не стоит, правильно я понимаю?К примеру у меня сервис (для работы) крутящийся на приличном железе выдает в динамике 6000 RPS (1000 запросов 500 конкурентных). При этом загрузка увеличивается лишь процентов на 10. Всю балансировку на себя берет Nginx, в том числе отбой лишних запросов. ЗЫ и главный вопрос, закладываете ли основу для горизонтального масштабирования? Без него сложнее сайта визитки/портфолио и тп делать не стал бы, а для данного решения главная ниша это различные HTTP сервисы, а тут вопрос масштабирования очень остро стоит. Считаю эту задачу обязательной к разрешению. Одного сервера недостаточно в случае реализации серьёзного вебпроекта. Мне бы хотелось, если это возможно, услышать Ваши рекомендации по данной теме. Со своей стороны приведу следующие рассуждения.В вопросе с горизонтальным масштабированием необходимо разделить вычисления (другими словами формирование страниц сайтов) и отдачу статики. Действительно, это разные задачи со своими особенностями в процессе исполнения, которые мешать в кучу не следует. Я был не прав, признаю. В случае со статикой масштабирование может производиться при помощи фронта и использования сетевых файловых систем. Иными словами, эту часть вопроса можно закрыть при помощи сторонних по отношению к вебсерверу средств. Таким образом, следует обратить внимание именно на динамику, задачу реализации которой можно развести на три составляющие:
Первый пункт может быть закрыт средствами самого сервера БД. Наверное все популярные БД поддерживают репликацию. Некоторые могут быть объединены в кластер. Однако это не обязательно, и распределение данных на разные сервера БД можно производить непосредственно плагином сайта. Плюсы и минусы обоих решений оставлю за кадром, лишь подчеркну, что оба метода поддерживаются проектом вебсервера по определению. Над вторым пунктом мне необходимо подумать. Здесь можно использовать как и сторонний сервис, например, memcache, так и собственную реализацию взаимодействия между различными instance вебсервера, разнесёнными на разные хосты. Может быть имеет смысл реализовать поддержку обоих методов. Возможно, у Вас есть собственные соображения на этот счёт. Третий пункт частично связан со вторым пунктом. Здесь подразумевается возможность плагина сайта подключаться к любому другому сервису в сети (да хоть к самому же вебсерверу по HTTP :) ) для осуществления каких-либо вычислений, необходимых ему при формировании конечного результата своей работы. Тут как бы получается, что данная возможность тоже по определению поддерживается, поскольку вебсервер никоим образом не ограничивает плагины сайтов в их собственных мытарствах. Таким образом, задача поддержки вебсервером горизонтального масштабирования в моём случае сводится ко второму пункту. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 09, 2012, 19:40 Подключил POST-запрос. Напишите, пожалуйста, кто может протестить мой сервер через slow post atack. По этой ссылке можно скачать прогу юного хакера: http://habrahabr.ru/post/116056/ (http://habrahabr.ru/post/116056/)
У себя запускаю - открывается максимум 4000 соединений с копейками. Видимо ограничения какие-то срабатывают в системе. Пробовал в /etc/security/limits менять значение до 100000 на hard и soft. Вроде ставится, но всё равно больше 4000 соединений не создаётся, больше - операционка напрочь вырубает сервер. Это наверняка настраивается как-то, но я не стал вдаваться в подробности пока. На 4000 соединениях вебсервер пашет без проблем (и это при том, что я через внешний адрес сам к себе подключаюсь). Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 14, 2012, 22:05 Возникла идея защиты от fast ддоса (традиционного, в противовес slow). Например, если детектится подозрительная активность с какого-либо хоста, то автоматом вносится соответствующая запись в настройки файервола, и нехороший бот банится, не успев навредить.
Правда, это решение также автоматом выносит приложение из разряда кроссплатформенных. С виндовсом я знаком очень плохо, и там мне такое не реализовать точно. Впрочем, виндовс-вебсервер лично для меня нонсенс :) В проект добавил сжатие контента через deflate и gzip (в планах sdch, и не знаю, стоит ли добавлять compress). Также добавил функционал по раздаче контента частями (Content-Range). Надо будет заняться вплотную документацией (http://78.81.31.38/html/index.html). Пожалуй сайт первый сделаю о проекте вебсервера и прямо на нём же, как у WT :) Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 14, 2012, 22:11 Традиционный это когда весь канал забивают мусором. Ну будешь ты отсекать этот мусор, но ведь мало кто через него пробьется к тебе из реальных пользователей.
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 14, 2012, 22:26 Традиционный это когда весь канал забивают мусором. Ну будешь ты отсекать этот мусор, но ведь мало кто через него пробьется к тебе из реальных пользователей. На уровне файервола по конкретному айпишнику пресекать доступ. Запросы с этого хоста не дойдут до приложения, а всем остальным - пожалуйста.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 14, 2012, 22:33 На уровне файервола по конкретному айпишнику пресекать доступ. Запросы с этого хоста не дойдут до приложения, а всем остальным - пожалуйста. Мы говорим о разных вещах. То что отсекаются боты для предотвращения загрузки процессора это понятно. Но допустим у тебя канал в 100 Мб/с, тебе боты шлют запросы с скоростью 200 Мб/с. В результате канал забивается и нормальные пользователи не могут послать запрос к тебе, ибо и так канал перегружен. Да единицы может и достучатся в течении продолжительного времени, но это будут именно единицы. Так что есть еще куда расти =).Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 14, 2012, 22:40 Мы говорим о разных вещах. То что отсекаются боты для предотвращения загрузки процессора это понятно. Но допустим у тебя канал в 100 Мб/с, тебе боты шлют запросы с скоростью 200 Мб/с. В результате канал забивается и нормальные пользователи не могут послать запрос к тебе, ибо и так канал перегружен. Да единицы может и достучатся в течении продолжительного времени, но это будут именно единицы. Мне это известно, и я не заявлял о 100% защите. Да, завалят (как и любой другой вебпрокси), но чтобы завалить вебсервер с э-э-э... таким активным файерволом (назовём это так) потребуется гораздо больше ресурсов, нежели чем без него. Мне кажется, что резон тут имеется.Так что есть еще куда расти =). Есть более интересные идеи?Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 14, 2012, 23:05 Есть более интересные идеи? Если есть несколько серверов, то можно какую-нибудь схему придумать =).Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 14, 2012, 23:33 Если есть несколько серверов, то можно какую-нибудь схему придумать =). Это да, масштабирование хорошая вещь. Но если есть возможность делать на одной машине то, для чего в другой ситуации потребуется две или даже несколько, то по идее отказываться от такого варианта не гут. Да и не противоречит "активный" файервол связкам. А очень хорошо дополняет. Другое дело, что наверное тогда это решение стоит вынести в отдельное приложение, и дать вебсерверу возможность им управлять. Или пусть самостоятельным будет полностью. Но тогда проще взять готовое.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 08:56 Признавайтесь, кто присылал на сервер запрос: "/?-s"? Такое не будет работать по определению. Однако всё равно спасибо за тест :)
З.Ы. Просьба на тестирование через slow post/header atack по прежнему в силе Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 18, 2012, 11:03 Признавайтесь, кто присылал на сервер запрос: "/?-s"? Ахаха, кулхацкеры блин =). Дырку в твоем сервере которая позволит выполнить код смогут найти только при наличии у себя копии сервера =). Так что пока не выложишь исполняемый файл, максимум смогут только уронить сервер.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 11:31 Ахаха, кулхацкеры блин =). :) ну в моём случае это только на пользу. Я бы, честно, и не догадался бы проверить.Дырку в твоем сервере которая позволит выполнить код смогут найти только при наличии у себя копии сервера =). Так что пока не выложишь исполняемый файл, максимум смогут только уронить сервер. Пока никто не спрашивал. А так, занялся сайтом для проекта, где и выложу исходники (после реализации поддержки WebSockets; с ними ради эксперимента чтобы работал). Надо будет ещё хотя бы виртуальный сервер купить, а то мои робкие попытки оставить десктоп включенным на ночь автоматически активируют угрозу в виде летящей в монитор или голову сковородки (видели те шумит) :)Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 12:28 Пожалуйста отпишитесь о результате теста, кто недавно подключался через прокси. Спасибо
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 18, 2012, 17:03 Потестировал под нагрузкой, либо канал узковат, либо машина не самая шустрая, либо сервер не шибко отзывчив:
Код: Concurrency Level: 10 В тоже время мой сервер (при тех же параметрах теста) на nginx + Presto (ruby1.9) выдал: Код: Requests per second: 242.49 [#/sec] (mean) При увеличении количество параллельных подключений прироста не дало, хотя по идее как минимум подрости должно было: Код: Concurrency Level: 500 Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 18, 2012, 17:23 А вот и SLOW POST:
Код: ./slow_http_test --host 78.81.31.38 --path /html/ --slow-post --connections 100 Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 17:23 У меня сейчас стоял ограничитель на 10 соединений с одного IP. Убрал, попробуйте снова, пожалуйста.
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 17:31 Потестировал под нагрузкой, либо канал узковат, либо машина не самая шустрая, либо сервер не шибко отзывчив: Спасибо, что потестили. Не пойму, почему так медленно :(... Хотя у меня всего скорость инета 6 Мбит/сек, то есть 750 Кб/с. Комп - 8 ядерный, с 8 Гб памяти (здесь напрягов не должно быть) Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 18, 2012, 17:37 Никаких изменений:
Цитировать Concurrency Level: 500 Time taken for tests: 95.651 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 385000 bytes HTML transferred: 214000 bytes Requests per second: 10.45 [#/sec] (mean) Time per request: 47825.666 [ms] (mean) Time per request: 95.651 [ms] (mean, across all concurrent requests) Transfer rate: 3.93 [Kbytes/sec] received Может надо посмотреть в событийную модель, те же Nginx, Thin (сервер приложения для ruby) используют libevent внутри себя для организации асинхронного I\O, стараясь как можно меньше блокировать процессы. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 17:47 Никаких изменений: Я тоже на событиях сделал. Буду копаться и искать способ, как заставить систему отрабатывать быстрее. Похоже, у меня узкое место, там где я опираюсь на сигнал QTcpSocket о том, что столько-то данных отправлено. Тогда я отправляю новые данные. Надо здесь по-другому тогда как-то. Ещё раз спасибо большое, без тестирования никуда :)... Может надо посмотреть в событийную модель, те же Nginx, Thin (сервер приложения для ruby) используют libevent внутри себя для организации асинхронного I\O, стараясь как можно меньше блокировать процессы. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 18:23 Вот результат на локалхосте с 500 конкурирующими запросами:
Код: ab -n1000 -c500 http://127.0.0.1:8080/html/ Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 18:25 Может скорость так сильно упасть ещё и потому, что у меня комп за роутером сидит? D-Link DIR-300
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: Bepec от Май 18, 2012, 23:11 Алексис - проверь исходящую скорость интернета. От входящей она обычно отличается в 2 - 3 раза. (Возможно вы итак это знаете, но попытка не пытка)
Так же ваш роутер (у меня такой же) является дешёвой, корявой, признанной даже разработчиками фуфловой коробочкой ;) У меня он лично резал (счас что-то прекратил) примерно 50% пакетов, выдаёт иногда блокировку при использовании потоков(видео, p2p, торренты). (Кто скажет что он идеально работает - да. А некоторые из них работают 1/2/3/4/5/6/7/n времени нормально, а потом появляются вышеперечисленные проблемы ;) Так же чуток режет скорость интернета ) Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 18, 2012, 23:20 Алексис - проверь исходящую скорость интернета. От входящей она обычно отличается в 2 - 3 раза. (Возможно вы итак это знаете, но попытка не пытка) Не знал, спасибо, обязательно проверю.Так же ваш роутер (у меня такой же) является дешёвой, корявой, признанной даже разработчиками фуфловой коробочкой ;) )))У меня он лично резал (счас что-то прекратил) примерно 50% пакетов, выдаёт иногда блокировку при использовании потоков(видео, p2p, торренты). Стал замечать в последнее время, что возьмёт, да вырубит доступ к инету минут на 5-10. Ни с того, ни с сего. Я грешил на провайдера сначала. Раньше такого не было, месяца 4 назад купил. И где-то вот с месяц такая фигня стала проявляться. Он мне нужен в принципе только для вайфая. С ним удобно конечно, но раз такие дела, то пожалуй имеет смысл что-то получше купить.(Кто скажет что он идеально работает - да. А некоторые из них работают 1/2/3/4/5/6/7/n времени нормально, а потом появляются вышеперечисленные проблемы ;) Так же чуток режет скорость интернета ) Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 19, 2012, 12:48 Провёл небольшую оптимизацию кода. Вот результат выполнения 1000 одновременных запросов:
Код: ab -n1000 -c1000 http://127.0.0.1:8080/html Сейчас попробую запустить через внешний адрес без роутера. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 19, 2012, 13:16 В общем, практически та же скорость:
Код: ab -n1000 -c1000 http://78.81.31.38:8080/html Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 20, 2012, 08:07 А теперь если запустить пару экземпляров и спрятать за балансировщиком, можно получить 6K RPS и даже больше.
Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 20, 2012, 11:01 Это да, но главное, что пока удаётся выжать максимум со stand alone. Вполне вероятно, что ещё многое можно было бы оптимизировать, но пока, пожалуй, приостановлюсь с этой задачей, иначе дальше не скоро продвинусь :)
Здесь (http://78.81.31.38:8080/html/index.html) буду публиковать документацию по коду. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 23, 2012, 14:39 Передумал "приостанавливаться". Довёл скорость до 3500 RPS на 1000 одновременных запросов, однако это, похоже, уже высшая точка. Ну может быть ещё пол-тысячи запросов удастся через какой-нибудь изврат натянуть, но не факт. В любом случае, ситуация кардинально не поменяется, и хотя даже такая скорость вполне приличная, всё же её будет недостаточно в боевых условиях.
Вертикально масштабировать свой десктоп мне уже некуда. Он уже итак изрядно отмасштабирован, поэтому остаётся только уповать на горизонталь. По моему скромному разумению, здесь могут быть два пути: разделяемая память (и т.п.) или сокеты. В случае первого варианта имеем высокую производительность при обмене информацией между процессами вебсервера, но тогда ограничены одной машиной. Вариант с сокетами относительно медленный в "общении" instances вебсерверов между собой, но получается более предпочтительным. Например в этом случае можно было бы использовать два и более связанных между собой VPS. Если в определённый момент возникнет ситуация, когда уже поступивших и продолжающих поступать на обработку запросов становится слишком много, то часть из них может быть автоматом спроксирована на параллельный узел. Протокол общения между хостами будет тот же HTTP, и каждый из вебсерверов сможет быть мастером (multi-master). Вроде всё идеально, но вероятно какие-то подводные камни при таком подходе существуют. О каких технических нюансах имеет смысл задуматься, и... вообще будет ли оправдано такое решение соответствующим увеличением производительности системы? З.Ы. Пожалуйста, не приводите снова в пример связку с nginx и т.п. Я в курсе про это (несколько форумных страниц запечатлелись в памяти надолго :) ), и сделать сие можно хоть сейчас (благо и писать-то ничего не надо боле), и именно потому оно не интересно. Правда-матка в том, что велосипедостроение в купе с академическим интересом не предполагают использование уже наличествующих вариантов. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: V1KT0P от Май 23, 2012, 15:50 Передумал "приостанавливаться". Довёл скорость до 3500 RPS на 1000 одновременных запросов, однако это, похоже, уже высшая точка. Ну может быть ещё пол-тысячи запросов удастся через какой-нибудь изврат натянуть, но не факт. В любом случае, ситуация кардинально не поменяется, и хотя даже такая скорость вполне приличная, всё же её будет недостаточно в боевых условиях. Ты же QTcpSocket используешь? Они не такие быстрые как хотелось, я уже пробовал. В итоге взял библиотеку asio и не пожалел.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 23, 2012, 16:04 Ты же QTcpSocket используешь? Они не такие быстрые как хотелось, я уже пробовал. В итоге взял библиотеку asio и не пожалел. Не в бровь, а в глаз. Были сомнения, что что-то не то. Спасибо за совет.Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 28, 2012, 12:29 Перевёл сервер на epoll. Результат порадовал:
Код: ab -n1000 -c1000 http://78.81.31.38:8080/html Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 28, 2012, 12:41 Что-то я не понял с этим тестером апачевским. Это как вообще?
Код: ab -n2000 -c2000 http://78.81.31.38:8080/html Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 30, 2012, 06:03 Цитировать Concurrency Level: 1000 Time taken for tests: 0.162 seconds Concurrency Level: 2000 Time taken for tests: 0.328 seconds А RPS и не должно было вырости, т.к. с увеличением конкурентности количество обрабатываемых в единицу времени запросов не увеличилось. И как видно из приведенных цифр, время выполнения выросло в 2 раза ровно. Отсюда можно предположить вывод, что при текущем железе и ПО максимальная производительность в районе 6000 запросов. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: fuCtor от Май 30, 2012, 06:05 Что-то я не понял с этим тестером апачевским. Это как вообще? Запросов в два раза больше, вроде и среднее время на запрос увеличилось, а скорость таже - 6000 RPS Нужно смотреть на: Time per request: 0.164 [ms] (mean, across all concurrent requests) он показывает сколько времени на один запрос тратится, в обоих случаях одинаков. Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Май 30, 2012, 07:36 Понял, спасибо. Самое интересное, что если увеличить общее количество запросов при тех же 1000 конкурентных, то среднее время на запрос меньше:
Код: ab -n10000 -c1000 http://78.81.31.38:8080/html Название: Re: [РЕШЕНО] Вебсервер: логика маршрутизации Отправлено: alexis031182 от Июнь 22, 2012, 18:36 Еще немного, ещё чуть-чуть. Последний бой - он трудный самый.
Код: ab -n1000 -c1000 http://78.81.31.38:8080/html |