Introducción

Apache y Nginx son los dos servidores web de código abierto más comunes en el mundo. Juntos, son responsables de atender más del 50% del tráfico en Internet. Ambas soluciones son capaces de administrar diversas cargas de trabajo y trabajar con otro software para proporcionar un conjunto web completo.

Si bien Apache y Nginx comparten muchas cualidades, no se debe pensar que sean completamente intercambiables. Cada uno sobresale a su manera y es importante comprender las situaciones en las que es posible que debas reevaluar el servidor web de tu elección. Este artículo se dedicará a una discusión de cómo cada servidor funciona en varias áreas.

Visión general

Antes de profundizar en las diferencias entre Apache y Nginx, echemos un vistazo rápido de estos dos proyectos y sus características generales.

Apache

El servidor HTTP Apache fue creado por Robert McCool en 1995 y se ha desarrollado bajo la dirección de Apache Software Foundation desde 1999. Dado que el servidor web HTTP es el proyecto original de la fundación y es, con mucho, su software más popular, a menudo es referido simplemente como “apache”.

El servidor web Apache ha sido el servidor más popular en Internet desde 1996. Debido a esta popularidad, Apache se beneficia de una excelente documentación y soporte integrado de otros proyectos de software.

Apache es a menudo elegido por los administradores por su flexibilidad, potencia y amplio soporte. Es extensible a través de un sistema de módulos cargables dinámicamente y puede procesar una gran cantidad de lenguajes interpretados sin necesidad de conectarse a un software separado.

Nginx

En 2002, Igor Sysoev comenzó a trabajar en Nginx como una respuesta al problema C10K, que fue un desafío para los servidores web para comenzar a manejar diez mil conexiones simultáneas como un requisito para la web moderna. El lanzamiento público inicial se realizó en 2004, cumpliendo con este objetivo al basarse en una arquitectura asincrónica y basada en eventos.

Nginx ha crecido en popularidad desde su lanzamiento debido a su ligero uso de recursos y su capacidad para escalar fácilmente en un mínimo de hardware. Nginx es excelente para mostrar contenido estático rápidamente y está diseñado para pasar solicitudes dinámicas a otro software que sea más adecuado para esos fines.

Nginx es a menudo seleccionado por los administradores por su eficiencia de recursos y capacidad de respuesta bajo carga. Los defensores de este agradecen el enfoque de Nginx en el servidor web central y las funciones de proxy.

Arquitectura de manejo de conexiones

Una gran diferencia entre Apache y Nginx es la forma real en que manejan las conexiones y el tráfico. Esto proporciona quizás la diferencia más significativa en la forma en que responden a diferentes condiciones de tráfico.

Apache

Apache proporciona una variedad de módulos de multiprocesamiento (Apache llama a estos MPM) que dictan cómo se manejan las solicitudes de los clientes. Básicamente, esto permite a los administradores intercambiar su arquitectura de manejo de conexiones fácilmente. Estos son:

• mpm_prefork: este módulo de procesamiento genera procesos con un solo subproceso cada uno para manejar la solicitud. Cada uno puede manejar una sola conexión a la vez. Mientras el número de solicitudes sea menor que el número de procesos, este MPM es muy rápido. Sin embargo, el rendimiento se degrada rápidamente después de que las solicitudes superan el número de procesos, por lo que esta no es una buena opción en muchos escenarios. Cada proceso tiene un impacto significativo en el consumo de RAM, por lo que este MPM es difícil de escalar de manera efectiva. Esto puede ser una buena opción, aunque si se usa junto con otros componentes que no están diseñados teniendo en cuenta los hilos. Por ejemplo, PHP no es seguro para subprocesos, por lo que se recomienda este MPM como la única forma segura de trabajar con mod_php el módulo de Apache para procesar estos archivos.

• mpm_worker: este módulo genera procesos que pueden gestionar varios subprocesos. Cada uno de estos hilos puede manejar una sola conexión. Los hilos son mucho más eficientes que los procesos, lo que significa que este MPM se escala mejor que el MPM prefork. Dado que hay más subprocesos que procesos, esto también significa que las nuevas conexiones pueden tomar inmediatamente un subproceso libre en lugar de tener que esperar un proceso libre.

