NGINX vs. Apache: Cómo Elegir el Mejor Servidor Web

Imagina esto: estás buscando unas zapatillas nuevas, encuentras una buena oferta y decides revisarla en el sitio web.

Esperas 10 segundos… 20 segundos… y el sitio simplemente no carga. Te cansaste de esperar, así que te vas a otro sitio. Esto es lo que probablemente pasó: el sitio web de las zapatillas probablemente invirtió mucho tiempo y dinero en imágenes llamativas y diseños elegantes, pero todo es en vano si tarda una eternidad en cargar.

Internet está lleno de sitios web lentos.

La página de destino promedio en móviles tarda 22 segundos en cargar, y eso es terrible para los negocios.

Un estudio de Portent encontró que un sitio que carga en menos de un segundo tiene una tasa de conversión tres veces mayor que un sitio que tarda cinco segundos en cargar.

Ahora, ¿qué tiene esto que ver con nuestra comparación entre NGINX y Apache?

Un factor importante que afecta la velocidad del sitio es tu servidor web: el software que entrega tus páginas a los visitantes.

Apache y NGINX son dos de los servidores web más prominentes que existen.

A partir de julio de 2024, w3techs informa que NGINX impulsa más del 34% de los sitios web, mientras que Apache soporta el 29.4%.

¿Eso hace que NGINX sea el claro ganador? Aún no.

Ambos servidores web funcionan de manera diferente para casos de uso variados. En esta guía, veremos las diferencias entre Apache y NGINX y explicaremos qué buscar al elegir un servidor.

Vamos a comenzar.

¿Qué Son Los Servidores Web?

Los servidores web son aplicaciones de software que se ejecutan en un servidor físico y manejan las solicitudes de los usuarios entrantes.

Cuando escribes una URL como “google.com”, tu navegador envía una solicitud al servidor web, que almacena los archivos necesarios para ejecutar el sitio web.

El servidor luego envía el contenido apropiado, ya sea HTML, CSS, JavaScript, imágenes u otro tipo de archivos.

Los servidores web manejan muchas tareas importantes en segundo plano:

• Administrar conexiones y solicitudes HTTP
• Redirigir solicitudes a la aplicación de backend correcta si es necesario (como PHP, Python o Ruby on Rails)
• Leer y escribir archivos desde el disco para servir activos estáticos
• Hacer cumplir políticas de seguridad
• Comprimir contenido para una transmisión más rápida
• Registrar solicitudes para análisis

Ahora que hemos cubierto cómo funcionan los servidores web, veamos cómo NGINX y Apache abordan estas tareas.

¿Qué es Apache?

Apache HTTP Server, comúnmente llamado Apache, es un popular software de servidor web de código abierto creado por Robert McCool y lanzado en 1995. Está basado en el servidor NCSA HTTPd.

La Fundación Apache Software, una organización sin fines de lucro que apoya proyectos de software de código abierto, lo desarrolló y continúa manteniéndolo.

Durante muchos años, Apache fue el servidor web más utilizado en el mundo, impulsando muchos sitios web. De hecho, jugó un papel significativo en el crecimiento de la World Wide Web en sus primeros días.

Algunas de las características y beneficios clave de Apache son:

• Arquitectura modular: Su funcionalidad puede ser ampliada mediante módulos para diferentes características y lenguajes.
• Funciona en varios sistemas operativos: Apache está diseñado para ser multiplataforma, permitiendo alojar tu servidor web en cualquier sistema operativo, incluyendo Linux, Windows y macOS.
• Documentación extensa y una gran comunidad: Ayuda a usuarios y desarrolladores a resolver problemas y desarrollar mejores soluciones colaborativamente.
• Configuración flexible: Los archivos .htaccess pueden facilitar cambios en la configuración específica de directorios para los usuarios.
• Características de seguridad: Apache tiene una buena seguridad debido a su naturaleza de código abierto y actualizaciones regulares para corregir vulnerabilidades y errores.

Dicho esto, Apache tiene algunas limitaciones:

