Nginx vs Apache: Lucha entre Servidores Web

El internet, como lo conocemos hoy en día, comenzó una “conquista” global en los años 90. Todo el protocolo “Web” puede ser resumido como un visitante pidiendo un documento de cierta dirección web, con un DNS y sistema IP enviando esa petición a la computadora correcta. Esta computadora, que está haciendo hosting a la página requerida, “servirá” la página web de vuelta al visitante.

Las páginas web son esencialmente documentos HTML. Para poder servir distintas páginas web a los visitantes, la maquina que “sirve” necesita un programa de servidor. Software como Nginx y Apache lidian con estas peticiones, las analizan y las envían de vuelta junto con los documentos correspondientes, para que puedan ser vistos por el visitante.

Apache

Primero hablaremos de Apache, ya que fue el primero en salir.

Después del CERN httpd y el NCSA HTTPd de TimBerners-Lee durante los primeros años del internet, llegó Apache – lanzado originalmente en 1995 – y conquistó en unos instantes el mercado para convertirse en el servidor web más popular. Hoy en día, sigue ocupando una fuerte posición en el mercado, pero mayormente por razones de legado. Apache sigue siendo desarrollado y mantenido por el Apache Foundation, bajo la licencia Apache.

Hay dos historias distintas sobre como Apache obtuvo su nombre. La primera versión dice que el nombre se originó de la famosa herencia Nativo Americana, mientras que la otra dice que el nombre es un chiste originado de la frase “a patchy server” o en español un servidor con muchos parches, después de recibir una gran cantidad de patches de software.

Linux

Gran parte de la razón por la que Apache sigue ocupando una buena posición en el mercado es parcialmente por el hecho de que viene instalado en la gran mayoría de las distribuciones Linux, como Red Hat/Centos y Ubuntu.

Un ejemplo del rol tan importante de Apache dentro del mundo de Linux es que sirve el nombre de su proceso de servidor es HTTPd, haciendo Apache sinónimo con el software de servidor web.

Además de ser el primer jugador serio en el mercado de los servidores, parte de la proliferación de Apache es debida a su sistema de configuración y su archivo .htaccess.

.htaccess

Apache utiliza .htaccess para su configuración. Hay muchos tutoriales sobre cómo configurar, editar y trabajar con sus archivos ya que este provee mucha flexibilidad en la configuración de como Apache lidia con las peticiones entrantes. Algunos ejemplos son: distintas reglas de redirección, tamaños máximos de subida de archivos, reescrituras de URL, limites de memoria, protección de directorio (htpasswd), encabezados de expiración, encabezados de control-caché, encabezado de codificación, cookies, manipulaciones de query string.

Por otro lado, Kinsta utiliza Nginx el cual no ofrece soporte para archivos .htaccess. Sin embargo, las opciones y reglas de sus archivos .htaccess pueden ser fácilmente “traducidas” a la regla reescrita de sintaxis de Nginx.

Una de las principales “Ventajas” de Apache es que el servidor principal – el directorio principal del sitio web – cada nivel o directorio en el árbol de directorios pueden tener su propio archivo .htaccess con su propia configuración.

Para proveedores de hosting compartido, esto es un sueño porque estos pueden ofrecer a cientos de usuarios en la misma maquina una forma de como configurar como sus sitios son servidos, sin que afecten a otros. Los clientes pueden configurar muchos de los detalles en un entorno restringido de hosting compartido, mientras que jamás tocarán la configuración del servidor global.

Como dice la documentación oficial dice:

«En general, usted debería usar los archivos .htaccess cuando uno no tenga acceso al archivo de configuración principal del servidor.»

Esta flexibilidad, sin embargo, viene con un costo sobre el desempeño “¡permitiendo que los archivos .htaccess causen cambios en el desempeño, quiere o no usarlos!”

Cada vez que los archivos .htaccess son habilitados, Apache tiene que atravesar todo el árbol del directorio desde un URL o archivo solicitado a través de todas las partes más altas hasta llegar al directorio raíz del servidor y luego cargarlas, por cada una de las peticiones. Esta necesita procesar estos archivos y reconfigurarse a sí mismo por cada uno de los directorios configurados de esta forma.

