Servidor web incorporado con analizador XML integrado

Question

Tengo un requisito para integrar un servidor web en un dispositivo incrustado que ejecuta Linux y estoy en el proceso de evaluar OSS y ofertas comerciales.

Requerimientos del sistema no especialmente ajustados: - Memoria funcionando con un conjunto de hasta 10MB, - Puede ahorrar el 20% + de un ARM de 300MHz y más en ráfagas, - La interfaz de usuario estará en jQuery y JSON, por lo tanto le gustaría alimentar varios cientos de páginas KB que unen una docena de archivos CSS y JS en menos de un segundo.

Requisitos de características: - Soporte HTTPS, - A más de 10 conexiones concurrentes, - Bien probado contra ataques DOS.

apreciaría mucho un analizador XML integrado en el que basar la implementación de SOAP.

No soy fanático de PHP, pero tampoco estoy seguro acerca del Javascript del lado del servidor y no estoy familiarizado con Lua. Así que buscamos sugerencias para soluciones de plantillas, tal vez una pila basada en Python.

Ya revisado discussions on SO y lists on Wikipedia. Estoy al tanto de thttpd, Mongoose, Cherokee, Appweb.

En este punto invito técnico detallado sugerencias y discusión de las opciones de implementación, basadas en la experiencia de primera mano en la implementación de calidad de producción.

Answer 1

Cuando se trata de un simple servidor de pila pitón, la combinación que he oído más a menudo dentro de la comunidad para la implementación de peso ligero es CherryPy (para proporcionar el servidor WSGI hilo combinado) con Werkzeug (para crear la estructura básica de la aplicación). Ambas son tomas muy diferentes en WSGI que aceleran considerablemente el tiempo de desarrollo.

Hay algunas muy buenas notas que describen comparaciones marco pitón básicas (aunque no en un entorno integrado, pero el énfasis se puso en los despliegues de peso ligero.) at this question, in which Alex "the Machine" Martelli weighed in for these two.

Si usted puede permitirse los gastos generales de la intérprete de Python (que soy asumiendo que está bien ya que lo incluyó en su lista elegible), werkzeug es una excelente manera de configurar una aplicación que consta de puntos finales simples. Las respuestas pueden mimetizarse en línea para ayudar a generar sus librerías de interfaz de usuario (Jquery, etc.). Hay ejemplos asombrosos en los documentos de Werkzeug.

Uno de los mejores recursos que he podido encontrar al comparar servidores WSGI (para satisfacer su necesidad de altas conexiones concurrentes y supervivencia de DOS) se puede encontrar en Nicholas Piel's blog post on the subject, donde CherryPy se clasifica como uno de los mejores "bang" -for-your-buck "recursos a la velocidad. El servidor WSGI en Cherry está listo para el despliegue, y esto puede usarse como el proceso del servidor que proporciona el entorno a su aplicación Werkzeug para que no necesite implementar algo más pesado como Apache con mod_wsgi. Cherry es fácilmente capaz de un promedio de alrededor de 2000 r/ps con tiempos de respuesta bien por debajo de un segundo bajo una carga moderada.

Como no sé en qué tipo de dispositivo implementará esto, debería mencionar, por supuesto, que ambas plataformas se actualizan regularmente, por lo que esto también debe considerarse si por alguna razón se asignan recursos de red para actualizar el dispositivo no es práctico.

Al combinar el módulo minidom de python (v2.6 +) con el enrutamiento del punto final en Werkzeug, también debería beneficiarse de una muy buena velocidad de desarrollo. Construir un esquema de url complejo es simple usando la característica Map de Werkzeug, y el tutorial en su página de documentación brinda un resumen impresionante sobre esto. Entre los dos, no debería ser demasiado difícil poner en marcha su servicio web.

Answer 2