• mpm_event: este módulo es similar al módulo anterior en la mayoría de las situaciones, pero está optimizado para manejar conexiones de mantenimiento. Cuando se utiliza el MPM worker, una conexión mantendrá un subproceso independientemente de si se realiza una solicitud de forma activa mientras la conexión se mantenga activa. El evento que maneja el MPM mantiene las conexiones vivas dejando a un lado los hilos dedicados para manejar las conexiones vivas y pasando las solicitudes activas a otros hilos. Esto evita que el módulo se atasque con las solicitudes de mantenimiento, lo que permite una ejecución más rápida. Esto se volvió estable con el lanzamiento de Apache 2.4.

Como puedes ver, Apache proporciona una arquitectura flexible para elegir diferentes conexiones y solicitar algoritmos de manejo. Las opciones proporcionadas son principalmente una función de la evolución del servidor y la creciente necesidad de concurrencia a medida que el panorama de Internet ha cambiado.

Nginx

Nginx entró en escena después de Apache, con más conciencia de los problemas de concurrencia que enfrentarían los sitios a gran escala. Aprovechando este conocimiento, Nginx fue diseñado desde cero para utilizar un algoritmo de manejo de conexión asíncrono, sin bloqueo, dirigido por eventos.

Nginx genera procesos de trabajo, cada uno de los cuales puede manejar miles de conexiones. Los procesos de trabajo logran esto implementando un mecanismo de bucle rápido que verifica y procesa eventos continuamente. El desacoplamiento del trabajo real de las conexiones permite a cada worker ocuparse de una conexión solo cuando se ha activado un nuevo evento.

Cada una de las conexiones manejadas por el worker se coloca dentro del bucle de eventos donde existen con otras conexiones. Dentro del bucle, los eventos se procesan de forma asíncrona, lo que permite que el trabajo se maneje de manera no bloqueante. Cuando la conexión se cierra, se elimina del bucle.

Este estilo de procesamiento de conexión permite a Nginx escalar increíblemente lejos con recursos limitados. Dado que el servidor es de un solo hilo y los procesos no se generan para manejar cada nueva conexión, la memoria y el uso de la CPU tienden a ser relativamente constantes, incluso en momentos de gran carga.

Contenido estático vs dinámico

En términos de casos de uso del mundo real, una de las comparaciones más comunes entre Apache y Nginx es la forma en que cada servidor administra las solicitudes de contenido estático y dinámico.

Apache

Los servidores Apache pueden administrar contenido estático usando sus métodos convencionales basados ​​en archivos. El rendimiento de estas operaciones es principalmente una función de los métodos MPM descritos anteriormente.

Apache también puede procesar contenido dinámico incorporando un procesador del lenguaje en cuestión en cada una de sus instancias de trabajo. Esto te permite ejecutar contenido dinámico dentro del propio servidor web sin tener que depender de componentes externos. Estos procesadores dinámicos se pueden habilitar mediante el uso de módulos cargables dinámicamente.

La capacidad de Apache para administrar contenido dinámico internamente significa que la configuración del procesamiento dinámico tiende a ser más simple. La comunicación no necesita coordinarse con un software adicional y los módulos pueden intercambiarse fácilmente si cambian los requisitos de contenido.

Nginx

Nginx no tiene ninguna capacidad para procesar contenido dinámico de forma nativa. Para manejar PHP y otras solicitudes de contenido dinámico, Nginx debe pasar a un procesador externo para su ejecución y esperar a que se devuelva el contenido representado. Los resultados pueden ser transmitidos al cliente.

Para los administradores, esto significa que la comunicación debe configurarse entre Nginx y el procesador a través de uno de los protocolos que Nginx sabe cómo hablar (http, FastCGI, SCGI, uWSGI, memcache). Esto puede complicar un poco las cosas, especialmente cuando se intenta anticipar la cantidad de conexiones que se permitirán, ya que se utilizará una conexión adicional para cada llamada al procesador.

Sin embargo, este método también tiene algunas ventajas. Dado que el intérprete dinámico no está integrado en el proceso de trabajo, su sobrecarga solo estará presente para el contenido dinámico. El contenido estático se puede mostrar de manera directa y solo se contactará al intérprete cuando sea necesario. Apache también puede funcionar de esta manera, pero al hacerlo se eliminan los beneficios de la sección anterior.

Configuración distribuida vs centralizada