Con los sitios de WordPress, las cosas se pueden poner realmente complejas. Un sitio típico de WordPress puede tener cientos de peticiones de distintos directorios.

Desde los tipos de directorios /wp-content/uploads/yyyy/mm, típicamente tendrán múltiples peticiones en una sola carga de página, usualmente di directorios de distintos meses. Entonces habrá recursos estáticos del /wp-content/themes/parent-theme, /wp-content/themes/child-theme: estos incluirán javascript, archivos css, imágenes.

Luego, también habrá /wp-content/plugins con archivos estáticos cargados usualmente de docenas de subdirectorios de plugin. Para cada uno de estos recursos, Apache tiene que atravesar todo árbol para encontrar la configuración.

Un análisis ha demostrado que una configuración típica de WordPress, bastante común para sitios en hosts compartidos, incluirán 42 ejecuciones separadas .htaccess y 249 vistas separadas para el archivo .htaccess.

Este es tan sólo un nivel de un servidor web. El visitante aún necesita esperar para que el proceso de PHP ejecute todo el stack de llamada de WordPress para crear un query de la base de datos y mandarlo a MySQL para armar la página web y enviarla al visitante.

Módulos

Otra cosa que hizo popular a Apache es su sistema de módulo dinámico.

Los Módulos – como una función que permite a los usuarios extender funcionalidad de servidor web – existen en Nginx y Apache. Apache permite que los usuarios instalen módulos una vez que el servidor web ya ha sido instalado y lanzado, y luego los habilita/deshabilita cuando sean necesarios. Las distribuciones basadas en Debian tienen comandos que permiten habilitar y deshabilitar estos módulos sin tener que editar los archivos de configuración: a2enmod y a2dismod.

La lista oficial de módulos que vienen como parte de la distribución estándar de Apache están aquí y estas incluyen cosas como la compresión, encriptación, inicio de sesión, redirecciones a cosas más avanzadas como editar peticiones y respuestas con sintaxis avanzada.

Nginx

Nginx (también escrito como nginx o NGINX), entró en escena en el 2004, cuando fue lanzado por primera vez de forma pública por el desarrollador Ruso Igor Sysoev. Como Owen Garret, el jefe de proyecto de Nginx dijo:

«Nginx fue escrito específicamente para resolver las limitantes de desempeño de los servidores web de Apache.»

El servidor fue creado primero como una herramienta para escalar para el sitio web de rambler.ru en el 2002. Este viene en dos versiones: open source, con licencia tipo-BSD, y Nginx plus, con soporte y funciones empresariales adicionales.

Después de ser lanzado, Nginx fue usado principalmente para servir archivos estáticos y como un balanceador de carga o proxy inverso en frente de instalaciones Apache. Mientras evolucionaba la red, y la necesidad de exprimir hasta la última gota de la velocidad y eficiencia de uso de hardware con este, más sitios empezaron a reemplazar Apache con Nginx por completo, gracias a un software mucho más maduro.

En Marzo del 2019, Nginx Inc fue adquirido por F5 Networks por $670 millones. En ese momento, como lo reporta Techcrunch, el servidor Nginx estaba siendo usado por más de “375 millones de sitios web con alrededor de 1,500 clientes de paga”.

De acuerdo a datos de w3techs, la posición en el mercado de Nginx ha estado en constante crecimiento, sacando a Apache y quitándole la corona para tomar el primer puesto:

Estos datos pertenecen a todos los servidores web a nivel mundial, pero si tomamos una muestra del primer millón de sitios en la cima, Nginx ha estado ahí desde hace un buen rato:

Las Tendencias de Búsqueda de Google parecen reflejar este dato también:

La encuesta de Netcraft sugiere que Apache ha sido superada por Nginx en Abril del 2019.

Configuración Nginx

Nginx no tiene un sistema de configuración como Apache, así que, a pesar de ser mucho más eficiente y rápido, no es tan usado con los proveedores de hosting. No resalta tanto en entornos compartidos como Apache.

Por otro lado, como hemos dicho, al no permitir configuraciones a nivel directorio, Nginx obtiene una ventaja significativa sobre Apache. Hay un artículo en Nginx wiki que compara el impacto del desempeño:

Módulos Nginx

