servidores - servidor web de aplicaciones de alto rendimiento en C/C++

servidor de aplicaciones vs servidor web (5)

¿Hay algún servidor web de alto rendimiento (idealmente codiciado y de código abierto) en C o C ++?

Me gustaría poder usarlo en el sentido de que llama a un método / función en mi aplicación con una clase / estructura de solicitud HTTP completa, y luego puedo devolverle una clase / estructura de respuesta HTTP completa.

Si no es de código abierto, necesitaría soporte integrado para conexiones de larga duración, keep-alive, etc. De lo contrario, creo que puedo agregar estas cosas yo mismo.

Si no sabe de ninguno de esos servidores disponibles, ¿me recomendaría escribir mi propio servidor web para que se ajuste a la tarea? No puede estar basado en archivos y debe escribirse en C / C ++ de alto rendimiento.

Edit: estoy pensando algo así como Ruby Mongrel para C, si eso ayuda.

Soy un ávido usuario de nginx ; nginx está escrito en C; nginx parece que podría funcionar para ti. Si quieres la mejor velocidad de nginx, crearía un módulo nginx. Aquí hay módulos de terceros que puede examinar para tener una idea de lo que requiere.

En cuanto al requisito de sondeo largo, es posible que desee echar un vistazo a los módulos de inserción http.

Sugeriría escribir un ejecutable FastCGI que pueda usarse con muchos servidores web de alto rendimiento (incluso los de código cerrado).

Tenía los mismos requisitos para mi trabajo, así que evalué una serie de soluciones: mangosta, libmicrohttpd, libevent. Y también estaba pensando en escribir módulos nginx. Aquí está el resumen de mis hallazgos:

nginx

página del proyecto nginx

Amo este servidor y lo uso mucho. Su rendimiento y uso de recursos es mucho mejor que el de Apache, que también sigo usando, pero planea migrar a nginx.

Muy buen rendimiento sintonizable. Funcionalidad rica Portabilidad.
El Módulo API no está documentado y parece ser muy detallado. Vea este módulo nginx hello world como ejemplo.
Nginx no usa hilos pero usa múltiples procesos. Esto hace que escribir módulos sea más difícil, necesita aprender nginx API para memoria compartida, etc.

mangosta

página de proyecto de mangosta

El código de todo el servidor está en el archivo mongoose.c (aproximadamente 130K), sin dependencias. Esto es bueno.
Un hilo por conexión, por lo que si necesita concurrencia, debe configurar muchos hilos, es decir. alto uso de RAM. No muy bien.
El rendimiento es bueno, aunque no excepcional.
La API es simple, pero debes compilar todos los encabezados HTTP de respuesta, es decir. aprende el protocolo HTTP en detalle.

libmicrohttpd

página del proyecto libmicrohttpd

Proyecto oficial de GNU.
La API Verbose, me parece incómoda, aunque es mucho más simple que escribir módulos nginx.
Buen rendimiento en modo keep-alive (enlace a mis benchmarks a continuación), no tan bueno sin keep-alive.

liberante

página del proyecto libevent

La biblioteca Libevent tiene un servidor web incorporado llamado evhttp.

Está basado en eventos, usa libevent para eso.
API fácil Construye encabezados HTTP automáticamente.
Oficialmente de un solo hilo. Esta es una gran desventaja. Encontré un hack , que hace que varias instancias de evhttp se ejecuten simultáneamente aceptando conexiones del mismo socket. No estoy seguro si todo es seguro y robusto.
El rendimiento de evhttp de subproceso único es sorprendentemente pobre. El hack de subprocesos múltiples funciona mejor, pero aún no es bueno.

G-WAN

El proyecto G-WAN no es de código abierto, pero me gustaría decir algunas palabras al respecto.

