Biblioteca del servidor http embebible en tiempo real

Después de haber examinado varias bibliotecas de servidor http disponibles, todavía no he encontrado lo que estoy buscando y estoy seguro de que no puedo ser el primero en tener este conjunto de requisitos.Biblioteca del servidor http embebible en tiempo real

Necesito una biblioteca que presenta una API que es 'pipeline'. La canalización se usa para describir una función HTTP donde se pueden enviar múltiples solicitudes HTTP a través de un enlace TCP a la vez sin esperar una respuesta. Quiero una característica similar en la API de la biblioteca, donde mi aplicación puede recibir todas esas solicitudes sin tener que enviar una respuesta (responderé pero quiero la capacidad de procesar múltiples solicitudes a la vez para reducir el impacto de la latencia interna).

Así que la biblioteca de servidor web tendrá que soportar el siguiente flujo

1) de cliente HTTP transmite petición http 1

2) de cliente HTTP transmite petición http 2 ...

3) Web Biblioteca servidor recibe la solicitud 1 y lo pasa al servidor de aplicación web de Mi

4) Mi web del servidor de aplicaciones recibe la solicitud y envía 1 a mi sistema

5) Web Server recibe solicitud 2 y lo pasa a mi servidor Web App

6) Mi Servidor Web App recibe solicitud 2 y despacha a mi sistema

7) Mi Servidor Web App recibe respuesta a la solicitud 1 de mi sistema y la envía al servidor web

8) Server web transmite la respuesta HTTP 1 a cliente HTTP

9) Mi servidor web App recibe respuesta a la solicitud 2 de mi sistema y la envía al servidor web

10) El servidor web transmite la respuesta HTTP 2 al cliente HTTP

Espero que esto ilustre mi requisito. Hay dos puntos clave para reconocer. Las respuestas a la biblioteca del servidor web son asíncronas y puede haber varias solicitudes HTTP pasadas a la aplicación de servidor My Web con respuestas pendientes.

requisitos adicionales son

insertable en una aplicación existente 'C'
Pequeña huella; No necesito toda la funcionalidad disponible en Apache, etc.
Eficiente; deberá admitir miles de solicitudes por segundo
Permite respuestas asíncronas a las solicitudes; su es una pequeña latencia para las respuestas y dado el rendimiento de solicitud requerido, una arquitectura sincrónica no me va a funcionar.
de apoyo conexiones TCP persistentes
Soporte con conexiones Comet servidor push-
Open Source/GPL
soporte para HTTPS
portable a través de Linux, Windows; preferiblemente más.

estaré muy agradecido por cualquier recomendación

Saludos

Fuente

2010-02-09 Howard May

Si está utilizando una única conexión, entonces está utilizando la canalización HTTP que requiere que las respuestas se envíen en el mismo orden que las solicitudes, por lo que presumiblemente el manejo paralelo de las solicitudes no le ganaría mucho de todos modos. –

Hola, Christopher, gracias por tomar el temporizador para comentar. Mi sistema recibe una gran cantidad de solicitudes en una sola conexión y tiene una pequeña latencia para responder a estas solicitudes. Si tengo que procesar las solicitudes secuencialmente, esto obliga a un límite en el rendimiento max_throughput = 1/latencia. Si puedo procesar múltiples solicitudes simultáneamente, entonces este límite desaparece. Nota: la latencia es interna para mi sistema y no entre el cliente HTTP y el servidor web. –

usted podría intentar libmicrohttp.

Fuente

2010-02-09 17:33:31

libmicrohttp no parece permitir el modo de operación que necesito. Necesito procesar solicitudes múltiples a través de una única conexión simultáneamente. libmicrohttp no parece permitir esto, independientemente del modelo de subprocesamiento. ¿Puedes confirmar mi entendimiento? –

Suponiendo que está dando un significado a la canalización, esto podría ser relevante: http://www.themes.freshmeat.net/projects/libmicrohttpd/releases/270855 No sé si procesará solicitudes segmentadas simultáneamente, pero DEBERÍA admitir canalización para solicitudes GET y HEAD. –

@Howard, creo que permite el modo de operación que necesita, si asumo que los hilos paralelos pueden ayudarlo. (No soy fanático de los hilos en general, pero a veces son útiles.) –

Lo que desea es algo que admita HTTP pipelining. Debe familiarizarse con esa página si aún no lo está.

Sí, vaya por libmicrohttp. Tiene soporte para SSL, etc. y funciona tanto en Unix como en Windows.

Sin embargo, Christopher está justo en el lugar en su comentario. Si tienes un tiempo de inicio para cada respuesta, no vas a ganar mucho mediante la canalización. Sin embargo, si solo tiene un tiempo de respuesta significativo a la primera solicitud, puede ganar algo.

Por otro lado, si cada respuesta tiene un tiempo de inicio, puede ganar un lote por no usando canalización, pero cree una nueva solicitud para cada objeto. Entonces cada solicitud puede tener su propio hilo, absorbiendo los costos de inicio en paralelo. Todas las respuestas se enviarán "a la vez" en el caso óptimo. libmicrohttp admite este modo de operación en su modelo de subproceso MHD_USE_THREAD_PER_CONNECTION.