• Mayor uso de memoria: Utiliza más memoria que NGINX, particularmente cuando maneja varias conexiones concurrentes.
• Más lento bajo cargas pesadas: Puede ser más lento que NGINX al servir archivos estáticos, especialmente bajo cargas pesadas.
• Desafíos para desarrolladores en el desarrollo y mantenimiento: Con el tiempo, la creciente complejidad de su base de código ha hecho que sea más desafiante de construir y mantener.

¿Qué es NGINX?

NGINX (pronunciado “Engine X”) es un software de servidor web gratuito, de código abierto y de alto rendimiento, lanzado por primera vez en 2004. Fue creado por Igor Sysoev, un ingeniero de software ruso, para resolver el problema de manejar muchos usuarios accediendo a un sitio web simultáneamente, lo que era un desafío para otros servidores web como Apache.

El trabajo de Sysoev en NGINX comenzó en 2002. Su objetivo era abordar el “problema C10k” — manejar 10,000 conexiones concurrentes.

Su visión era de un servidor rápido, estable y escalable. Este enfoque en el rendimiento hace que NGINX sea excepcionalmente bueno en servir contenido estático como páginas HTML, imágenes y archivos CSS.

Más allá de su velocidad, NGINX sobresale como un proxy inverso. Recibe solicitudes de los usuarios y las redirige inteligentemente a otros servidores, como Apache o aplicaciones web, optimizando la utilización de recursos.

Algunas de las principales ventajas de NGINX son:

• Manejo concurrente: NGINX maneja a muchos usuarios simultáneamente sin requerir una cantidad excesiva de memoria o potencia de CPU.
• Fácil de configurar: NGINX tiene un formato de archivo de configuración simple e intuitivo que ayuda a los usuarios a configurar fácilmente el servidor web según sus necesidades.
• Diversas características de rendimiento: NGINX cuenta con muchas funciones integradas para balanceo de carga, almacenamiento en caché y seguridad de sitios web con cifrado SSL/TLS.
• Soporta IMAP y POP3: NGINX incluso funciona como un servidor proxy de correo, soportando protocolos como IMAP y POP3.

Sin embargo, hay algunos inconvenientes al usar NGINX:

• Configuraciones predeterminadas no óptimas: Los algoritmos de balanceo de carga predeterminados pueden no siempre ofrecer un rendimiento óptimo en cada situación.
• Sin compiladores de lenguajes integrados: No tiene soporte nativo para generar sitios web dinámicos usando lenguajes del lado del servidor como PHP o Python. No obstante, puedes sortear esto con una extensión de terceros.

Apache vs. NGINX: ¿Cuáles Son Las diferencias?

Apache fue alguna vez la opción principal como servidor web. Sin embargo, NGINX rápidamente tomó participación en el mercado y ahora es popular entre muchos sitios web de alto tráfico.

Si planeas trabajar con hosting dedicado, elegir el servidor web adecuado es una decisión importante.

Entonces, ¿qué distingue a estos dos?

Veamos más de cerca.

Detalles	Apache HTTP Server	NGINX
Fundado	1995	2004
Términos de licencia	Apache License 2.0	Licencia BSD de 2 cláusulas
Compatibilidad con sistemas operativos	Windows, Linux, macOS, sistemas basados en Unix	Windows, Linux, macOS, sistemas basados en Unix
Soporte del protocolo WebSocket	Sí	Sí (introducido en la versión 1.3.13)
Soporte de proxy inverso	Sí	Sí
Configuración de host virtual	Compatible	Compatible
Caché	Disponible a través de módulos	Integrado en el núcleo
Consumo de recursos (memoria)	Alto	Bajo
Formato de configuración y configuración	Basado en texto	Basado en texto (sintaxis más simple)
Características de seguridad	Soporte para mod_security ofrece configuración flexible de reglas y control de acceso	Filtrado avanzado, limitación de tasa, soporte integrado para mitigación de DDoS y rendimiento SSL/TLS
Comunicación encriptada (SSL/TLS)	Compatible	Compatible
Manejo de conexiones concurrentes	Bueno	Altamente eficiente
Scaling performance	Bueno	Sobresaliente
Funcionalidad de distribución de carga	Alcanzable con módulos	Característica integrada
Rendimiento y velocidad general	Satisfactorio	Dos veces más rápido que Apache

