Una de las características más útiles, pero a menudo malinterpretadas y mal configuradas, de NGINX es la limitación de velocidad. Permite limitar la cantidad de solicitudes HTTP que un usuario puede realizar en un período de tiempo determinado. Una solicitud puede ser tan simple como una solicitud GET para la página de inicio de un sitio web o una solicitud POST en un formulario de inicio de sesión.

La limitación de velocidad se puede utilizar con fines de seguridad, por ejemplo, para ralentizar los ataques de fuerza bruta para adivinar contraseñas. Puede ayudar a proteger contra los ataques DDoS limitando la tasa de solicitudes entrantes a un valor típico para los usuarios reales y (con el registro) identificar las URL objetivo. En términos más generales, se utiliza para proteger los servidores de aplicaciones ascendentes de verse desbordados por demasiadas solicitudes de usuarios al mismo tiempo.

En este blog trataremos los aspectos básicos de la limitación de velocidad con NGINX, así como configuraciones más avanzadas. La limitación de velocidad funciona de la misma manera en NGINX Plus.

Cómo funciona la limitación de NGINX

La limitación de velocidad de NGINX utiliza el «algoritmo del cubo agujereado», muy utilizado en telecomunicaciones y redes informáticas con conmutación de paquetes para gestionar los picos de tráfico cuando el ancho de banda es limitado. La analogía es con un cubo en el que se vierte agua por la parte superior y se escapa por la parte inferior; si la velocidad a la que se vierte el agua supera la velocidad a la que se escapa, el cubo se desborda. En términos de procesamiento de solicitudes, el agua representa las solicitudes de los clientes y el cubo representa una cola en la que las solicitudes esperan a ser procesadas según un algoritmo de programación primero en entrar, primero en salir (FIFO). El agua que se derrama representa las solicitudes que salen del búfer para ser procesadas por el servidor, y el desbordamiento representa las solicitudes que se descartan y nunca se atienden.

Configuración de la limitación básica

La limitación de velocidad se configura con dos directivas principales, limit_req_zone y limit_req, como en este ejemplo:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    location /login/ {
        limit_req zone=mylimit;
        
        proxy_pass http://my_upstream;
    }
}

La directiva limit_req_zone define los parámetros para la limitación de velocidad, mientras que limit_req habilita la limitación de velocidad dentro del contexto en el que aparece (en el ejemplo, para todas las solicitudes a /login/).

La directiva limit_req_zone se define normalmente en el bloque http, lo que permite su uso en múltiples contextos. Admite los tres parámetros siguientes:

    Key: define la característica de la solicitud a la que se aplica el límite. En el ejemplo, es la variable NGINX $binary_remote_addr, que contiene una representación binaria de la dirección IP del cliente. Esto significa que estamos limitando cada dirección IP única a la tasa de solicitud definida por el tercer parámetro. (Utilizamos esta variable porque ocupa menos espacio que la representación de cadena de una dirección IP de cliente, $remote_addr).

    Zona: define la zona de memoria compartida que se utiliza para almacenar el estado de cada dirección IP y la frecuencia con la que ha accedido a una URL con límite de solicitudes. Al mantener la información en la memoria compartida, esta se puede compartir entre los procesos de trabajo de NGINX. La definición tiene dos partes: el nombre de la zona identificado por la palabra clave zone= y el tamaño que sigue a los dos puntos. La información de estado de unas 16 000 direcciones IP ocupa 1 megabyte, por lo que nuestra zona puede almacenar unas 160 000 direcciones.

Si se agota el almacenamiento cuando NGINX necesita añadir una nueva entrada, elimina la entrada más antigua. Si el espacio liberado sigue sin ser suficiente para alojar el nuevo registro, NGINX devuelve el código de estado 503 (Servicio temporalmente no disponible). Además, para evitar que se agote la memoria, cada vez que NGINX crea una nueva entrada, elimina hasta dos entradas que no se han utilizado en los últimos 60 segundos.

    Tasa: establece la tasa máxima de solicitudes. En el ejemplo, la tasa no puede superar las 10 solicitudes por segundo. NGINX realiza un seguimiento de las solicitudes con una precisión de milisegundos, por lo que este límite corresponde a 1 solicitud cada 100 milisegundos (ms). Dado que no permitimos ráfagas (véase la siguiente sección), esto significa que una solicitud se rechaza si llega menos de 100 ms después de la anterior permitida.