Fuente

2010-02-10 11:56:29

Gracias Sr. Kant. Como se explicó anteriormente, aunque el pipeline es necesario, no es suficiente. Necesito algo que permita que mi aplicación/sistema utilizando la biblioteca pueda procesar solicitudes múltiples simultáneamente. No creo que libmicrohttp lo haga. –

Respuesta actualizada con un nuevo párrafo en la parte inferior. –

El seguimiento de los comentarios y las actualizaciones anteriores ...

usted no dice cuántas conexiones simultáneas que tendrá, pero sólo "un enlace TCP".
Si se trata de una conexión única, utilizará la canalización de HTTP como se mencionó anteriormente; por lo que solo necesitaría un puñado de hilos — en lugar de miles — para procesar las solicitudes al principio de la tubería.

Así que no necesitaría tener un hilo para cada solicitud; solo un pequeño grupo de trabajadores para cada conexión.

¿Ha realizado alguna prueba o implementación hasta el momento para mostrar si realmente tiene problemas con la latencia de respuesta para las conexiones en derivación?
Si su dispositivo incrustado es lo suficientemente potente como para hacer frente a miles de solicitudes por segundo, incluida la configuración de TLS, el cifrado y el descifrado, me preocuparía la optimización prematura en este nivel.

Fuente

2010-02-12 14:37:04

Gracias por sus comentarios Christopher. Puedo tener del orden de 10 clientes conectados, cada uno de los cuales colocará una gran carga en el sistema. La latencia está dentro de mi sistema. Estoy colocando una interfaz web en un sistema existente basado en un mensaje que pasa la comunicación. La latencia es el tiempo entre recibir una solicitud HTTP y enviar una respuesta HTTP. A menos que pueda recibir múltiples solicitudes de una conexión TCP a la vez, cada conexión TCP estará restringida a una tasa de 1/latencia. Sé que esto no cumplirá con mis requisitos, así que necesito abordarlo ahora. –

Howard,

¿Ha echado un vistazo a lighthttpd? Cumple con todos sus requisitos, excepto que no es explícitamente un servidor web incorporado. Pero es de código abierto y compilarlo en su aplicación no debería ser demasiado difícil. A continuación, puede escribir un plugin personalizado para manejar sus solicitudes.

Fuente

2010-02-19 00:24:53

No puedo creer que nadie haya mencionado nginx. He leído grandes porciones del código fuente y es extremadamente modular. Probablemente puedas obtener las piezas que necesitas para trabajar bastante rápido.

Fuente

2010-02-19 10:10:07

uIP o lwip podrían funcionar para usted. Yo personalmente uso uIP. Es bueno para un pequeño número de clientes y conexiones concurrentes (o como usted lo llama, "pipelining"). Sin embargo, no es tan escalable ni tan rápido como para servir contenido como lwip por lo que he leído. Fui con simplicidad y tamaño pequeño de uIP en lugar de la potencia de lwip, ya que mi aplicación generalmente solo tiene 1 usuario.

He encontrado uIP bastante limitado a medida que aumentan las conexiones simultáneas.Sin embargo, estoy seguro de que esa es una limitación de mis búferes de recepción de MAC disponibles y no de uIP. Creo que lwip usa mucha más memoria de alguna forma para evitar esto. Simplemente no tengo suficiente RAM de ethernet para soportar la llegada de una tonelada de paquetes de solicitud. Dicho esto, puedo hacer una encuesta ajax de fondo con una latencia de 15ms en un procesador de 56mhz.

http://www.sics.se/~adam/software.html

De hecho, he modificado uIP de varias maneras. Agregar un servidor DHCP y admitir POST multiparte para subir archivos son las cosas más importantes). Avíseme si tiene alguna pregunta.

Fuente

2010-05-12 18:50:53

Utilice Onion, Luke. Esta es una biblioteca de servidor HTTP ligera y fácil de usar en C.

Fuente

2013-05-04 18:52:46 puchu

Para referencia futura, que cumpla con sus requisitos, eche un vistazo a libasyncd Soy uno de los contribuyentes.

insertable en una aplicación existente 'C'

Está escrito en C.

Pequeña huella; No necesito toda la funcionalidad disponible en Apache, etc.

Muy compacto.

Eficiente; tendrá que admitir miles de solicitudes por segundo

Es marco basado en libevent. Puede manejar más que eso.

Permite respuestas asincrónicas a las solicitudes;

Es asincrónico. También soporte pipelining.

de apoyo conexiones TCP persistentes

Claro, keep-alive.

uso de la ayuda con las conexiones Comet servidor push-

Todo depende de cómo se codifican los lógica.

Open Source/GPL

bajo licencia BSD

soporte para HTTPS

Sí. es compatible con https con openssl.

Portátil en linux, windows; preferiblemente más.

Portátil pero no tiene ventanas en este momento, pero es portátil para Windows.

Fuente

2014-04-12 18:42:29 user3474832

Biblioteca del servidor http embebible en tiempo real

Respuesta

Cuestiones relacionadas