Arquitectura y Concurrencia

Una de las diferencias más significativas entre NGINX y Apache es cómo manejan las solicitudes entrantes en segundo plano.

Esto tiene un impacto considerable en su rendimiento y eficiencia de recursos.

Arquitectura Basada en Procesos de Apache

Apache sigue un modelo basado en procesos, generando un nuevo hilo o proceso para cada solicitud entrante.

Estos procesos o hilos son gestionados por los Módulos de Procesamiento Múltiple (MPMs):

• Prefork MPM: El modelo original de Apache. Cada proceso tiene un solo hilo y maneja una conexión a la vez. Es simple, pero puede ser intensivo en memoria.
• Worker MPM: Utiliza múltiples hilos por proceso, cada uno manejando una sola conexión. Es mejor que el prefork en términos de memoria, pero el tráfico pesado y las solicitudes que consumen muchos recursos aún pueden saturar la CPU, lo que lleva a problemas de rendimiento.
• Event MPM: Similar al worker MPM, pero optimizado para conexiones keep-alive (dispositivos que no pueden desconectarse del servidor). Aunque, todavía no es completamente asíncrono.

Estos son todos buenos módulos, pero tienen una desventaja principal: Apache debe crear nuevos procesos o hilos para cada conexión entrante y destruirlos cuando ha terminado. Intenta gestionar esto mediante la creación anticipada de algunos procesos inactivos.

Sin embargo, si varias personas quieren conectarse al sitio simultáneamente, Apache podría superar su grupo existente, y entonces debe crear rápidamente más procesos. Esto toma tiempo y consume memoria.

Este modelo funciona perfectamente para sitios con tráfico bajo a medio. Aun así, Apache puede comenzar a afectar sitios con muchas conexiones concurrentes.

Estos son todos buenos módulos, pero tienen una desventaja principal: Apache debe crear nuevos procesos o hilos para cada conexión entrante y destruirlos cuando ha terminado. Intenta gestionar esto mediante la creación anticipada de algunos procesos inactivos.

Sin embargo, si varias personas quieren conectarse al sitio simultáneamente, Apache podría superar su grupo existente, y entonces debe crear rápidamente más procesos. Esto toma tiempo y consume memoria.

Este modelo funciona perfectamente para sitios con tráfico bajo a medio. Aun así, Apache puede comenzar a afectar sitios con muchas conexiones concurrentes.

Todos estos procesos separados no son muy eficientes. Incluso con el event MPM, Apache no puede escapar completamente del modelo de un hilo por conexión.

Arquitectura Basada en Eventos de NGINX

NGINX adopta un enfoque muy diferente. En lugar de utilizar procesos o hilos separados para cada conexión, NGINX emplea una arquitectura asíncrona basada en eventos.

Así es como funciona:

• NGINX tiene un proceso principal (generalmente uno por núcleo de CPU) que gestiona varios procesos de trabajo. Cada trabajador puede manejar miles de conexiones simultáneas. No es necesario que los trabajadores generen nuevos hilos o dirijan cada solicitud a un proceso dedicado.
• En su lugar, los trabajadores tienen un bucle de eventos donde observan eficientemente los nuevos eventos en las conexiones existentes utilizando los mecanismos del sistema operativo, como kqueue o epoll. Esto les permite manejar múltiples conexiones dentro de un solo hilo. Cuando ocurre un evento, como una nueva solicitud entrante o una respuesta de un servidor backend, NGINX lo despacha rápidamente a un espacio libre en el trabajador.
• Esto es mucho más eficiente que el modelo de Apache. NGINX puede servir una gran cantidad de solicitudes con un consumo mínimo de memoria. Escala de manera increíble, por lo que se utiliza en muchos de los sitios más concurridos de la web.