La directiva limit_req_zone establece los parámetros para la limitación de la tasa y la zona de memoria compartida, pero en realidad no limita la tasa de solicitudes. Para ello, es necesario aplicar el límite a una ubicación específica o a un bloque de servidor incluyendo allí una directiva limit_req. En el ejemplo, estamos limitando la velocidad de las solicitudes a /login/.

Así que ahora cada dirección IP única está limitada a 10 solicitudes por segundo para /login/ o, más precisamente, no puede realizar una solicitud para esa URL en los 100 ms siguientes a la anterior.

Gestión de ráfagas

¿Qué ocurre si recibimos dos solicitudes con una diferencia de 100 ms entre ellas? Para la segunda solicitud, NGINX devuelve el código de estado 503 al cliente. Probablemente esto no sea lo que queremos, ya que las aplicaciones tienden a ser de naturaleza irregular. En su lugar, queremos almacenar en búfer cualquier exceso de solicitudes y atenderlas de manera oportuna. Aquí es donde utilizamos el parámetro burst para limit_req, como en esta configuración actualizada:

location /login/ {
    limit_req zone=mylimit burst=20;
 
    proxy_pass http://my_upstream;
}

El parámetro burst define cuántas solicitudes puede realizar un cliente por encima de la tasa especificada por la zona (con nuestra zona mylimit de ejemplo, el límite de tasa es de 10 solicitudes por segundo, o 1 cada 100 ms). Una solicitud que llega antes de 100 ms después de la anterior se coloca en una cola, y aquí estamos estableciendo el tamaño de la cola en 20.

Esto significa que si llegan 21 solicitudes simultáneamente desde una dirección IP determinada, NGINX reenvía la primera al grupo de servidores ascendentes inmediatamente y coloca las 20 restantes en la cola. A continuación, reenvía una solicitud en cola cada 100 ms y devuelve un 503 al cliente solo si una solicitud entrante hace que el número de solicitudes en cola supere las 20.

Puesta en cola sin retraso

Una configuración con ráfagas da como resultado un flujo de tráfico fluido, pero no es muy práctica porque puede hacer que su sitio parezca lento. En nuestro ejemplo, el vigésimo paquete de la cola espera 2 segundos para ser reenviado, momento en el que la respuesta al mismo podría ya no ser útil para el cliente. Para solucionar esta situación, añada el parámetro nodelay junto con el parámetro burst: 

location /login/ {
    limit_req zone=mylimit burst=20 nodelay;
 
    proxy_pass http://my_upstream;
}

Con el parámetro nodelay, NGINX sigue asignando espacios en la cola según el parámetro burst e impone el límite de velocidad configurado, pero no espaciando el reenvío de las solicitudes en cola. En su lugar, cuando una solicitud llega «demasiado pronto», NGINX la reenvía inmediatamente siempre que haya un espacio disponible para ella en la cola. Marca esa ranura como «ocupada» y no la libera para que la utilice otra solicitud hasta que haya transcurrido el tiempo adecuado (en nuestro ejemplo, después de 100 ms).

Supongamos, como antes, que la cola de 20 ranuras está vacía y que llegan simultáneamente 21 solicitudes desde una dirección IP determinada. NGINX reenvía las 21 solicitudes inmediatamente y marca las 20 ranuras de la cola como ocupadas, y luego libera 1 ranura cada 100 ms. (Si hubiera 25 solicitudes, NGINX reenviaría inmediatamente 21 de ellas, marcaría 20 ranuras como ocupadas y rechazaría 4 solicitudes con el estado 503).

Ahora supongamos que 101 ms después de que se reenviara el primer conjunto de solicitudes, llegan otras 20 solicitudes simultáneamente. Solo se ha liberado 1 espacio en la cola, por lo que NGINX reenvía 1 solicitud y rechaza las otras 19 con el estado 503. Si, en cambio, han pasado 501 ms antes de que lleguen las 20 nuevas solicitudes, hay 5 espacios libres, por lo que NGINX reenvía 5 solicitudes inmediatamente y rechaza 15.