Para los administradores, una de las diferencias más evidentes entre estas dos piezas de software es si la configuración a nivel de directorio está permitida dentro de los directorios de contenido.

Apache

Apache incluye una opción para permitir la configuración adicional por directorio inspeccionando e interpretando las directivas en archivos ocultos dentro de los propios directorios de contenido. Estos archivos son conocidos como archivos .htaccess.

Dado que estos archivos residen dentro de los propios directorios de contenido, al administrar una solicitud, Apache verifica cada componente de la ruta al archivo solicitado en busca de un archivo .htaccess y aplica las directivas que se encuentran dentro. Esto permite efectivamente la configuración descentralizada del servidor web, que a menudo se utiliza para implementar reescrituras de URL, restricciones de acceso, autorización y autenticación, incluso políticas de almacenamiento en caché.

Si bien los ejemplos anteriores se pueden configurar en el archivo de configuración principal de Apache, los archivos .htaccess tienen algunas ventajas importantes. Primero, dado que estos se interpretan cada vez que se encuentran a lo largo de una ruta de solicitud, se implementan inmediatamente sin volver a cargar el servidor. En segundo lugar, hace posible que los usuarios sin privilegios puedan controlar ciertos aspectos de su propio contenido web sin darles control sobre el archivo de configuración completo.

Esto proporciona una manera fácil para que ciertos programas web, como los sistemas de gestión de contenido para configurar su entorno sin proporcionar acceso al archivo de configuración central. Esto también es utilizado por los proveedores de alojamiento compartido para mantener el control de la configuración principal mientras que los clientes tienen control sobre sus directorios específicos.

Nginx

Nginx no interpreta los archivos .htaccess, ni proporciona ningún mecanismo para evaluar la configuración por directorio fuera del archivo de configuración principal. Esto puede ser menos flexible que el modelo de Apache, pero tiene sus propias ventajas.

La mejora más notable sobre el sistema htaccess de configuración de nivel de directorio es un mayor rendimiento. Para una configuración típica de Apache que puede permitir .htaccess en cualquier directorio, el servidor buscará estos archivos en cada uno de los directorios principales que conducen al archivo solicitado, para cada solicitud. Si se encuentran uno o más archivos .htaccess durante esta búsqueda, se deben leer e interpretar. Al no permitir las anulaciones de directorio, Nginx puede atender solicitudes más rápido al
realizar una única búsqueda de directorio y lectura de archivos para cada solicitud (asumiendo que el archivo se encuentra en la estructura de directorios convencional).

Otra ventaja es la seguridad relacionada. La distribución del acceso a la configuración a nivel de directorio también distribuye la responsabilidad de la seguridad a usuarios individuales, a quienes no se les puede confiar para que administren bien esta tarea. Asegurarse de que el administrador mantenga el control sobre todo el servidor web puede evitar algunos errores de seguridad que pueden ocurrir cuando se otorga acceso a otras partes.

Ten en cuenta que es posible desactivar la interpretación .htaccess en Apache si estas preocupaciones te alarman.

Archivo vs interpretación basada en URI

La forma en que el servidor web interpreta las solicitudes y las asigna a los recursos reales en el sistema es otra área en la que estos dos servidores difieren.

Apache

Apache proporciona la capacidad de interpretar una solicitud como un recurso físico en el sistema de archivos o como una ubicación de URI que puede necesitar una evaluación más abstracta. En general, para el antiguo Apache usa bloques <Directory>o <Files>, mientras que utiliza bloques <Location> para recursos más abstractos.

Debido a que Apache fue diseñado desde cero como un servidor web, el valor predeterminado es interpretar las solicitudes como recursos del sistema de archivos. Comienza tomando la raíz del documento y agregando la parte de la solicitud después del host y el número de puerto para tratar de encontrar un archivo real. Básicamente, la jerarquía del sistema de archivos se representa en la web como el árbol de documentos disponible.

Apache proporciona una serie de alternativas para cuando la solicitud no coincide con el sistema de archivos subyacente. Por ejemplo, una directiva Alias se puede utilizar para asignar a una ubicación alternativa. El uso de bloques <Location> es un método para trabajar con el URI en lugar del sistema de archivos. También hay variantes de expresiones regulares que se pueden usar para aplicar la configuración de manera más flexible en todo el sistema de archivos.