El inconveniente es que NGINX no puede integrar intérpretes de código como lo hace Apache.

Entonces, cuando deseas ejecutar código Python o PHP, NGINX envía solicitudes a un administrador de procesos FastCGI separado, como php-fpm. Este proceso ejecuta el código y lo traduce a algo que el navegador del usuario puede entender.

Por otro lado, Apache puede ejecutar lenguajes como PHP, Perl y Python dentro de sus procesos.

Dado que NGINX no puede, el archivo de configuración puede volverse un poco más complejo.

Sin embargo, las mejoras en el rendimiento suelen compensar las complicaciones.

Rendimiento

NGINX es conocido por su alto rendimiento al servir archivos estáticos como páginas HTML, imágenes, CSS y JavaScript.

La arquitectura basada en eventos ayuda, pero NGINX también tiene otros trucos.

Primero, a diferencia de Apache, NGINX no necesita pasar por la caché y acceder al disco para cada solicitud. Puede servir archivos directamente desde el disco. Además, NGINX elimina la sobrecarga que conlleva la verificación de permisos y el bloqueo de archivos.

Apache enfrenta estos problemas porque cada solicitud es un proceso, y si un proceso está modificando algo, el otro proceso no puede usar el mismo archivo simultáneamente.

Mientras que los sitios web más pequeños no notarán este cuello de botella debido a la rapidez con la que se procesan las cosas en segundo plano, un sitio grande con un par de miles de solicitudes por segundo comenzará a experimentar estos problemas, ralentizando la experiencia del usuario.

NGINX también tiene una caché de archivos integrada. En la primera solicitud de un archivo, NGINX lo lee desde el disco y lo coloca en su caché. Las solicitudes futuras para ese archivo pueden ser servidas a gran velocidad directamente desde la memoria sin tocar el disco. También invalida automáticamente los datos en caché si el archivo en el disco cambia.

Estas optimizaciones se suman. En las pruebas de rendimiento, NGINX a menudo puede servir archivos estáticos aproximadamente tres veces más rápido que Apache, especialmente a medida que aumentan las solicitudes concurrentes.

Un beneficio adicional: esto también puede ayudarte a mejorar tus métricas principales para la web, dándote un pequeño impulso en Google.

Apache tampoco es lento. Simplemente, necesitas pasar tiempo afinándolo para que funcione a la perfección. También es capaz de servir archivos estáticos muy rápidamente.

Pero NGINX es la opción ideal si deseas un servidor web de alto rendimiento desde el principio.

Configuración y Sintaxis

NGINX y Apache tienen filosofías de configuración diferentes.

Apache es famoso por sus extensas opciones de configuración. Además de apache2.conf, debes agregar tus reglas y configuraciones al archivo .htaccess.

Los archivos de configuración utilizan una sintaxis similar a XML y ofrecen una flexibilidad increíble. Apache tiene una lista masiva de directivas que puedes usar para ajustar cada aspecto del comportamiento del servidor.

Puedes establecer opciones de configuración globalmente o sobreescribirlas para directorios específicos u hosts virtuales.

El verdadero poder de Apache proviene de su extenso ecosistema de módulos. Una gran variedad de módulos oficiales y de terceros para Apache te permite hacer de todo, desde reescritura de URLs hasta filtrado de seguridad y almacenamiento en caché avanzado. Para usar un módulo, lo cargas en tu configuración de Apache.

El lado negativo es que la configuración de Apache puede volverse compleja rápidamente, especialmente para configuraciones avanzadas. Las directivas pueden sobrescribirse entre sí en cadenas de herencia complicadas. Las opciones de configuración a menudo están divididas en múltiples archivos en varios subdirectorios de la carpeta principal de configuración. Es extremadamente flexible, pero lleva tiempo dominarlo.