El efecto es equivalente a un límite de velocidad de 10 solicitudes por segundo. La opción nodelay es útil si desea imponer un límite de velocidad sin restringir el espacio permitido entre solicitudes.

Nota: Para la mayoría de las implementaciones, recomendamos incluir los parámetros burst y nodelay en la directiva limit_req.

Limitación de velocidad en dos etapas

Con NGINX Open Source 1.15.7, puede configurar NGINX para permitir una ráfaga de solicitudes que se adapte al patrón típico de solicitudes de los navegadores web y, a continuación, limitar las solicitudes excesivas adicionales hasta un punto, más allá del cual se rechazan las solicitudes excesivas adicionales. La limitación de velocidad en dos etapas se habilita con el parámetro de retraso de la directiva limit_req.

Para ilustrar la limitación de velocidad en dos etapas, aquí configuramos NGINX para proteger un sitio web imponiendo un límite de velocidad de 5 solicitudes por segundo (r/s). El sitio web suele tener entre 4 y 6 recursos por página, y nunca más de 12 recursos. La configuración permite ráfagas de hasta 12 solicitudes, las primeras 8 de las cuales se procesan sin demora. Se añade un retraso después de 8 solicitudes excesivas para hacer cumplir el límite de 5 r/s. Después de 12 solicitudes excesivas, se rechazan todas las solicitudes adicionales.

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;

server {
    listen 80;
    location / {
        limit_req zone=ip burst=12 delay=8;
        proxy_pass http://website;
    }
}

El parámetro de retraso define el punto en el que, dentro del tamaño de la ráfaga, las solicitudes excesivas se limitan (retrasan) para cumplir con el límite de velocidad definido. Con esta configuración, un cliente que realiza un flujo continuo de solicitudes a 8 r/s experimenta el siguiente comportamiento. 

Las primeras 8 solicitudes (el valor del retraso) son proxy por NGINX Plus sin retraso. Las siguientes 4 solicitudes (ráfaga - retraso) se retrasan para que no se supere la tasa definida de 5 r/s. Las siguientes 3 solicitudes se rechazan porque se ha superado el tamaño total de la ráfaga. Las solicitudes posteriores se retrasan.

Ejemplos de configuración avanzada

Al combinar la limitación de velocidad básica con otras funciones de NGINX, puede implementar una limitación del tráfico más matizada.

Lista de permitidos

Este ejemplo muestra cómo imponer un límite de velocidad a las solicitudes de cualquier persona que no esté en una «lista de permitidos».

geo $limit {
    default 1;
    10.0.0.0/8 0;
    192.168.0.0/24 0;
}
 
map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}
 
limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
 
server {
    location / {
        limit_req zone=req_zone burst=10 nodelay;
 
        # ...
    }
}

Este ejemplo utiliza las directivas geo y map. El bloque geo asigna un valor de 0 a $limit para las direcciones IP de la lista de permitidos y 1 para todas las demás. A continuación, utilizamos un mapa para traducir esos valores a una clave, de modo que:

•     Si $limit es 0, $limit_key se establece en la cadena vacía.
•     Si $limit es 1, $limit_key se establece en la dirección IP del cliente en formato binario.

Al combinar ambos, $limit_key se establece en una cadena vacía para las direcciones IP de la lista de permitidos y en la dirección IP del cliente en los demás casos. Cuando el primer parámetro del directorio limit_req_zone (la clave) es una cadena vacía, no se aplica el límite, por lo que las direcciones IP de la lista de permitidos (en las subredes 10.0.0.0/8 y 192.168.0.0/24) no están limitadas. Todas las demás direcciones IP están limitadas a 5 solicitudes por segundo.

La directiva limit_req aplica el límite a la ubicación / y permite ráfagas de hasta 10 paquetes por encima del límite configurado sin retraso en el reenvío. 

Incluir varias directivas limit_req en una ubicación