El sistema de módulos de Nginx es una cosa más que se posiciona como una elección más premium. Los módulos de Nginx típicamente necesitan ser habilitados durante el tiempo de su construcción, lo que quiere decir que esto requiere más habilidad técnica, y la adición de módulos después de la instalación es un poco más compleja.

En el 2016, con la versión 1.9.11, las cosas han cambiado y el repositorio oficial/verificado de los módulos dinámicos es reservado para los usuarios de paga. Desde Mayo del 2019, ellos anunciaron que empezarían a desarrollar el soporte para QUIC y HTTP/3.

El Asunto sobre el Caché: Nginx vs Apache

El caché – si queremos simplificarlo – puede ser visto como el tener que preparar el contenido para los visitantes del sitio web antes de que lleguen, para que cuando “toquen a la puerta”, usted no necesite buscar el contenido que están buscando. Ya lo tendrá preparado y usted se los entregará sin que nadie espere.

Como Apache, la configuración típica de Nginx solía ser quedarse entre los servidores y el usuario final para ayudar con el cambio del desempeño en el resto de la infraestructura. En estos casos, este puede hacer caché a contenido estático sin la necesidad de conseguirlo del servidor original protegido en todas las ocasiones.

Si utilizamos Nginx como un servidor web autónomo – como es el caso con los contenedores LXC de Kinsta – no existe esa necesidad. Nginx es muy eficiente en servir contenido estático por su cuenta.

Luego está el asunto del caché dinámico o el caché de la página. En un escenario de un sitio web de WordPress, esto quiere decir almacenar todas las páginas de WordPress generadas por cada URL en la memoria o en el disco.

FastCGI caching está disponible por omisión en las instalaciones estándares de Nginx. Es simple, muy poderosa, y una de las funciones menos usadas de Nginx.

Para comparar esto con los equivalentes de Apache, usted debería saber que Apache tiene un módulo mod_cache el cual se reporta que suele estar lleno de glitches, y esto causa conflictos con otros módulos. Así que la solución estándar de caché desplegada por Apache es el acelerador de HTTP Varnish. A pesar de que Varnish es la solución dedicada de la industria, algunas pruebas recientes dan a Nginx caché una clara ventaja sobre Varnish.

En Kinsta, nosotros utilizamos Nginx para tener un caché dinámico en WordPress, junto con un plugin propietario de caché que permita control granular sobre las páginas en el caché, y activos estáticos almacenados en el caché por el CDN de Kinsta.

Lidiando con las Peticiones: Nginx vs Apache

La más grande diferencia entre Apache y Nginx se encuentra en la arquitectura subyacente de la forma en que estos manejan las peticiones.

Apache procesa las peticiones con MPM-s o Multi-Processing-Modules, el cual es “responsable de unirse a los puertos de la red en la maquina, aceptar peticiones, y mandar children para manejar las peticiones.”

EL MPM más viejo, el cual data desde los principios de Apache, es el módulo prefork. A este módulo se le puede acreditar la mala reputación del desempeño de Apache. Bajo este modo, Apache sacó varios nuevos procesos con un sólo hilo en cada petición.

Este modulo, usado con mod_php, quiere decir que el servidor de Apache agregó un interprete de PHP en cada proceso, incluso si este tenía que servir archivos CSS o imágenes.

Esto era ineficiente. El módulo de Peefork viene con Apache como el módulo por defecto. Este también restringe conexiones a HTTP/1.

Años más adelante, Apache desarrolló un mpm trabajador con múltiples hilos y después de eso, el mpm de evento. Ambos alivianaban muchos de los problemas de desempeño de Apache. Cambiar a php-fpm hizo posible que Apache siguiera siendo una solución que compite en el mercado hasta hoy en día, junto con la eliminación del uso de .htaccess, pero eso, como que va en contra de su propósito.

Nginx utiliza arquitectura asíncrona a base de eventos, sin bloqueos.

Para explicar la diferencia: en el mundo de Linux/Unix, los procesos están poniendo en funcionamiento a los programas.

Los hilos son un sub conjunto de procesos y puede haber múltiples hilos dentro de una sola ejecución de proceso. Vea esto como tener varias pestañas abiertas en la ventana de un navegador. De esta forma un programa puede aprovechar múltiples CPU-s y CPU-s con cores e hilos múltiples para ejecutarse aún más rápido. Puede leer a Linus Torvalds elaborando a detalle las diferencias.

