Nginx: ¿cuál es el significado de definir 'burst' si existe la opción 'nodelay'?

En la configuración de Nginx, cuando desea limitar la velocidad de procesamiento de solicitudes utilizando limit_req_zone/ limit_req instructions, realmente no entiendo el uso de la nodelayopción.
Según tengo entendido, finaliza las solicitudes por encima de la tasa definida sin retrasarlas. Entonces parece equivalente a burst=0. Por eso no entiendo el siguiente ejemplo:

limit_req zone=one burst=5 nodelay;

burstdefine el número de solicitudes que podrían retrasarse, entonces, ¿cuál es el significado de definir burstsi existe la nodelayopción?

Encuentro la limit_reqdocumentación lo suficientemente clara.

burst está documentado de esa manera:

Las solicitudes excesivas se retrasan hasta que su número excede el tamaño máximo de ráfaga [...]

nodelay está documentado de esa manera:

Si no se desea retrasar las solicitudes excesivas mientras las solicitudes están limitadas, se debe usar el parámetro nodelay

Las solicitudes están limitadas para ajustarse a la tasa definida. Si las solicitudes son entrantes a una tasa mayor, no se atenderá más que el número definido de solicitudes por unidad de tiempo . Luego debe decidir qué hacer con esas otras solicitudes.

• De forma predeterminada (no burst, no nodelay), las solicitudes se rechazan con un error HTTP 503.
• Con burst, apila el número definido de solicitudes en una cola de espera, pero no las procesa más rápido que las solicitudes definidas por tasa de unidad de tiempo .
• Con bursty nodelay, la cola no estará esperando y las ráfagas de solicitud se procesarán de inmediato .

Los comentarios sobre la respuesta original parecen incorrectos.

La pregunta en cuestión es cuál es la diferencia entre, digamos, tasa = ráfaga de 6r / s = 0 y tasa = ráfaga de 1r / s = 5 nodos

Las respuestas son excelentes para explicar la diferencia cuando la opción de nodolay NO está presente, en cuyo caso, las solicitudes se ponen en cola con la ráfaga, y son 503 sin la ráfaga.

La respuesta original parece acertada: con nodelay, las solicitudes de ráfaga se procesan de inmediato. Y por lo tanto, la única implicación de esto es que NO hay diferencia entre especificar una ráfaga + nodolay vs. solo especificar un límite superior con busrt = 0 en primer lugar.

Por lo tanto, para responder de manera más sucinta a la pregunta OP: el significado de ráfaga cuando se especifica nodelay es lo mismo que especificar una velocidad mayor sin ráfaga.

Con bursty nodelayespecificado, me resulta más fácil entender el mecanismo de esta manera (al revés de lo que generalmente se entiende):

1. Usted permite un máximo de burstsolicitudes. Con $binary_remote_addrese es el número máximo de solicitudes que acepta de una dirección determinada. Cada solicitud aumenta un contador interno. Cuando el contador alcanza bursttodas las solicitudes adicionales, se deniegan (y el contador no aumenta más allá del burstvalor).
2. Este contador se reduce continuamente a una velocidad especificada usando rate.

Esta lógica sugiere que tiene mucho sentido especificar un burstvalor alto (por ejemplo, 100 y más) y un ratevalor bajo (incluso algo así como 2r / s). Esto maneja la navegación normal (un lote de solicitudes paralelas seguidas de un período de silencio) mejor mientras protege contra el flujo continuo de solicitudes de bot.

Le hice la pregunta de Nicolas al tipo que escribió la siguiente publicación en el sitio web nginx. Limitación de velocidad NGINX . Su respuesta es la siguiente

En el límite de velocidad anterior, nginx aceptará solicitudes consecutivas a intervalos de 1/6 de segundo. no aceptará una ráfaga de solicitudes que no satisfagan ese intervalo de tiempo mínimo. Por otro lado, en la última definición, nginx aceptará una ráfaga de hasta 6 solicitudes, independientemente del intervalo de tiempo entre las solicitudes. Enlace de respuesta

Basado en la excelente respuesta de Dan y en el código fuente de nginx , un resumen conciso del nodelaycomportamiento parece ser el siguiente:

• burstes cuántas nuevas solicitudes concurrentes están permitidas.
• ratees cuántas solicitudes nuevas concurrentes se vuelven viejas por unidad de tiempo. (Esta actualización ocurre gradualmente: una vez por solicitud pero no por segundo).

Sugiero leer este hilo: limit_req_zone limit por ubicación / proxy

y esta respuesta: stackoverflow