Muy buen rendimiento, bajo uso de memoria, 150 KB ejecutable.
Implementación ''servlet'' muy conveniente: simplemente copie el archivo .c en el directorio csp, y el servidor en ejecución lo compilará automáticamente. Las modificaciones de código también se compilan sobre la marcha.
API simple Aunque limitado de alguna manera. Funcionalidad rica (json, almacén de clave-valor, etc.).
Inestable. Tenía segfaults en archivos estáticos. Se bloquea en algunas secuencias de comandos de muestra. (Experimentado en instalación limpia. Nunca mezcló archivos de diferentes versiones).
~~Solo binario de 32 bits~~ (no más).

Como puede ver, ninguna de las alternativas existentes me ha satisfecho por completo. Así que he desarrollado mi propio servidor, que es ...

NXWEB

Página del proyecto NXWEB

Características destacadas:

Muy buen rendimiento; ver puntos de referencia en la página del proyecto
Puede servir decenas de miles de solicitudes simultáneas
Huella de memoria pequeña
Modelo de subprocesos múltiples diseñado para escalar
Base de código excepcionalmente ligera
API simple
Manejo de protocolo HTTP decente
Conexiones Keep-alive
Soporte SSL (a través de GNUTLS)
HTTP proxy (con la agrupación de conexiones keep-alive)
Compatibilidad con archivos send sin bloqueo (con memoria caché de archivos pequeños configurable; servicio de archivos precodificados gzip)
Diseño modular para desarrolladores
Se puede ejecutar como daemon; se relanza por error
Fuente abierta

Limitaciones

~~Depende de la biblioteca libev~~ (ya no)
Solo probado en Linux

Voy a sugerir lo mismo que Axel Gneiting, pero he proporcionado una respuesta con mis razones para tomar este enfoque:

1) HTTP no es tan trivial como un protocolo: escribir su propio servidor o modificar una solución lista para usar es una tarea muy compleja, mucho más compleja que usar las API disponibles para implementar un motor de procesamiento separado

2) El uso del servidor web mainstream (no modificado) debería proporcionarle más funcionalidades de las que necesita (para que tenga más espacio).

3) El uso de un servidor web convencional (no modificado) generalmente significará que ha sido probado y documentado de forma mucho más exhaustiva que un sistema homebrew.

4) .. y es más probable que sea seguro y estable.

5) Usando fastCGI puede usar todo tipo de idiomas para desarrollar su procesamiento back-end, incluyendo C ++ y C. Hay kits de herramientas estándar disponibles para facilitar esto.

6) alternativamente, muchos servidores web proporcionan soporte para ejecutar motores de intérpretes en proceso (por ejemplo, mod_php, mod_perl). Sin embargo, desaconsejaría ejecutar tu propio código nativo como módulo.

No puede estar basado en archivos.

Eh? Qué significa eso?

mangosta: un archivo. Simple y fácil de usar. no es una frase sino perfecta para propósitos incrustados y particulares.

gwan excelente. no se bloquea configuración ultra bien planificada. muy inteligente y fácil para el desarrollo de c / c ++ en otras palabras, api sensible muy limpio en comparación con nginx. proporciona un hilo por núcleo o lo que sea que especifiques. una gran elección. mayor desventaja (tal vez me falta en esta área): no se puede pasar a través del código.

libevent: un solo hilo no es una desventaja en una sola máquina central. después de todo, su punto es un i / o asíncrono. tiene multiprocesamiento para otros núcleos.

nginx: sin experiencia personal. ganando terreno serio en un servidor irregular. (api terriblemente confuso)

boost asio: una biblioteca de c ++ para asynchio (asio). increíble. necesita una API amigable de alto nivel para simplones como yo. y otros que provienen de php, java, javascript, node.js y otros lenguajes web.

Pitón botella: impresionante 1 archivo lib (framework / sistema) que hace que sea fácil de construir aplicaciones web de Python. tiene / está integrado en un servidor httpd, como libevent y node.js

node.js: javascript asyncio server. una excelente selección. desafortunadamente, tiene que programar en javascript que se vuelve tedioso. mientras que hay algo que decir para hacer el trabajo; también hay algo que decir para divertirse durante el proceso. es de esperar que a nadie se le ocurra node.php