La configuración de NGINX, por otro lado, busca simplicidad y legibilidad. No hay archivo .htaccess aquí. Simplemente, configuras los sitios en tu nginx.conf junto con la carpeta sites-enabled, y estás listo para empezar.

La sintaxis toma prestado el estilo de lenguajes de programación comunes. Sigue siendo poderosa, pero no tan extensa como la de Apache.

En lugar de módulos, NGINX tiene un conjunto más pequeño de directivas y características principales que vienen integradas. Todas tus opciones para una característica dada generalmente están en un solo bloque (encerradas entre llaves { }).

Algunas características avanzadas como el balanceo de carga y el almacenamiento en caché se configuran en el nginx.conf principal, no se separan en archivos adicionales.

El resultado es que los archivos de configuración de NGINX tienden a ser más ágiles y accesibles para leer y configurar que los pesados archivos de Apache, pero aun así puedes hacer mucho con ellos.

Seguridad

NGINX y Apache son proyectos de código abierto con comunidades grandes y activas de desarrolladores que trabajan constantemente para identificar y corregir vulnerabilidades. Ambos reciben actualizaciones de seguridad regulares y tienen un buen historial de resolución rápida de problemas.

Dicho esto, existen algunas diferencias en cómo abordan la seguridad.

Aquí algunos puntos clave a considerar:

• Modularidad: La arquitectura modular de Apache significa que solo necesitas habilitar las características que usas, minimizando así la superficie de ataque. Con NGINX, muchas características estándar están integradas directamente en el núcleo, lo que algunos podrían argumentar que hace que sea menos flexible desde el punto de vista de la seguridad.
• Filtrado de solicitudes: NGINX tiene un potente motor de filtrado de solicitudes integrado que puede ayudar a bloquear ataques web comunes como la inyección SQL y el scripting entre sitios (XSS). Apache tiene capacidades similares a través de módulos como mod_security.
• Configuración SSL/TLS: Ambos servidores soportan SSL/TLS para conexiones cifradas, pero se dice que NGINX suele ser más fácil de configurar. Tiene una documentación más clara y configuraciones más seguras de manera predeterminada.
• Aislamiento de procesos: El uso de un único proceso maestro con múltiples procesos de trabajo en NGINX puede ayudar a aislar áreas problemáticas. Los MPMs prefork y worker de Apache pueden proporcionar un aislamiento similar a nivel de proceso, pero a costa de usar más recursos.
• Mitigación de DDoS: La arquitectura basada en eventos de NGINX y su manejo eficiente de conexiones concurrentes lo hacen una opción popular para mitigar ataques DDoS pequeños y medianos. Algunos módulos adicionales y ajustes también pueden hacer que Apache sea resistente a ataques DDoS.

Contenido Dinámico, Módulos y Ecosistema

Apache ha sido durante mucho tiempo la opción preferida para servir contenido dinámico porque se integra fácilmente con lenguajes del lado del servidor. Con los MPMs prefork y worker, puedes compilar soporte para lenguajes como PHP, Python y Perl directamente en el binario de Apache.

Apache luego ejecutará un intérprete dentro de cada uno de sus procesos de trabajo. Esto es sencillo — Apache puede pasar solicitudes para archivos .php a su intérprete PHP integrado y obtener la salida renderizada de vuelta.

NGINX no tiene soporte incorporado para lenguajes del lado del servidor. Necesitas un servicio separado como php-fpm que ejecute el intérprete de lenguaje para ejecutar PHP, Python o Ruby on Rails con NGINX. NGINX recibe las solicitudes y las envía al backend, que procesa el código y devuelve una respuesta.

Esto requiere un poco más de trabajo para configurar en comparación con el enfoque todo-en-uno de Apache. Sin embargo, encaja con la filosofía de NGINX de hacer una cosa (servir solicitudes) — y hacerlo bien.

En cuanto a otras características, NGINX viene con un núcleo compacto de funcionalidades beneficiosas como balanceo de carga, proxy, almacenamiento en caché, limitación de tasa, compresión y terminación de SSL. Pero no iguala la increíble amplitud del ecosistema de módulos de Apache. Con Apache, tienes módulos para esquemas de autenticación, filtrado de contenido, lenguajes de scripting integrados y más.