Tiene que decidir qué tecnologías del lado del servidor usaría primero. Para un sistema integrado, tiene severas limitaciones de recursos, ¡así que asegúrese de seleccionar las tecnologías de peso liviano en consecuencia! Habiendo dicho que Node.js es una gran tecnología (http://nodejs.org/) es posible que desee prestar atención. También he visto algunas implementaciones de SOAP. Por otro lado, el desarrollo basado en JavaScript podría ser muy complicado. Puede probar diferentes soluciones y comenzar a probar el comportamiento funcional de su sistema usando herramientas como JMeter (http://jmeter.apache.org).

Algunas de las sugerencias: Configure un servidor http liviano (como Cherokee, lighttpd, etc.) en su sistema integrado, luego configure PHP (PHP también tiene algunas herramientas SOAP). Luego cambie PHP con una solución Python o Ruby (como Mongrel incrustado, etc.). Descubra cómo se comporta su sistema con cargas pesadas utilizando JMeter.

Answer 3

Supongo que el propósito de su servidor web incorporado es proporcionar una interfaz administrativa para la configuración, las operaciones y el estado.

Para su divulgación, nuestra compañía construye e implementa interfaces web administrativas en muchos sistemas integrados con especificaciones similares a las que describe según nuestro producto, Web. Puede encontrar más información sobre nuestro enfoque en http://uweb.workware.net.au/, y se puede leer un papel presenté en la Conferencia Embedded Linux 2010 en http://workware.net.au/papers/embedded-scripting.pdf que proporciona algún detalle de cómo equilibrar el tamaño y el rendimiento se refiere con un despliegue rápido a través de secuencias de comandos .

Tiene dos opciones amplias. El primero es usar un marco como μWeb o el servidor Barracuda (mencionado anteriormente), o un marco de código abierto como luci (http://luci.subsignal.org/trac). El segundo es para usar un servidor web liviano como los mencionados anteriormente y luego construir su propio marco (supuestamente basado en jQuery y JSON). La segunda opción tomará mucho más tiempo y la seguridad es una preocupación a medida que aborda los ataques XSS, CRSF y DOS.

En cualquier caso, le sugiero que se mantenga alejado de PHP, Python o del lado del servidor Javascript. Todos ellos tienen demasiados recursos para una plataforma ARM 300MHz.

¿Por qué el requisito de XML y SOAP si su interfaz de usuario de administrador va a ser jQuery y JSON? ¿Tiene un requisito separado para el soporte SOAP ? Si es así, es probable que GSOAP sea una elección razonable (ha sido hace unos años desde la última vez que lo usé).

En cuanto a https y más de 10 sesiones simultáneas, tenga en cuenta que el protocolo de enlace inicial de SSL requiere una gran cantidad de recursos y una plataforma integrada. Si es estableciendo nuevas solicitudes con frecuencia (ya sea debido a sesiones nuevas, o porque las solicitudes no están canalizadas), la plataforma tendrá dificultades. Probablemente solo establezca 1-2 conexiones SSL por segundo.

Answer 4

Si solo tiene 10MB, muchas de las sugerencias están descartadas: node y ruby ​​superarán rápidamente esta huella con solo una pequeña aplicación. PHP comenzará en aproximadamente 8 MB mínimo y puede ir rápidamente a 20 + MB. Hemos visto un sitio con una aplicación de administración de PHP de 50MB. Definitivamente no es una buena opción para incrustado a menos que tengas GB de sobra.

He utilizado Appweb con ESP, que es un framework MVC de lenguaje c y Ejscript, que es Javascript para servidor. Ejscript tiene un analizador XML y puede manejar el requisito SOAP. Appweb incluye un analizador XML muy básico. Necesitará libxml si desea un manejo de SOAP de alto nivel.

Appweb 4 tiene buenas protecciones para DOS. Puede limitar el número de solicitudes simultáneas de un solo cliente con la directiva LimitRequestPerClient. LimitParseTimeout también ayuda a cerrar rápidamente las solicitudes de DOS que no concluyen sus encabezados. El entorno limitado de seguridad Appweb tiene muchas directivas para que pueda caracterizar su carga; esto ayuda a DOS y otras amenazas de seguridad.

Su otra opción sería ir a Javascript puro y usar Ejscript, que tiene el motor http Appweb integrado.