Esquema de NGINX
NGINX surgió debido a una prueba agotadora, en la que un servidor tiene que alcanzar 10,000 conexiones de cliente al mismo tiempo. Utiliza una arquitectura impulsada por eventos no sincronizada para hacer frente a esta carga prodigiosa. Y su diseño significa que puede soportar cargas elevadas y cargas que varían enormemente en su ritmo, aprovechando las predicciones para el uso de RAM, uso de CPU y latencia para lograr una mayor eficiencia.
NGINX es una creación de Igor Sysoev en 2002. Lo vio como una solución al problema de C10K que causaba problemas a los servidores web que manejaban miles de conexiones al mismo tiempo. Lo lanzó inicialmente en 2004, y esta primera iteración logró su objetivo mediante la utilización de una arquitectura asíncrona impulsada por eventos.
Desde su lanzamiento público, NGINX ha seguido siendo una opción popular, gracias a su ligero uso de recursos y su flexibilidad para escalar simplemente incluso con un equipo mínimo. Como testificarán los fanáticos, NGINX es excelente para servir contenido estático con velocidad y eficiencia, debido a su diseño para pasar solicitudes dinámicas a diferentes software, que se adaptan a los propósitos específicos de manera más efectiva.
Los administradores tienden a elegir NGINX debido a la eficiencia y capacidad de respuesta de los recursos.
Arquitectura básica
- Enfoque impulsado por eventos
- Trata simultáneamente numerosas solicitudes en un hilo
NGINX tiene una arquitectura impulsada por eventos y utiliza el manejo de solicitudes asincrónicas.
Fue diseñado para utilizar un algoritmo de manejo de conexión controlado por eventos sin bloqueo. Esto significa que puede atender miles de solicitudes de conexión simultáneas en un solo hilo de procesamiento y trabajar rápidamente incluso cuando los recursos son limitados.
NGINX funciona bien en sistemas de baja potencia, así como en sistemas que necesitan manejar cargas sustanciales.
Esquema de Apache
A Robert McCool se le atribuye la producción del servidor HTTP Apache en 1995. Pero a partir de 1999, ha sido administrado y mantenido por la Apache Software Foundation. El servidor HTTP Apache se conoce generalmente como "Apache", debido a que el servidor web HTTP es el proyecto inicial y más popular de la fundación.
Desde 1996, Apache ha sido reconocido como el servidor más popular de Internet, lo que ha llevado a Apache a recibir un considerable soporte integrado y documentación de proyectos de software posteriores. Los administradores generalmente eligen Apache debido a su potencia, amplio soporte y considerable flexibilidad.
Se puede ampliar con su sistema de módulos cargables dinámicamente y es capaz de procesar varios idiomas interpretados sin necesidad de conectarse a un software externo.
Arquitectura básica
- Enfoque impulsado por procesos
- Crea un nuevo hilo para cada solicitud.
Apache adopta un enfoque de subprocesos múltiples utilizando múltiples módulos de procesamiento que cuentan con tres tipos de algoritmos para manejar solicitudes. Hay tres porque cada uno se adapta mejor a un escenario diferente para el servidor.
Estos MPM (módulos de multiprocesamiento) dan al sistema la flexibilidad de elegir diferentes algoritmos y diferentes conexiones.
Además, las diferentes versiones de Apache 2 utilizan diferentes módulos de procesamiento.
Los tres MPM principales de Apache son:
- MPM de proceso (pre-bifurcación)
- Trabajador MPM
- Evento MPM
Apache (2.2) de estilo antiguo usa mpm_worker, mpm_prefork y mod_php. Apache 2.4 (nuevo Apache) está configurado para usar mpm_event, php-fpm.
Apache 2.2 está configurado en modo previo a la bifurcación (mpm_prefork) de forma predeterminada. Responde a un número específico de procesos y cada uno de ellos puede atender una solicitud en cualquier momento. Otra forma de decir esto es que Apache crea un nuevo hilo para atender cada solicitud de conexión sucesiva.
En caso de que se lo pregunte, un subproceso es la secuencia más pequeña de instrucciones programadas que un planificador puede administrar por sí mismo, y un subproceso generalmente contribuye a un proceso general más grande.
Dicho esto, la arquitectura básica de Apache es tal que puede hacer que necesite muchos recursos, lo que ralentiza todo.
Apache vs NGINX - Manejo de conexiones
Uno de los contrastes más significativos entre Nginx y Apache es sus respectivas capacidades de manejo de conexión y tráfico.
A medida que NGINX se lanzó después de Apache, el equipo detrás de él tuvo una mayor conciencia de los problemas de concurrencia que afectan a los sitios a escala. El equipo de NGINX pudo utilizar este conocimiento para construir NGINX desde cero para utilizar un algoritmo sin bloqueo, asíncrono y controlado por eventos para manejar conexiones. NGINX está diseñado para generar procesos de trabajo capaces de manejar muchas conexiones, incluso miles, cortesía de una función de bucle rápido. Esto busca eventos y los procesa continuamente. Como el trabajo real se desacopla fácilmente de las conexiones, cada trabajador es libre de hacer conexiones solo después de que se activen nuevos eventos.
Cada conexión manejada por los trabajadores está ubicada en el bucle de eventos, junto con muchas otras. Los eventos dentro del bucle se someten a un procesamiento asincrónico, de modo que el trabajo se maneja sin bloqueos. Y cada vez que se cierra cada conexión, se eliminará del bucle. NGINX puede escalar extremadamente lejos incluso con recursos limitados, gracias a esta forma de procesamiento de conexión. Como el servidor de un solo subproceso no genera procesos para manejar cada nueva conexión, la utilización de la CPU y la memoria se mantiene bastante constante durante los períodos de gran carga.
Apache ofrece varios módulos de multiprocesamiento. Estos también se conocen como MPM y son responsables de determinar cómo manejar las solicitudes de los clientes. Esto permite a los administradores cambiar su arquitectura de manejo de conexiones de manera simple, rápida y conveniente.
Entonces, ¿qué son estos módulos?
mpm-prefork
Este módulo de Apache crea procesos con un hilo para manejar cada solicitud, y cada niño puede acomodar una conexión a la vez. Siempre que el volumen de solicitudes sea menor que el de los procesos, este módulo es capaz de un rendimiento extremadamente rápido.
Pero puede demostrar una seria caída en la calidad cuando la cantidad de solicitudes supera la cantidad de procesos, lo que significa que este módulo no siempre es la opción correcta.
Cada proceso con este módulo también tiene un efecto importante en el consumo de RAM, lo que dificulta lograr un escalado efectivo. Sin embargo, aún podría ser una opción sólida cuando se utiliza junto con componentes adicionales construidos sin tener en cuenta los hilos. Por ejemplo, como PHP carece de seguridad para subprocesos, este módulo podría ser la mejor manera de trabajar con mod_php (el módulo de Apache para procesar estos archivos específicos) de forma segura.
mpm_worker
El módulo mpm_worker de Apache está diseñado para generar procesos capaces de administrar numerosos subprocesos cada uno, y cada uno de ellos maneja una conexión. Los subprocesos demuestran ser más eficientes que los procesos, por lo que este MPM ofrece un escalado más fuerte que el módulo discutido anteriormente.
Como no hay más subprocesos que procesos, las conexiones nuevas pueden ocupar uno de los subprocesos libres en lugar de esperar a que aparezca otro proceso adecuado.
mpm_event
El tercer módulo de Apache se puede considerar similar al módulo mpm_worker mencionado anteriormente en la mayoría de las situaciones, aunque se ha optimizado para adaptarse a las conexiones de mantenimiento. Esto significa que, cuando se usa el módulo de trabajo, las conexiones continúan conteniendo subprocesos, ya sea que las solicitudes se realicen activamente o no durante todo el período durante el cual la conexión permanece activa.
Está claro que la arquitectura de manejo de conexiones de Apache ofrece una flexibilidad considerable al seleccionar varias conexiones y algoritmos de manejo de solicitudes. Las opciones proporcionadas son principalmente el resultado del avance continuo del servidor, así como de la creciente demanda de simultaneidad a medida que Internet ha cambiado de manera tan dramática.
Apache vs NGINX: manejo de contenido estático y dinámico
Al enfrentar a Nginx vs Apache, su capacidad para manejar solicitudes de contenido estático y dinámico es un punto común de comparación. Miremos más de cerca.
NGINX no está diseñado para el procesamiento nativo de contenido dinámico: tiene que pasar a un procesador externo para manejar PHP y otras solicitudes de contenido dinámico. Esperará a que se devuelva el contenido cuando se haya renderizado, antes de transmitir los resultados al cliente.
La comunicación debe establecerse entre NGINX y un procesador a través de un protocolo que NGINX pueda admitir (por ejemplo, FastCGI, HTTP, etc.). Esto puede hacer que las cosas sean un poco más complicadas de lo que los administradores pueden preferir, especialmente cuando se intenta anticipar el volumen de conexiones que se permitirán; será necesaria una conexión adicional para cada llamada al procesador correspondiente.
Aún así, existen algunos beneficios al usar este método. Como el intérprete dinámico no está integrado en el proceso de trabajo, la sobrecarga se aplica solo al contenido dinámico. Por otro lado, el contenido estático puede ser servido en un proceso más simple, durante el cual el intérprete solo es contactado cuando se considera necesario.
Los métodos tradicionales basados en archivos de los servidores Apache significan que son capaces de manejar contenido estático, y su rendimiento es principalmente una función de los métodos MPM cubiertos anteriormente.
Pero Apache también está diseñado para procesar contenido dinámico, integrando un procesador de lenguajes adecuados en cada instancia de trabajador. Como resultado, Apache puede acomodar contenido dinámico en el propio servidor, sin necesidad de depender de ningún componente externo. Estos se pueden activar gracias a los módulos cargables dinámicamente.
El manejo interno de contenido dinámico de Apache permite configurarlo más fácilmente y no es necesario coordinar la comunicación con otro software. Los módulos pueden intercambiarse siempre y cuando los requisitos de contenido cambien.
NGINX o Apache: ¿cómo funciona la configuración a nivel de directorio?
Otra de las diferencias más destacadas que los administradores discuten cuando discuten Apache vs NGINX se relaciona con la configuración a nivel de directorio y si está permitido en sus directorios de contenido. Exploremos lo que esto significa, comenzando con Apache.
Con Apache, se permite la configuración adicional a nivel de directorio, mediante la inspección de archivos ocultos dentro de los directorios de contenido y la interpretación de sus directivas. Se les conoce como .htaccess .
Como los archivos .htaccess se encuentran dentro de los directorios de contenido, Apache verifica cada componente en la ruta a los archivos solicitados, aplicando esas directivas adentro. Esencialmente, esto permite que el servidor web se configure de manera descentralizada, normalmente utilizado para la implementación de URL reescritas, restricciones de acceso, autenticación y autorización, así como políticas de almacenamiento en caché.
Aunque estos ofrecen configuración en el archivo de configuración principal de Apache , existen algunas ventajas clave para los archivos .htaccess. En primer lugar, se implementan instantáneamente sin necesidad de recargar el servidor, ya que se interpretan siempre que se encuentran en una ruta de solicitud.
En segundo lugar, los archivos .htaccess permiten a los usuarios sin privilegios tomar el control de elementos específicos de su contenido web sin otorgarles un control completo sobre el archivo de configuración completo.
Esto crea una forma sencilla para que cierto software, como los sistemas de gestión de contenido, configure los entornos sin dar acceso a los archivos de configuración centrales. Los proveedores de alojamiento compartido lo utilizan para mantener el control de las configuraciones primarias, incluso cuando ofrecen a los clientes su propio control de directorio.
Con NGINX, la interpretación de los archivos .htaccess está fuera de discusión. También carece de una forma de evaluar la configuración por directorio más allá del archivo de configuración principal. Como resultado, se podría decir que ofrece menos flexibilidad que Apache, aunque también tiene una serie de beneficios.
Específicamente, el rendimiento mejorado es una de las principales ventajas en comparación con el sistema de configuración a nivel de directorio .htaccess. En el caso de las configuraciones estándar de Apache que admiten .htaccess en cualquier directorio, el servidor evalúa los archivos en cada directorio principal que conduce al archivo solicitado, siempre que se realiza una solicitud. Cualquier archivo .htaccess que se encuentre durante esta búsqueda se leerá antes de ser interpretado.
Por lo tanto, NGINX puede atender solicitudes en menos tiempo, debido a sus búsquedas de directorio único y lecturas de archivos para cada solicitud. Por supuesto, esto se basa en que los archivos estén ubicados en un directorio con una estructura convencional.
Otro beneficio que ofrece NGINX con la configuración a nivel de directorio se relaciona con la seguridad. La distribución del acceso también conduce a una distribución de la responsabilidad de la seguridad a usuarios individuales, y es posible que no todos sean dignos de confianza. Cuando los administradores retienen el control de todo el servidor, hay menos riesgo de problemas relacionados con la seguridad que otorgan acceso a personas en las que no se puede confiar.
¿Cómo funciona la interpretación basada en archivos y URI con NGINX y Apache?
Cuando se habla de Nginx vs Apache, es importante recordar la forma en que el servidor web interpreta las solicitudes y las asigna a los recursos del sistema, es otro tema vital.
Cuando se creó NGINX, se diseñó para funcionar como servidor web y proxy. La arquitectura exigida para cumplir con ambos roles significa que NGINX trabaja principalmente con URI y se traduce al sistema de archivos según sea necesario. Esto es evidente en varias formas en las que funcionan sus archivos de configuración.
NGINX no tiene medios para determinar la configuración del directorio del sistema de archivos. Como resultado, está diseñado para analizar el URI. Los principales bloques de configuración de NGINX son los bloques de ubicación y servidor: el primero coincide con partes del URI que vienen después del host y el puerto, mientras que el segundo interpreta los hosts solicitados. Las solicitudes se interpretan como un URI, en lugar de una de las ubicaciones del sistema de archivos.
En el caso de archivos estáticos, las solicitudes se asignan finalmente a una ubicación del sistema de archivos. NGINX elige la ubicación y los bloques de servidor para manejar la solicitud específica, antes de combinar la raíz del documento con el URI. También adapta lo que sea necesario, según la configuración especificada.
Con NGINX diseñado para analizar solicitudes como URI en lugar de posiciones del sistema de archivos, simplifica la funcionalidad en varias áreas. Específicamente, en los siguientes roles de servidor: web, proxy y correo. Esto significa que NGINX se configura fácilmente al diseñar las respuestas adecuadas a diversos patrones de solicitud, y NGINX solo verifica los sistemas de archivos cuando está preparado para atender la solicitud. Es por eso que no implementa archivos .htaccess.
Interprete las solicitudes como recursos físicos en un sistema de archivos. También puede interpretar las solicitudes como una ubicación de URI, lo que exige una evaluación un poco menos específica. Generalmente, Apache utiliza bloques <Directory> o <Files> para estos propósitos, y bloques <Location> para recursos que son más abstractos.
Como Apache fue concebido como un servidor para la web, su función estándar es interpretar las solicitudes como recursos tradicionales del sistema de archivos. Este proceso comienza con la raíz del documento y cambia la parte de la solicitud que viene después de los números de puerto y host, ya que intenta localizar un archivo real. Entonces, en la web, la jerarquía del sistema de archivos aparece en forma de árbol de documentos disponible.
Apache ofrece varias alternativas para cuando las solicitudes no coinciden con los sistemas de archivos subyacentes. Por ejemplo, las directivas de Alias se pueden utilizar para mapear ubicaciones alternativas. Aprovechar los bloques <Location> es una forma de trabajar con el URI en lugar del sistema de archivos. Se pueden utilizar varias variantes de expresión para aplicar la configuración en todos los sistemas de archivos con mayor flexibilidad.
Como Apache es capaz de funcionar en el espacio web y los sistemas de archivos subyacentes, se centra más en los métodos del sistema de archivos. Esto es evidente en varias opciones de diseño, como la presencia de archivos .htaccess en la configuración por directorio. La documentación de Apache aconseja no utilizar bloques basados en URI para inhibir el acceso cuando las solicitudes coinciden con esos sistemas de archivos subyacentes.
NGINX vs Apache: ¿Cómo funcionan los módulos?
Al considerar Apache vs NGINX, tenga en cuenta que se pueden ampliar con sistemas de módulos, aunque funcionan de formas significativamente diferentes.
Los módulos NGINX deben elegirse y compilarse en su software central, ya que no se pueden cargar dinámicamente. Como resultado, algunos usuarios de NGINX son menos flexibles. Esto puede ser particularmente cierto para aquellos que se sienten descontentos con la administración de su software compilado que está ubicado en un lugar externo al sistema de empaquetado convencional de la distribución.
Aunque los paquetes generalmente incluyen módulos que se usan comúnmente, necesitaría crear el servidor desde la fuente si necesita un módulo no estándar. Aún así, NGINX es increíblemente útil, ya que permite a los usuarios dictar lo que quieren de su servidor al incluir solo la funcionalidad que planea utilizar.
Para muchas personas, NGINX parece ofrecer una mayor seguridad como resultado de esto. Los componentes arbitrarios no pueden conectarse al servidor. Pero si el servidor se encuentra en un escenario en el que esto parece probable, es posible que ya se haya visto afectado.
Además, los módulos NGINX ofrecen limitación de velocidad, geolocalización, soporte de proxy, reescritura, cifrado, funcionalidad de correo, compresión y más.
Con Apache, el sistema de módulos brinda a los usuarios la opción de cargar o descargar módulos dinámicamente según sus necesidades individuales. Los módulos se pueden encender y apagar aunque el núcleo de Apache permanezca presente en todo momento, por lo que puede agregar o quitar funcionalidad adicional y conectarse al servidor principal.
Con Apache, esta funcionalidad se utiliza para una amplia gama de tareas y, como esta plataforma es tan madura, los usuarios pueden elegir entre una gran variedad de módulos. Cada uno de estos puede ajustar la funcionalidad central del servidor de varias formas, por ejemplo, mod_php incorpora un intérprete de PHP en todos los trabajadores en ejecución.
Sin embargo, los módulos no están restringidos al procesamiento de contenido dinámico: algunas de sus funciones incluyen la autenticación de clientes, reescritura de URL, almacenamiento en caché, proxy, cifrado, compresión y más. Con módulos dinámicos, los usuarios pueden expandir la funcionalidad principal de manera significativa, sin necesidad de un trabajo adicional extenso.
NGINX o Apache: ¿Cómo funcionan el soporte, la documentación y otros elementos clave?
Al intentar decidir entre Apache o Nginx, otro factor importante a tener en cuenta es la configuración y el nivel de soporte con otro software.
El nivel de soporte para NGINX está creciendo, a medida que un mayor número de usuarios continúan implementándolo. Sin embargo, todavía le queda mucho camino por recorrer para ponerse al día con Apache en ciertas áreas.
Érase una vez, era difícil recopilar documentación detallada para NGINX (en inglés), ya que la mayor parte de su documentación inicial estaba en ruso. Sin embargo, la documentación se ha expandido desde que el interés en NGINX ha crecido, por lo que hay una gran cantidad de recursos de administración en el sitio web oficial de NGINX y en terceros.
En el tema de las aplicaciones de terceros, la documentación y el soporte son más fáciles de encontrar. Los mantenedores de paquetes están comenzando a ofrecer opciones entre la configuración automática de NGINX y Apache. Es fácil configurar NGINX para complementar software alternativo sin ningún tipo de soporte, siempre que el proyecto específico documente requisitos claros (como encabezados, permisos, etc.).
El soporte para Apache es bastante fácil de encontrar, ya que ha sido un servidor tan popular durante tanto tiempo. Se ofrece una extensa biblioteca de documentación propia y de terceros, para el servidor central y las situaciones basadas en tareas que requieren que Apache esté conectado con software adicional.
Además de la documentación, numerosos proyectos y herramientas en línea implican herramientas que deben iniciarse dentro de una configuración de Apache. Esto podría estar presente en los proyectos o los paquetes gestionados por el equipo responsable del embalaje de la distribución.
Apache recibe un apoyo decente de proyectos externos principalmente debido a la participación de mercado y la gran cantidad de años que ha estado operando. Puede haber una mayor probabilidad de que los administradores tengan experiencia en el uso de Apache, no solo porque es tan frecuente, sino porque muchos de ellos comienzan en escenarios de alojamiento compartido que dependen de Apache, debido a las capacidades de administración distribuida de .htaccess.
NGINX vs Apache: trabajar con ambos
Ahora que hemos explorado las ventajas y desventajas de NGINX y Apache, podría estar en una mejor posición para comprender si Apache o NGINX es lo mejor para usted. Pero muchos usuarios descubren que pueden aprovechar los beneficios de ambos servidores utilizándolos juntos.
La configuración tradicional para usar NGINX y Apache al unísono es posicionar a NGINX por delante de Apache. De esta manera, sirve como un proxy inverso, lo que le permite adaptarse a todas las solicitudes de los clientes. ¿Porque es esto importante? Porque aprovecha las rápidas velocidades de procesamiento y las capacidades de NGINX para manejar muchas conexiones al mismo tiempo.
En el caso de contenido estático, NGINX es un servidor fantástico, ya que los archivos se envían al cliente de forma directa y rápida. Con contenido dinámico, NGINX envía solicitudes a Apache para que sean procesadas. Apache luego traerá de vuelta las páginas renderizadas. Después de esto, NGINX puede enviar contenido a los clientes.
Mucha gente encuentra que esta es la configuración ideal, ya que permite que NGINX funcione como una máquina de clasificación, manejando todas las solicitudes y pasando aquellas que no tienen capacidad nativa para atender. Si reduce el nivel de solicitudes de Apache, es posible reducir el nivel de bloqueo que sigue cuando los subprocesos o procesos de Apache están ocupados.
Con esta configuración, los usuarios pueden escalar mediante la adición de servidores backend adicionales según sea necesario. NGINX puede configurarse para pasar a varios servidores con facilidad, aumentando el rendimiento de la configuración y su resistencia a fallas.
Apache vs NGINX - Reflexiones finales
Es justo decir que NGINX y Apache ofrecen un rendimiento de calidad: son flexibles, capaces y potentes. La elección del servidor que mejor se adapte a sus necesidades depende en gran medida de la evaluación de sus requisitos individuales y de las pruebas con los patrones que cree que es probable que vea.
Varias diferencias entre estos proyectos tienen un efecto tangible en las capacidades, el rendimiento y el tiempo necesario para implementar cada solución de manera eficaz. Pero estos tienden a ser el resultado de numerosas compensaciones que no deben descartarse fácilmente. Cuando todo está dicho y hecho, no existe un servidor web que satisfaga las necesidades de todos en todo momento, por lo que es mejor utilizar la solución que mejor se adapte a sus objetivos.