Сайты, работающие на nxweb, уже не раз бывали под DDoS'ом – успешно его отбивали (хотя DDoS тоже бывает разный), в т.ч. благодаря кешированию. Не знаю, пытались ли их взломать, но и не слышал о том, чтобы это кому-то удалось.
Разумеется, я думал о безопасности, когда писал код, но уязвимости можно найти всегда в любом коде. Обязательно их устраню, когда обнаружатся.
Принцип работы веб-сервера прост, и реализовать его несложно. Есть работающие примеры буквально из 100 строк кода. Но, как хорошо видно из Вашего поста, нюансов там несметное множество. А если захочется сделать на собственном сервере полноценный веб-сайт (со статикой, бекендом, SSI, gzip-компрессией, кешированием, ...) то придется много еще чего доделать. Вот так и я, начал с самого простого, в итоге за несколько лет пришел к тому, что есть сейчас.
Из обработчика, работающего в отдельном потоке (worker thread), в т.ч. Python, это пока не реализовано. Worker должен вернуть серверу весь ответ целиком.
Для асинхронных модулей на C такого ограничения нет, но написание асинхронных модулей – задача нетривиальная. Нужно интегрироваться в event loop сервера. В т.ч. нужно асинхронно мониторить источник информации, сигнализирующий о необходимости отправки клиентам новых пакетов данных.
Я – разработчик nxweb. Данная статья была написана в декабре 2011 года, но почему-то только сейчас вышла из песочницы. Через три с половиной года. Попытаюсь немного освежить информацию.
За прошедшее время nxweb оброс немалым функционалом:
http-proxy (удобно для Java)
встроенный Python
шаблоны страниц с наследованием блоков
SSL
файловый кеш ответов бекенда
кешируемое gzip-сжатие
масштабирование изображений
конфиг-файл в формате json
подгружаемые модули
access log
...
При этом он достаточно стабилен, давно использую его как фронтенд. На некоторых сайтах работает год и больше без перезапуска.
Кстати, вот официальный сайт: nxweb.org. Работает на nxweb + своя CMS на Python. Там, правда, в русской версии практически ничего не написано, но в английской есть несколько статей для быстрого старта.
А вот и прощальный аккорд упал только что на почту (орфография сохранена):
Мы пытались, но у нас ни чего не получилось :(
Просим прощения, у всех наших пользователей, за то что не смогли представить вам качественный сервис. Мы уходим… А проект будет закрыт.
Если вы делали бекапы в панели управления, то по запросу в тикет систему, мы предоставим ссылку на их скачивание.
Уважаемые пользователи, мы рекомендуем использовать сервера от компании флопс, они хорошие ребята и давно зарекомендовали себя на рынке.
Как и следовало ожидать, внесенные перед аварией на счет и неизрасходованные деньги CloudMouse мне так и не вернул. Сначала пообещали вернуть в течение недели, но потом просто перестали отвечать на письма.
Вот такой бесславный конец, казалось бы, перспективного хостинг-провайдера.
Кстати, есть еще более интересная бизнес-модель: такси, где клиент сам назначает цену. Реально работающий сервис — Таксометра.нет.
Благодаря ему, я начал пользоваться такси, до этого ловил попутки. Главный плюс для меня — отсутствие счетчика, цена заранее установлена, и никаких сюрпризов.
Как было уже отмечено, смысл забастовки — привлечь внимание. Реальная забастовка, если и была, то была совсем не массовой и вообще незаметной для рынка, но СМИ тему подняли. И кто выиграл от этого информационного вброса? Забастовщики??? Вы сами усомнились в этом.
Читал ранее новость о том, что после забастовки лондонских таксистов против Uber число заказов Uber резко возросло, чуть ли не в 10 раз.
Полагаю, что такие «забастовки» — это и есть одна из тактик Uber. До этой «забастовки» я, например, не знал, что Uber уже работает в Москве. Отличный анонс получился — думаю число заказов у них выросло не в 10, а в 100 или 1000 раз.
Ну, это если платил через visa/mc. Я же платил через ЯД.
И не факт, что основания для чарджбека имеются. Чарджбек обоснован, если у вас списали средства без должного подтверждения с вашей стороны. А тут есть все цифровые протоколы, формально подтверждающие, что платеж был выполнен вами лично.
Взыскание средств за некачественно оказанные услуги — это не по банковской части.
Потерял два рабочих сервера. Опираясь на собственные ощущения, могу предположить, что никто новые сервера пересоздавать у них теперь не захочет. Наоборот, все захотят вернуть хотя бы неизрасходованные средства со счета. Я написал запрос на возврат, но ответа пока нет. Не удивлюсь, если его и не будет.
Перспективы у них теперь нулевые. Наиболее вероятный вариант — перезапуск проекта под новым именем, всячески маскируя связь со старым CloudMouse. Нужно быть бдительным.
Простите, но не понял, за что минуса. Это какая-то запретная тема? Они кого-то сильно «нагрели»? Дайте пару ссылочек, чтобы и я был в курсе. Я их сейчас и клиентам рекомендую.
В CloudMouse потерял два рабочих сервера. У меня такое впервые за 15 лет пользования услугами разных хостеров. Резко возник интерес к отзывами о других провайдерах.
Так как я достаточно давно пишу не только на Java, но и на C, могу сказать по личному опыту, что разница в скорости обычно измеряется коэффициентом от 2 до 10. Наверное что-то можно отыграть с помощью более эффективных алгоритмов, но если переложить те же алгоритмы на C, все равно получится в несколько раз быстрее. Хотя, опять же, это обобщение, а занчит, со всемы вытекающими оговорками.
И меня обычно тоже не устраивают стандартные решения. Сам я Varnish так ни разу в деле и не попробовал. Но по идее он должен помочь.
А в целом, спасибо за интересную статью. Давно пишу на Java, но мне бы и в голову не пришло решать на ней такие задачи. Вы расширили мой кругозор, за что премного благодарен.
Согласен, конечно. Смысл в другом. Мой тест показывает, что издержки на out-of-process могут составлять (на моем компьютере) лишь порядка 3 мкс. Понятно, что это может оказаться не совсем так на практике, надо проверять, но я веду к другому. Не стоит принимать за аксиому то, что кеш обязан быть in-process, чтобы справиться с указанной нагрузкой.
А еще ведь можно запустить какой-нибудь Varnish в режиме malloc (чтобы кешировал в ОЗУ), а позади него поставить tomcat, который будет в случае непопадания в кеш подтягивать недостающий контент из хранилища. Не улучшит ли это результат? Причем значительно, так как большую часть запросов будет отрабать C-код, а не Java.
Ну, командная строка (точнее утилита измерения числа запросов в секунду) — она по отношению к http-серверу, как бы, не in-process, но работает достаточно быстро.
Показывает, что вызов чего-то быстрого out-of-process не должен стать узким местом при указанной частоте запросов и пропускной способности. Сокет на том же хосте работает достаточно быстро.
Вот тут посмотрите пример для Flask, Django будет отличаться лишь параметром:
Сайты, работающие на nxweb, уже не раз бывали под DDoS'ом – успешно его отбивали (хотя DDoS тоже бывает разный), в т.ч. благодаря кешированию. Не знаю, пытались ли их взломать, но и не слышал о том, чтобы это кому-то удалось.
Разумеется, я думал о безопасности, когда писал код, но уязвимости можно найти всегда в любом коде. Обязательно их устраню, когда обнаружатся.
Для асинхронных модулей на C такого ограничения нет, но написание асинхронных модулей – задача нетривиальная. Нужно интегрироваться в event loop сервера. В т.ч. нужно асинхронно мониторить источник информации, сигнализирующий о необходимости отправки клиентам новых пакетов данных.
За прошедшее время nxweb оброс немалым функционалом:
При этом он достаточно стабилен, давно использую его как фронтенд. На некоторых сайтах работает год и больше без перезапуска.
Кстати, вот официальный сайт: nxweb.org. Работает на nxweb + своя CMS на Python. Там, правда, в русской версии практически ничего не написано, но в английской есть несколько статей для быстрого старта.
Вот такой бесславный конец, казалось бы, перспективного хостинг-провайдера.
Благодаря ему, я начал пользоваться такси, до этого ловил попутки. Главный плюс для меня — отсутствие счетчика, цена заранее установлена, и никаких сюрпризов.
Читал ранее новость о том, что после забастовки лондонских таксистов против Uber число заказов Uber резко возросло, чуть ли не в 10 раз.
Полагаю, что такие «забастовки» — это и есть одна из тактик Uber. До этой «забастовки» я, например, не знал, что Uber уже работает в Москве. Отличный анонс получился — думаю число заказов у них выросло не в 10, а в 100 или 1000 раз.
И не факт, что основания для чарджбека имеются. Чарджбек обоснован, если у вас списали средства без должного подтверждения с вашей стороны. А тут есть все цифровые протоколы, формально подтверждающие, что платеж был выполнен вами лично.
Взыскание средств за некачественно оказанные услуги — это не по банковской части.
Перспективы у них теперь нулевые. Наиболее вероятный вариант — перезапуск проекта под новым именем, всячески маскируя связь со старым CloudMouse. Нужно быть бдительным.
В CloudMouse потерял два рабочих сервера. У меня такое впервые за 15 лет пользования услугами разных хостеров. Резко возник интерес к отзывами о других провайдерах.
И меня обычно тоже не устраивают стандартные решения. Сам я Varnish так ни разу в деле и не попробовал. Но по идее он должен помочь.
Показывает, что вызов чего-то быстрого out-of-process не должен стать узким местом при указанной частоте запросов и пропускной способности. Сокет на том же хосте работает достаточно быстро.