Si bien Apache tiene la capacidad de operar tanto en el sistema de archivos subyacente como en el espacio web, se inclina fuertemente hacia los métodos del sistema de archivos. Esto se puede ver en algunas de las decisiones de diseño, incluido el uso de archivos .htaccess para la configuración por directorio. Los documentos de Apache advierten sobre el uso de bloques basados ​​en URI para restringir el acceso cuando la solicitud refleja el sistema de archivos subyacente.

Nginx

Nginx fue creado para ser un servidor web y un servidor proxy. Debido a la arquitectura requerida para estos dos roles, funciona principalmente con URI, traduciéndose al sistema de archivos cuando sea necesario.

Esto se puede ver en algunas de las formas en que los archivos de configuración de Nginx se construyen e interpretan. Nginx no proporciona un mecanismo para especificar la configuración de un directorio de sistema de archivos y, en cambio, analiza el URI en sí.

Por ejemplo, los bloques de configuración principales para Nginx son los bloques server y location. El bloque server interpreta el host que se solicita, mientras que los bloques location son responsables de hacer coincidir partes del URI que vienen después del host y el puerto. En este punto, la solicitud se interpreta como un URI, no como una ubicación en el sistema de archivos.

Para los archivos estáticos, todas las solicitudes deben asignarse a una ubicación en el sistema de archivos. Primero, Nginx selecciona el servidor y los bloques de ubicación que manejarán la solicitud y luego combina la raíz del documento con el URI, adaptando todo lo necesario según la configuración especificada.

Esto puede parecer similar, pero el análisis de solicitudes principalmente como URI en lugar de ubicaciones de sistemas de archivos permite que Nginx funcione más fácilmente en las funciones de servidor web, correo y proxy. Nginx se configura simplemente al presentar cómo responder a diferentes patrones de solicitud. Nginx no comprueba el sistema de archivos hasta que está listo para atender la solicitud, lo que explica por qué no implementa una forma de archivos .htaccess.

Módulos

Tanto Nginx como Apache son extensibles a través de sistemas de módulos, pero la forma en que funcionan difiere significativamente.

Apache

El sistema de módulos de Apache te permite cargar y descargar dinámicamente módulos para satisfacer tus necesidades durante el curso de la ejecución del servidor. El núcleo de Apache está siempre presente, mientras que los módulos se pueden activar o desactivar, agregar o eliminar funciones adicionales y conectarlos al servidor principal.

Apache usa esta funcionalidad para una gran variedad de tareas. Debido a la madurez de la plataforma, hay una extensa biblioteca de módulos disponibles. Se pueden usar para alterar algunas de las funciones principales del servidor, como por ejemplo mod_php, que incorpora un intérprete de PHP en cada worker en ejecución.

Sin embargo, los módulos no se limitan a procesar contenido dinámico. Entre otras funciones, se pueden usar para reescribir direcciones URL, autenticar clientes, fortalecer el servidor, registrar, almacenar en caché, comprimir, enviar por proxy, limitar la velocidad y encriptar. Los módulos dinámicos pueden extender la funcionalidad central considerablemente sin mucho trabajo adicional.

Nginx

Nginx también implementa un sistema de módulos, pero es bastante diferente del sistema Apache. En Nginx, los módulos no se pueden cargar dinámicamente, por lo que deben seleccionarse y compilarse en el software central.

Para muchos usuarios, esto hará que Nginx sea mucho menos flexible. Esto es especialmente cierto para los usuarios que no se sienten cómodos manteniendo su propio software compilado fuera del sistema de empaquetado convencional de su distribución. Si bien los paquetes de distribuciones tienden a incluir los módulos más utilizados, si necesitas un módulo no estándar, tendrás que compilar el servidor desde su origen.

Sin embargo, los módulos Nginx siguen siendo muy útiles y te permiten dictar lo que quieres que salga de tu servidor al incluir solo la funcionalidad que pretendes utilizar. Algunos usuarios también pueden considerar esto más seguro, ya que no se pueden conectar componentes arbitrarios al servidor. Sin embargo, si tu servidor alguna vez se coloca en una posición donde esto sea posible, es probable que ya esté comprometido.

Los módulos Nginx permiten muchas de las mismas capacidades que los módulos de Apache. Por ejemplo, los módulos Nginx pueden proporcionar soporte de proxy, compresión, limitación de velocidad, registro, reescritura, geolocalización, autenticación, cifrado, transmisión y funcionalidad de correo.

