¿Por qué Unicorn necesita ser desplegado junto con Nginx?

Nginx es un servidor web puro que está destinado a servir contenido estático y/o redirigir la solicitud a otro socket para manejar la solicitud.

Unicorn es un servidor web Rack y solo tiene la intención de alojar una 'Aplicación Rack' que generalmente genera contenido dinámico. Las aplicaciones de rack también pueden servir contenido estático, pero son menos eficientes que la mayoría de los otros servidores web tradicionales.

La mayoría de las configuraciones RoR utilizan una combinación de servidores web tradicionales y servidores Rack para aplicar lo mejor de sus capacidades. Nginx es increíblemente rápido en la redirección de solicitudes a través del equilibrio de proxy y el suministro de contenido estático. Unicorn es bastante capaz de procesar encabezados HTTP y equilibrar las solicitudes entrantes a Ruby para su procesamiento.

Esta respuesta es complementaria a las otras y explica por qué Unicornio necesita nginx delante de él.

TL;DR La razón por la que Unicorn generalmente se implementa junto con un proxy inverso como nginx es porque sus creadores lo diseñaron deliberadamente, haciendo una compensación por la simplicidad.

En primer lugar, no hay nada que te impida desplegar Unicorn sin un proxy inverso. Sin embargo, eso no sería una muy buena idea; vamos a ver por qué.

Unicorn sigue la filosofía Unix que es hacer una cosa y hacerlo bien , y que es servir clientes rápidos y de baja latencia (veremos lo que esto significa más adelante). El hecho de que Unicorn esté diseñado para clientes rápidos y de baja latencia también implica que no es muy bueno con clientes lentos y de alta latencia , lo cual es cierto. Este es uno de los puntos débiles del Unicornio y es donde entra en juego un proxy inverso: se sienta frente al Unicornio y toma cuidado de esos clientes lentos (veremos cómo más adelante).

Afortunadamente, tal proxy inverso ya existe y se llama nginx .

La decisión de manejar solo clientes rápidos, simplifica enormemente el diseño de Unicorn y permite una base de código mucho más simple y más pequeña, a costa de cierta complejidad añadida en el departamento de implementación (es decir. usted tiene que implementar nginx también, además de Unicorn).

Una decisión alternativa podría ser diseñar Unicornio en de tal manera que no necesitaría un proxy inverso. Sin embargo, esto significa que tendría que implementar una funcionalidad adicional para hacer todas las cosas que ahora hace nginx, lo que resulta en una base de código más compleja y más esfuerzos de ingeniería.

En su lugar, sus creadores tomaron la decisión de aprovechar el software existente que está probado en batalla y muy bien diseñado y evitar perder tiempo y energía en problemas ya resueltos por otro software.

Pero vamos a obtener técnica y responder a su pregunta:

¿Por qué Unicorn necesita ser desplegado junto con nginx?

Estas son algunas de las razones clave:

Unicorn utiliza E / S de bloqueo para clientes

Confiar en un proxy inverso significa que Unicorn no necesita usar E/S sin bloqueo.En su lugar, puede usar E/S de bloqueo, que es inherentemente más simple y fácil de seguir para el programador.

También como el documento DESIGN establece:

[Usando E/S de bloqueo] permite que se siga una ruta de código más simple dentro del intérprete de Ruby y menos llamadas de sistema.

Sin embargo, esto también tiene algunas consecuencias:

Punto clave # 1: Unicorn no es eficiente con clientes lentos

(Por simplicidad, asumimos una configuración con 1 Unicorn worker)

Dado que se usa el bloqueo de E/S, un Unicorn worker solo puede servir a un cliente a la vez, por lo que un cliente lento (ie. uno con una conexión lenta) efectivamente mantendría ocupado al trabajador por un tiempo más largo(que un cliente rápido haría). Mientras tanto, los otros clientes solo esperarían hasta que el trabajador esté libre de nuevo (es decir. las solicitudes se acumularían en la cola).

Para evitar este problema, se implementa un proxy inverso frente a Unicorn, que almacena completamente las solicitudes entrantes y las respuestas de la aplicación, y luego envía cada una de ellas a la vez (también conocidas como spoon-feeds) a Unicorn y a los clientes, respectivamente. En ese sentido, se podría decir que la el proxy inverso "protege" a Unicornio de clientes de red lentos.

Afortunadamente Nginx es un gran candidato para este puesto, ya que está diseñado para manejar miles de cientos de clientes simultáneos de manera eficiente.

Es de crucial importancia que el proxy inverso esté dentro de la misma red local que Unicorn (típicamente en la misma máquina física que se comunica con Unicorn a través de un socket de dominio Unix), para que la latencia de red se mantenga al mínimo.

Así que tal proxy efectivamente juega el papel de un cliente rápido que Unicorn está diseñado para servir en primer lugar, ya que proxies solicitudes a Unicorn rápido y mantiene a los trabajadores ocupados durante el menor tiempo posible (en comparación con la cantidad de tiempo que haría un cliente con una conexión lenta).

Punto clave # 2: Unicorn no es compatible con HTTP / 1.1 keep-alive

Dado que Unicorn usa E / S de bloqueo, también significa que no puede soportar la función HTTP / 1.1 keep-alive, ya que las conexiones persistentes de clientes lentos ocuparían rápidamente a todos los trabajadores Unicornio disponibles.

Por lo tanto, para aprovechar HTTP keep-alive, adivina qué: se utiliza un proxy inverso.

Nginx por otro lado, puede manejar miles de conexiones simultáneas usando solo unos pocos hilos. Por lo tanto, no tiene los límites de concurrencia que tiene un servidor como Unicorn (que esencialmente se limita a la cantidad de procesos de trabajo), lo que significa que puede manejar conexiones persistentes muy bien. Mas de cómo esto realmente funciona se puede encontrar aquí .

Es por eso que nginx acepta conexiones keep-alive de los clientes y los proxies a Unicorn sobre conexiones simples a través de un socket Unix.

Punto # 3: Unicorn no es muy bueno para servir archivos estáticos

Nuevamente, servir archivos estáticos es algo que Unicorn puede hacer pero no está diseñado para hacerlo de manera eficiente.

Por otro lado, los proxies inversos como nginx son mucho mejores en ello (IE. sendfile(2) & caching).

Más

Hay otros puntos que se describen en el documento PHILOSOPHY (véase "Improved Performance Through Reverse Proxying").

Ver también algunas de las características básicas de nginx.

Vemos que aprovechando el software existente (es decir. nginx) y siguiendo la filosofía de Unix de "hacer una cosa y hacerlo bien", Unicorn es capaz de seguir un diseño y una implementación más simples mientras mantiene ser eficiente en el servicio de aplicaciones de rack (por ejemplo. tu aplicación Rails).

Para obtener más información, consulte los documentos philosophy y design de Unicorn que explican con más detalle las opciones detrás del diseño de Unicorn y por qué nginx se considera un buen proxy inverso para Unicorn.

Nginx se puede usar para servir clientes lentos en un servidor unicorn ya que los clientes lentos estrangularían el servidor unicorn. Nginx se utiliza como algún tipo de proxy que almacena en búfer todas las solicitudes y respuestas a clientes lentos.

Véase http://unicorn.bogomips.org /