nginx el servidor http con balanceo de carga !

hola a todos hoy hablo de lo que es nginx el sevidor http con balanceo de carga y que tambien es de codigo libre y de codigo abierto !!

bueno veamos los primero

que es nginx?
es un servidor web/proxy inverso ligero de alto rendimiento y un proxy para protocolos de correo electronico (IMAP/POP3) y licenciado bajo la licencia BSD simplificada, bueno asi que tambien existe una version comercial distribuida bajo el nombre de nginx plus.

bueno su creacion fue realizada para solucionar problemas que presentaban las nuevas tecnologias en sitios son alto trafico de peticiones diarias como ser:
DropBox, CloudFare, Instagram, SoundCloud, Netflix, GitHub, bueno algo mas que agregar es que nginx es multiplataforma.

caracteristicas que tiene nginx

servidor de archivos estaticos, indices y autoindexado.
Proxy inverso con opciones de cache
Tolerancia a fallos
Soporte de HTTP y HTTP2 sobre ssl
Soporte para FastCGI -->(codigo PHP)con opciones de cache
Servidores virtuales basados en nombre y/o en direcciones IP
Soporte para autenticacion
Compatible con IPV6
Compresion gzip
Habilitado para soportar mas de 10.000 conexiones simultaneas.

bueno en la parte de lo que es escribo sobre fastCGI o tambien llamado proxy FastCGI dentro de Nginx generalmente se usa para traducir las solicitudes de los clientes para un servidor de aplicaciones que no maneja o no las solicitudes del cliente directamente. FastCGI es un protocolo basado en el protocolo CGI anterior, o interfaz de puerta de enlace común, destinado a mejorar el rendimiento al no ejecutar cada solicitud como un proceso separado. Se utiliza para interactuar eficientemente con un servidor que procesa solicitudes de contenido dinámico.

Uno de los principales casos de uso del proxy FastCGI dentro de Nginx es para el procesamiento de PHP. A diferencia de Apache, que puede manejar el procesamiento de PHP directamente con el uso del módulo mod_php, Nginx debe confiar en un procesador PHP separado para manejar las solicitudes de PHP. Muy a menudo, este procesamiento se maneja con php-fpm, un procesador PHP que ha sido ampliamente probado para trabajar con Nginx.

Nginx con FastCGI se puede usar con aplicaciones que usan otros lenguajes siempre que haya un componente accesible configurado para responder a solicitudes FastCGI.

Conceptos básicos de proxy de FastCGI
en general, las solicitudes de proxy implican al servidor proxy, en este caso Nginx, reenviando las solicitudes de los clientes a un servidor back-end.

La directiva que utiliza Nginx para definir el servidor real a proxy utilizando el protocolo FastCGI es fastcgi_pass. Por ejemplo, para reenviar cualquier solicitud de coincidencia de PHP a un backend dedicado a manejar el procesamiento de PHP utilizando el protocolo FastCGI, un bloque de ubicación básica puede tener un aspecto similar a este:

# server context

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
}

. . .

El fragmento de arriba no funcionará de manera predeterminada, ya que brinda muy poca información. Cada vez que se realiza una conexión de proxy, la solicitud original debe traducirse para garantizar que la solicitud de proxy tenga sentido para el servidor de fondo. Dado que estamos cambiando los protocolos con un pase FastCGI, esto implica un trabajo adicional.

Si bien el proxying http-to-http principalmente implica aumentar los encabezados http para garantizar que el back-end tenga la información que necesita para responder al servidor proxy en nombre del cliente, FastCGI es un protocolo separado que no puede leer los encabezados http. Debido a esta consideración, cualquier información pertinente se debe pasar al backend por otros medios.

El método principal para pasar información adicional cuando se usa el protocolo FastCGI es con parámetros. El servidor de fondo debe configurarse para leer y procesar estos, modificando su comportamiento en función de lo que encuentre. Nginx puede establecer parámetros FastCGI usando la directiva fastcgi_param.

La configuración mínima básica que realmente funcionará en un escenario de proxy FastCGI para PHP es algo como esto:

# server context

location ~ \.php$ {
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
}

. . .

En la configuración anterior, configuramos dos parámetros FastCGI, llamados REQUEST_METHOD y SCRIPT_FILENAME. Ambos son necesarios para que el servidor de back-end comprenda la naturaleza de la solicitud. El primero le dice qué tipo de operación debe realizar, mientras que el segundo le indica al archivo ascendente qué archivo ejecutar.

En el ejemplo, usamos algunas variables de Nginx para establecer los valores de estos parámetros. La variable $request_method contendrá siempre el método http solicitado por el cliente.

El parámetro SCRIPT_FILENAME se establece en una combinación de la variable $ document_root y la variable $fastcgi_script_name. $Document_root contendrá la ruta al directorio base, tal como lo establece la directiva raíz. La variable $fastcgi_script_name se establecerá en el URL de solicitud. Si el URL de solicitud finaliza con una barra inclinada (/), el valor de la directiva fastcgi_index se agregará al final. Este tipo de definiciones de ubicación autorreferencial son posibles porque estamos ejecutando el procesador FastCGI en la misma máquina que nuestra instancia de Nginx.