Soporte, Compatibilidad, Ecosistema y Documentación

Un punto importante a considerar es qué proceso real de puesta en marcha tendrá el panorama de ayuda disponible y soporte entre otros programas.

Apache

Debido a que Apache ha sido popular durante tanto tiempo, el soporte para el servidor es bastante omnipresente. Hay una gran biblioteca de documentación de primera y tercera parte disponible para el servidor central y para los escenarios basados ​​en tareas que involucran la conexión de Apache con otro software.

Junto con la documentación, muchas herramientas y proyectos web incluyen herramientas para iniciarse en un entorno de Apache. Esto puede incluirse en los propios proyectos o en los paquetes mantenidos por el equipo de empaquetado de tu distribución.

Apache, en general, tendrá más soporte de proyectos de terceros simplemente debido a su participación de mercado y la cantidad de tiempo que ha estado disponible. También es más probable que los administradores tengan experiencia trabajando con Apache, no solo por su prevalencia, sino también porque muchas personas comienzan en escenarios de alojamiento compartido que dependen casi exclusivamente de Apache debido a las capacidades .htaccess de administración distribuida.

Nginx

Nginx está experimentando un mayor soporte a medida que más usuarios lo adoptan para su perfil de rendimiento, pero todavía tiene que ponerse al día en algunas áreas clave.

En el pasado, era difícil encontrar documentación completa en inglés con respecto a Nginx debido al hecho de que la mayoría de los primeros desarrollos y la documentación estaban en ruso. A medida que creció el interés en el proyecto, se completó la documentación y ahora hay muchos recursos de administración en el sitio de Nginx y a través de terceros.

Con respecto a las aplicaciones de terceros, el soporte y la documentación están cada vez más disponibles, y los mantenedores de paquetes están comenzando, en algunos casos, a elegir entre la configuración automática de Apache y Nginx. Incluso sin soporte, la configuración de Nginx para que funcione con software alternativo es generalmente sencilla siempre que el proyecto en sí documente sus requisitos (permisos, encabezados, etc.).

Usando Apache y Nginx al mismo tiempo

Después de revisar los beneficios y las limitaciones de Apache y Nginx, puedes tener una mejor idea de qué servidor se adapta mejor a tus necesidades. Sin embargo, muchos usuarios encuentran que es posible aprovechar los puntos fuertes de cada servidor usándolos juntos.

La configuración convencional para esta asociación es colocar a Nginx delante de Apache como un proxy inverso. Esto permitirá que Nginx maneje todas las solicitudes de los clientes. Esto aprovecha la velocidad de procesamiento rápido de Nginx y la capacidad de manejar un gran número de conexiones simultáneamente.

Para el contenido estático, en el que Nginx se destaca, los archivos se entregarán rápida y directamente al cliente. Para el contenido dinámico, por ejemplo, los archivos PHP, Nginx enviará la solicitud a Apache, que luego puede procesar los resultados y devolver la página representada. Nginx puede pasar el contenido de nuevo al cliente.

Esta configuración funciona bien para muchas personas porque permite que Nginx funcione como una máquina de clasificación. Manejará todas las solicitudes que pueda y transmitirá las que no tenga capacidad nativa para atender. Al reducir las solicitudes que el servidor Apache debe manejar, podemos aliviar algunos de los bloqueos que ocurren cuando un proceso o subproceso de Apache está ocupado.

Esta configuración también te permite escalar agregando servidores backend adicionales según sea necesario. Nginx puede configurarse para pasar fácilmente a un grupo de servidores, lo que aumenta la resistencia de esta configuración a fallas y rendimiento.

Conclusión

Como puedes ver, tanto Apache como Nginx son poderosos, flexibles y capaces. Decidir cuál es el mejor servidor para ti es en gran medida una función de evaluar tus requisitos específicos y realizar pruebas con los patrones que esperas ver.

Hay diferencias entre estos proyectos que tienen un impacto muy real en el rendimiento sin formato, las capacidades y el tiempo de implementación necesarios para que cada solución esté en funcionamiento. Sin embargo, estos suelen ser el resultado de una serie de compensaciones que no deben ser descartadas casualmente. Al final, no hay un servidor web único para todos, así que usa la solución que mejor se ajuste con tus objetivos.