servidor nginx

Fuente:
Nginx: ¿qué ventajas e inconvenientes tiene?

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.
Nginx vs Apache
Nginx y Apache son servidores web populares usados para enviar páginas web al navegador del usuario. En nuestro caso, desde un sitio de WordPress con un host. Datos rápidos:

Apache fue lanzado primero en 1995, luego llegó Nginx en el 2004.
Ambos son usados por grandes compañías Fortune 500 alrededor del mundo.
La posición de Nginx en el mercado ha ido en crecimiento constante en los últimos años.
En algunas ocasiones, Nginx ha tenido la ventaja competitiva en términos de desempeño.
Support
Apache
Primero hablaremos de Apache, ya que fue el primero en salir.

Boost your WordPress site’s speed up to 200% just by moving to Kinsta.
MIGRATE TODAY FOR FREE
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 .httaccess.

.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 .httaccess 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.

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.

Según un estudio realizado por W3Techs en el que se ha analizado 10 millones de páginas web se pudo ver que el servidor más utilizado es NGINX, en los 10.000 sitios más visitados según el ránking de Alexa
Nginx (38%) prevalece en ese rango sobre Apache (33%), que sin embargo sigue siendo el servidor web más utilizado a nivel global (60,5 %), considerándose todavía en la mayoría de servidores unix/linux la solución estandar, gracias a su administración sencilla, caracter modular, madurez y buena documentación.
Sin embargo estos datos nos muestran una tendencia y es el auge de Nginx, que se ha convertido en la gran anternativa a Apache, proporcionando servidor web, un servidor proxy inverso (puede actuar conjuntamente con Apache por ej., lo cual podría enmascarar ligeramente los resultados de este tipo de estadísticas) y un equilibrador de carga de la aplicación, que según los datos del estudio le habrían servido para conquistar el nicho de las web de gran tráfico, al ser eficiente y fácilmente escalable.

Nginx es software libre (licencia BSD simplificada) y es utilizado por web tan famosas como: WordPress, Netflix, Hulu, GitHub, MaxCDN, Ohloh, SourceForge, TorrentReactor, Facebook, Yandex o Dropbox

Si tenéis curiosidad por saber que tipo de servidor (Microsoft Azure, Google, Apache, LiteSpeed, Ngnix…) utilizan vuestras web favoritas, podéis obtener esa información mediante la terminal ejecutando curl -I seguido de la url de la web a examinar:
Fuentes:
[Tienes que estar registrado y conectado para ver este vínculo]

Vulnerabilidad en ngnix pone en peligro de ataques DoS a un millón de sitios web
Vulnerabilidad en Nginx afecta a más de 1 millón de páginas web
¿Cómo actualizar Nginx?
Para verificar la versión de Nginx solo tenemos que lanzar el comando:
sudo nginx -v
Si tu sistema disponía de paquetes de NGINX o NGINX Plus previamente instalados, es recomendable realizar una copia de seguridad de los mismos de la siguiente manera:
sudo cp -a /etc/nginx /etc/nginx-plus-backup
sudo cp -a /var/log/nginx /var/log/nginx-plus-backup
En sistemas FreeBSD:
sudo cp -a /usr/local/etc/nginx /usr/local/etc/nginx-plus-backup
sudo cp -a /var/log/nginx /var/log/nginx-plus-backup
Para actualizar los paquetes de Nginx haremos lo siguiente:
apt-get update

sudo apt-get install nginx
En sistemas CentOS:
sudo yum upgrade nginx
En sistemas FreeBSD:
sudo pkg upgrade nginx-plus
Finalmente, ejecutaremos nginx -t para probar la nueva configuración y realizar los cambios necesarios para pasar la prueba con éxito.