En pocas palabras, Apache utiliza procesos para cada conexión (y con un mpm trabajador este utiliza hilos). A lo largo de que crece el tráfico, rápidamente se hace demasiado caro.

Podemos imaginarnos nuevos procesos o creación de hilos, como el encender una computadora o abrir un programa. Incluso en las computadoras más rápidas, tomará un poco de tiempo. Con los sitios web de ahora, haciendo cientos de peticiones en una sola carga de página, esto rápidamente se acumula.

Los mpm de evento pueden ir un poco más allá cuando se trata de la optimización, pero algunas pruebas muestran que no pueden rebasar a Nginx. Especialmente cuando hablamos de archivos estáticos, donde Nginx sirve casi el doble de peticiones que Apache hace.

Nginx idealmente tiene un proceso de trabajador por cada CPU/core. La diferencia de los procesos del trabajador de Nginx es que cada una lidia con cientos de miles de conexiones entrantes de la red por cada trabajador. No hay necesidad de crear nuevos hilos o procesos por cada conexión.

Esta es la razón por la que los Content Delivery Networks más grandes, como Cloudflare, MaxCDN, y nuestro socio, KeyCDN – o sitios como Netflix – ven a Nginx como un elemento crucial para su entrega de contenido.

La lista de compañías que toman ventaja de Nginx es demasiado larga para ponerla, así que terminaremos con Automattic, la compañía privada más grande detrás de WordPress.com.

Automattic convirtió todos sus balanceadores de carga a Nginx para WordPress.com en el 2008 (puede leer sobre esto aquí) y migraron el stack de su servidor completamente a Nginx.

Revisándolo en la Vida Real

Si queremos inspeccionar que utiliza el sitio web en producción, usualmente podemos encontrar esta información en los encabezados de respuesta de HTTP. Esto quiere decir que tendremos que dar clic derecho en un sitio > Inspeccionarlo, en las herramientas del desarrollador, elegiremos el panel de la red y cargaremos de nuevo el sitio. Veremos todos los recursos que el sitio web está cargando. Si elegimos un recurso en particular y su pestaña de Encabezados, usualmente veremos la información del servidor. Si el sitio web utiliza CDN, podríamos ver algo como Cloudflare en la línea del servidor o algo como Varnish si el sitio web utiliza un acelerador de HTTP.

Este es un ejemplo de un sitio de WordPress que utiliza una configuración típica de hosting compartido con cPanel, Apache y PHP:

Este es un sitio web en Nginx:

En el lado izquierdo, si lo expandimos, también podremos analizar el tiempo de cada recurso y ver su impacto en el tiempo de carga general de la página.

Resumen

En este artículo, me enfoqué en Nginx vs Apache, y expliqué las principales diferencias arquitectónicas que ayudaron a Nginx a tener más tracción y atención dentro de la arena de los servidores web. Estos son rasgos clave que le dan esa enorme ventaja en nuestra industria tan hambrienta de recursos.

Claro, no todo ejemplo tiene las mismas prioridades y Apache u otras herramientas como Lighttpd, IIS, LiteSpeed, Caddy, podrían ser buenas soluciones.

En Kinsta, utilizamos Nginx como parte de nuestras soluciones de optimización de desempeño en el hosting para WordPress y WooCommerce. Cada sitio de WordPress está albergado en su propio contenedor aislado, que tiene todos los recursos de software necesario para que funcione (Nginx, Linux, PHP, MySQL). Los recursos son 100% privados y no son compartidos con otros sitios.

Asegúrate de revisar Nginx y todos nuestros add-ons premium. Además, echa un vistazo a nuestros servicios de Alojamiento de Aplicaciones y Alojamiento de Bases de Datos para más opciones de alojamiento.

Tonino Jankov

Tonino es emprendedor, entusiasta de Linux y OSS, desarrollador y formador tecnológico. Tiene más de diez años de experiencia en desarrollo y lleva más de tres años en el espacio blockchain. Cuando no está programando, escribe para SitePoint y Alibaba Cloud, se pega un atracón de películas de ficción en Netflix y explora nuevos destinos turísticos.

• Twitter