Встроенный веб-сервер со встроенным парсером XML

Question

У меня есть требование для интеграции веб-сервера в встроенное устройство под управлением Linux , и я нахожусь в процессе оценки OSS и коммерческих предложений.

Системные требованияв не очень тесном: - Память с рабочим набором до 10 МБ, - Может сэкономить 20% + от ARM 300 МГц и более в пакетах, - Пользовательский интерфейс будет в jQuery и JSON, поэтому хотел бы кормить несколько сотен страниц КБ, связывающих дюжинуФайлы CSS и JS заняли меньше секунды.

Требования к функциям: - поддержка HTTPS, - 10+ одновременных подключений, - хорошо протестированы на DOS-атаках.

Очень понравилось бы интегрированный синтаксический анализатор XML, на котором базируется реализация SOAP.

Не фанат PHP, но также не уверен в серверном Javascript и не знаком с Lua.Поэтому ищите предложения для шаблонных решений, возможно, стека на основе Python.

Уже рассмотрены обсуждения списков SO и в Википедии .Я в курсе thttpd , Mongoose , Cherokee , Appweb .

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

Answer 1

Когда речь идет о простом стеке Python-сервера, наиболее часто встречаемая в сообществе комбинация для облегченной реализации выглядит следующим образом: CherryPy (для предоставления сервера WSGI с пулом) с Werkzeug (для создания базовой структуры приложения) Обе версии WSGI очень незначительно отличаются друг от друга, что значительно ускоряет разработку.

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

Если вы можете позволить себе накладные расходы питонаИнтерпретатор (который, я полагаю, в порядке, поскольку вы включили его в свой список допустимых), werkzeug - отличный способ настроить приложение, состоящее из простых конечных точек.Ответы могут быть встроены в миметип, чтобы помочь в выводе ваших библиотек пользовательского интерфейса (Jquery и т. Д.).В документах Werkzeug есть замечательные примеры.

Один из лучших ресурсов, которые мне удалось найти при сравнении серверов WSGI (чтобы удовлетворить ваши потребности в высоких одновременных соединениях и живучести DOS), можно найти по адресу Сообщение в блоге Николаса Пила на эту тему , где CherryPy считается одним из лучших ресурсов по принципу "удачи по карману" в плане скорости.Сервер WSGI в Cherry готов к развертыванию, и его можно использовать в качестве серверного процесса, обеспечивающего среду для вашего приложения Werkzeug, поэтому вам не нужно реализовывать что-то более тяжелое, например Apache, с mod_wsgi.Cherry легко способен в среднем около 2000 об / с при времени отклика менее секунды при небольшой нагрузке.

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

Путем объединения модуля minidom в Python (v2.6 +)с маршрутизацией конечной точки в Werkzeug вы также должны получить очень хорошую скорость разработки.Создать сложную схему URL-адресов очень просто, используя функцию Werkzeug Map, и руководство на странице документации дает потрясающее краткое изложение этого.Между ними не должно быть слишком сложно запустить и запустить ваш веб-сервис.

Answer 2

Если у вас есть только 10 МБ, то о многих предложениях не может быть и речи: узел и рубин быстро превзойдут этот размер только с небольшим приложением.PHP будет начинаться с минимума около 8 МБ и может быстро перейти к 20 + МБ.Мы видели один сайт с приложением для управления PHP 50 МБ.Определенно, это не лучший выбор для встраиваемых систем, если у вас нет запасных ГБ.

Я использовал Appweb с ESP, который представляет собой инфраструктуру MVC на языке c, и Ejscript, который является Javascript на стороне сервера.Ejscript имеет синтаксический анализатор XML и может обрабатывать требования SOAP.Appweb включает в себя очень простой XML-парсер.Вам понадобится libxml, если вы хотите высокоуровневую обработку SOAP.

Appweb 4 имеет хорошую защиту DOS.Вы можете ограничить количество одновременных запросов от одного клиента с помощью директивы LimitRequestPerClient.LimitParseTimeout также помогает быстро закрывать запросы DOS, которые не заканчивают свои заголовки.В изолированной программной среде безопасности Appweb есть множество директив для вас, чтобы охарактеризовать вашу нагрузку - это помогает для DOS и других угроз безопасности.

Ваш другой выбор - перейти на чистый Javascript и использовать Ejscript, в который встроен механизм Appweb http.это.

Answer 3

Я предполагаю, что целью вашего встроенного веб-сервера является предоставление административного интерфейса для конфигурации, операций и состояния.

Для раскрытия информации наша компания создает и развертывает административные веб-интерфейсы на многих встроенных системах со спецификациями, аналогичнымик тому, что вы описываете на основе нашего продукта, веб.Вы можете узнать больше о нашем подходе на http://uweb.workware.net.au/, и прочитать статью, представленную мною на Embedded Linux Conference 2010 на http://workware.net.au/papers/embedded-scripting.pdf, в которой представлены некоторые подробности того, как мы соотносим проблемы размера и производительности сбыстрое развертывание с помощью сценариев.

У вас есть два широких варианта.Во-первых, использовать инфраструктуру, такую ​​как µWeb, сервер Barracuda (упомянутый выше) или инфраструктуру с открытым исходным кодом, такую ​​как luci (http://luci.subsignal.org/trac).). Во-вторых, использовать облегченный веб-сервер, такой как упомянутый выше, изатем создайте свой собственный фреймворк (предположительно, на основе jQuery и JSON). Второй вариант займет значительно больше времени, и безопасность вызывает беспокойство при рассмотрении атак XSS, CRSF и DOS.

В любом случае я настоятельно рекомендую вамдержитесь подальше от PHP, Python или Javascript на стороне сервера. Все они слишком ресурсоемки для 300-МГц ARM-платформы.

Зачем нужны XML и SOAP, если пользовательский интерфейс администратора будет jQuery и JSON?у вас есть отдельное требование для поддержки SOAP? Если это так, gSOAP, вероятно, является разумным выбором (прошло несколько лет с тех пор, как я последний раз использовал его).

Что касается https и 10+ одновременных сессий, обратите внимание, что первоначальный SSLрукопожатие требует значительных ресурсов и встроенной платформы. Если вы создаете новый запросЧасто (либо из-за новых сессий, либо из-за того, что запросы не передаются по конвейеру) платформа будет испытывать трудности.Вероятно, вы можете установить только 1-2 SSL-соединения в секунду.

Answer 4

Вы должны решить, какие технологии на стороне сервера вы бы использовали в первую очередь.Для встраиваемой системы у вас серьезные ограничения по ресурсам, поэтому убедитесь, что вы выбираете легковесные технологии соответственно!Сказав, что Node.js - отличная технология (http://nodejs.org/), на которую вы можете обратить внимание. Я также видел некоторые реализации SOAP для нее. С другой стороны, разработка на основе JavaScript может быть очень грязной! Выможете попробовать разные решения и начать тестировать функциональное поведение вашей системы, используя такие инструменты, как JMeter (http://jmeter.apache.org).

. Некоторые из предложений: Настройте облегченный http-сервер (например, Cherokee, lighttpd и т. д.) во встроенномсистемы, затем настройте PHP (PHP также имеет некоторые инструменты SOAP). Позже замените PHP с помощью решения Python или Ruby (например, встроенного Mongrel и т. д.). Узнайте, как ваша система ведет себя при большой нагрузке, используя JMeter.