No todos estos módulos son únicos. NGINX puede hacer muchos de los mismos trabajos, solo que de diferentes maneras. Sin embargo, la biblioteca de módulos de Apache es bastante extensa.

Si necesitas una funcionalidad extremadamente específica, Apache puede tener la ventaja aquí.

Aun así, el conjunto de características de NGINX es robusto para la mayoría de las necesidades comunes de servicio web.

Uso en el Mundo Real, Rendimiento y Comunidad

La popularidad de NGINX ha aumentado en la última década.

A partir de 2022, impulsa más del 34% de todos los sitios web a nivel mundial, en comparación con el aproximadamente 29% de Apache.

Una cosa que debes tener en cuenta: no notarás la diferencia entre estos servidores web a menos que tengas un sitio web grande o un servidor realmente pequeño.

Supongamos que te gustan las extensas opciones de configuración de Apache y su enfoque todo-en-uno para contenido dinámico. Los documentos de Apache son algunos de los mejores, y la comunidad es enorme si alguna vez necesitas ayuda.

NGINX puede ser mejor si estás buscando máxima concurrencia o construyendo un sitio grande. Su arquitectura es un poco más a prueba de futuro y está diseñada para escalar. Y la comunidad de NGINX ha crecido rápidamente. Los documentos también son sólidos; puedes encontrar muchas guías y soporte.

Apache vs. NGINX: ¿Cuál Es El Adecuado Para Ti?

No hay una respuesta universal para el debate entre NGINX y Apache. No obstante, aquí tienes algunas reglas generales que te pueden ayudar a tomar la decisión.

NGINX es mejor si:

• Tienes un sitio con mucho tráfico.
• Necesitas servir una gran cantidad de activos estáticos rápidamente.
• Estás construyendo una arquitectura de microservicios.
• Prefieres un estilo de configuración más simplificado.
• Estás utilizando contenedores o alojamiento en la nube donde cada byte de memoria cuenta.

Apache es mejor si:

• Necesitas una compatibilidad profunda con características exclusivas de Apache, como .htaccess.
• Quieres módulos para funcionalidades extremadamente específicas.
• Necesitas ejecutar aplicaciones web antiguas construidas para Apache y mod_php.
• Simplemente, te gusta el sistema de configuración de Apache.
• Tu servidor es principalmente una caja de desarrollo, y el rendimiento es menos crítico.

No hay ninguna regla que diga que debes elegir uno.

Ejecutar NGINX frente a Apache como un proxy inverso es muy común. Esto te permite combinar el servicio inigualable de archivos estáticos y el procesamiento concurrente de NGINX con el rico soporte de lenguajes dinámicos de Apache en el backend — lo mejor de ambos mundos.

Conclusión

Apache y NGINX son ambos excelentes, por lo que elegir uno se trata principalmente de cuál se ajusta mejor a tus necesidades.

Recuerda, incluso el servidor web más potente es solo una pieza del engranaje. Por lo tanto, si el sitio se siente lento, el software o hardware del servidor web no necesariamente debería ser lo primero en optimizar.

Un almacenamiento en caché más inteligente, la optimización de bases de datos, la optimización del código y un hardware subyacente sólido pueden ayudar a acelerar tu stack mucho más que pasar horas ajustando NGINX o Apache.

Si necesitas un servidor para experimentar, prueba el VPS administrado de DreamHost. Con un VPS, puedes elegir qué software instalar, cómo debe responder el servidor a las solicitudes y más. Además, con la flexibilidad de un VPS, puedes alojar varios sitios web en un solo servidor y dividir los recursos entre ellos según corresponda.

Además, todos los planes de DreamPress ahora vienen con NGINX.

¡La única manera de encontrar la configuración ideal es experimentar! Inicia un VPS, instala NGINX y Apache, y ve cuál funciona mejor para ti.