Se pueden incluir varias directivas limit_req en una sola ubicación. Se aplican todos los límites que coinciden con una solicitud determinada, lo que significa que se utiliza el más restrictivo. Por ejemplo, si más de una directiva impone un retraso, se utiliza el retraso más largo. Del mismo modo, las solicitudes se rechazan si ese es el efecto de cualquier directiva, incluso si otras directivas las permiten.

Ampliando el ejemplo anterior, podemos aplicar un límite de velocidad a las direcciones IP de la lista de permitidos:

http {
    # ...
 
    limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
    limit_req_zone $binary_remote_addr zone=req_zone_wl:10m rate=15r/s;
 
    server {
        # ...
        location / {
            limit_req zone=req_zone burst=10 nodelay;
            limit_req zone=req_zone_wl burst=20 nodelay;
            # ...
        }
    }
}

Las direcciones IP de la lista de permitidos no coinciden con el primer límite de velocidad (req_zone), pero sí con el segundo (req_zone_wl), por lo que se limitan a 15 solicitudes por segundo. Las direcciones IP que no están en la lista de permitidos coinciden con ambos límites de velocidad, por lo que se aplica el más restrictivo: 5 solicitudes por segundo.

Configuración de funciones relacionadas

Registros

De forma predeterminada, NGINX registra las solicitudes que se retrasan o se descartan debido a la limitación de velocidad, como en este ejemplo: 

2015/06/13 04:20:00 [error] 120315#0: *32086 limiting requests, excess: 1.000 by zone "mylimit", client: 192.168.1.2, server: nginx.com, request: "GET / HTTP/1.0", host: "nginx.com"

Los campos de la entrada del registro incluyen:

•     2015/06/13 04:20:00: fecha y hora en que se escribió la entrada del registro.
•     [error]: nivel de gravedad.
•     120315#0: ID del proceso e ID del subproceso del trabajador NGINX, separados por el signo #.
•     *32086: ID de la conexión proxy que se limitó por tasa.
• limiting requests: indicador de que la entrada del registro registra un límite de tasa.
• excess: número de solicitudes por milisegundo por encima de la tasa configurada que representa esta solicitud.
• zone: zona que define el límite de tasa impuesto.
• client: dirección IP del cliente que realiza la solicitud.
• server: dirección IP o nombre de host del servidor.
•     solicitud: solicitud HTTP real realizada por el cliente.
•     host: valor del encabezado HTTP Host.

De forma predeterminada, NGINX registra las solicitudes rechazadas en el nivel de error, como se muestra en [error] en el ejemplo anterior. (Registra las solicitudes retrasadas en un nivel inferior, por lo que avisa de forma predeterminada). Para cambiar el nivel de registro, utilice la directiva limit_req_log_level. Aquí configuramos las solicitudes rechazadas para que se registren en el nivel de aviso: 

location /login/ {
    limit_req zone=mylimit burst=20 nodelay;
    limit_req_log_level warn;
 
    proxy_pass http://my_upstream;
}

Código de error enviado al cliente

De forma predeterminada, NGINX responde con el código de estado 503 (Servicio temporalmente no disponible) cuando un cliente supera su límite de velocidad. Utilice la directiva limit_req_status para establecer un código de estado diferente (444 en este ejemplo): 

location /login/ {
    limit_req zone=mylimit burst=20 nodelay;
    limit_req_status 444;
}

Denegar todas las solicitudes a una ubicación específica

Si desea denegar todas las solicitudes a una URL específica, en lugar de solo limitarlas, configure un bloque de ubicación para ella e incluya la directiva deny all: 

location /foo.php {
    deny all;
}

Hemos cubierto muchas de las funciones de limitación de velocidad que ofrece NGINX, incluyendo la configuración de velocidades de solicitud para diferentes ubicaciones en solicitudes HTTP y la configuración de funciones adicionales para la limitación de velocidad, como los parámetros burst y nodelay. También hemos cubierto la configuración avanzada para aplicar diferentes límites a las direcciones IP de clientes incluidas en la lista de permitidos y en la lista de denegados, y hemos explicado cómo registrar las solicitudes rechazadas y retrasadas. 

Fuentes:

https://nginx.org/en/docs/http/ngx_http_limit_req_module.html

https://blog.nginx.org/blog/rate-limiting-nginx