Veamos otro ejemplo:

# server context
root /var/www/html;

location /scripts {
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_index index.php;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
}

. . .

Si la ubicación anterior se selecciona para gestionar una solicitud de / scripts / test /, el valor de SCRIPT_FILENAME será una combinación de los valores de la directiva raíz, el URL de solicitud y la directiva fastcgi_index. En este ejemplo, el parámetro se establecerá en /var/www/html/scripts/test/index.php.

Hicimos otro cambio significativo en la configuración anterior en el sentido de que especificamos el backend FastCGI usando un socket Unix en lugar de un socket de red. Nginx puede usar cualquier tipo de interfaz para conectarse al FastCGI en sentido ascendente. Si el procesador FastCGI vive en el mismo host, normalmente se recomienda un socket Unix para mayor seguridad.

Breaking Out FastCGI Configuration
Una regla clave para el código de mantenimiento es tratar de seguir el principio DRY ("No repetir"). Esto ayuda a reducir los errores, aumentar la reutilización y permite una mejor organización. Teniendo en cuenta que una de las principales recomendaciones para la administración de Nginx es establecer siempre las directivas en su alcance más amplio aplicable, estos objetivos fundamentales también se aplican a la configuración de Nginx.

Cuando se trata de configuraciones de proxy FastCGI, la mayoría de las instancias de uso compartirán una gran mayoría de la configuración. Debido a esto y debido a la forma en que funciona el modelo de herencia Nginx, casi siempre es ventajoso declarar parámetros en un ámbito general.

Declaración de detalles de configuración de FastCGI en contextos principales

Una forma de reducir la repetición es declarar los detalles de configuración en un contexto principal superior. Todos los parámetros fuera del Fastcgi_pass real pueden especificarse en niveles superiores. Caen en cascada hacia abajo en el lugar donde ocurre el pase. Esto significa que varias ubicaciones pueden usar la misma configuración.

Por ejemplo, podríamos modificar el último fragmento de configuración de la sección anterior para que sea útil en más de una ubicación:

# server context
root /var/www/html;

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;

location /scripts {
    fastcgi_pass unix:/var/run/php5-fpm.sock;
}

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
}

. . .

En el ejemplo anterior, tanto la declaración fastcgi_param como la directiva fastcgi_index están disponibles en los dos bloques de ubicación que vienen después. Esta es una forma de eliminar declaraciones repetitivas.

Sin embargo, la configuración anterior tiene una seria desventaja. Si se declara cualquier fastcgi_param en el contexto inferior, ninguno de los valores de fastcgi_param del contexto primario se heredará. O bien usa solo los valores heredados, o no usa ninguno de ellos. La directiva fastcgi_param es una directiva de matriz en el lenguaje de Nginx.

Desde la perspectiva de los usuarios, una directiva de matriz es básicamente cualquier directiva que se puede usar más de una vez en un único contexto. Cada declaración posterior agregará la nueva información a lo que Nginx sabe de las declaraciones anteriores.

La directiva fastcgi_param se diseñó como una directiva de matriz para permitir a los usuarios establecer múltiples parámetros.
Las directivas de matriz heredan los contextos secundarios de una manera diferente a otras directivas.

La información de las directivas de matriz heredará los contextos secundarios solo si no están presentes en ningún lugar en el contexto secundario.

Esto significa que si usa fastcgi_param dentro de su ubicación, eliminará completamente los valores heredados del contexto primario. Por ejemplo, podríamos modificar ligeramente la configuración anterior:

# server context
root /var/www/html;

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;

location /scripts {
    fastcgi_pass unix:/var/run/php5-fpm.sock;
}

location ~ \.php$ {
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_pass 127.0.0.1:9000;
}

. . .

A primera vista, puede pensar que los parámetros REQUEST_METHOD y SCRIPT_FILENAME se heredarán en el segundo bloque de ubicación, con el parámetro QUERY_STRING estando adicionalmente disponible para ese contexto específico.

Lo que sucede realmente es que todos los valores padre fastcgi_param se borran en el segundo contexto y solo se establece el parámetro QUERY_STRING. Los parámetros REQUEST_METHOD y SCRIPT_FILENAME permanecerán desarmados.

Una nota sobre valores múltiples para parámetros en el mismo contexto Una cosa que definitivamente vale la pena mencionar en este punto son las implicaciones de establecer múltiples valores para los mismos parámetros dentro de un solo contexto. Tomemos el siguiente ejemplo como punto de discusión:

# server context

location ~ \.php$ {
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param SCRIPT_FILENAME $request_uri;

    fastcgi_param DOCUMENT_ROOT initial;
    fastcgi_param DOCUMENT_ROOT override;

    fastcgi_param TEST one;
    fastcgi_param TEST two;
    fastcgi_param TEST three;

    fastcgi_pass 127.0.0.1:9000;
}

. . .

bueno eso es todo por ahora en este post.