Nginx - quel est le sens de définir `burst 's'il y a l'option` nodelay`

Dans la configuration Nginx, lorsque vous souhaitez limiter le taux de traitement des demandes en utilisant le limit_req_zone/ limit_req instructions, je ne comprends pas vraiment l'utilisation de l' nodelayoption.
À ma connaissance, il met fin aux demandes au-dessus du taux défini sans les retarder. Cela semble donc équivalent à burst=0. C'est pourquoi je ne comprends pas l'exemple suivant:

limit_req zone=one burst=5 nodelay;

burstdéfinit le nombre de demandes qui pourraient être retardées, alors quelle est la signification de définir bursts'il y a une nodelayoption?

Je trouve la limit_reqdocumentation suffisamment claire.

burst est documenté de cette façon:

Les demandes excessives sont retardées jusqu'à ce que leur nombre dépasse la taille maximale de rafale [...]

nodelay est documenté de cette façon:

Si le retard de demandes excessives pendant que les demandes sont limitées n'est pas souhaité, le paramètre nodelay doit être utilisé

Les demandes sont limitées pour correspondre au taux défini. Si les demandes arrivent à un taux plus élevé, pas plus que le nombre défini de demandes par unité de temps ne sera traité. Vous devez ensuite décider quoi faire avec ces autres demandes.

• Par défaut (non burst, non nodelay), les demandes sont refusées avec une erreur HTTP 503.
• Avec burst, vous empilez le nombre défini de demandes dans une file d'attente, mais vous ne les traitez pas plus rapidement que les demandes définies par taux unitaire de temps .
• Avec burstet nodelay, la file d'attente n'attendra pas et les rafales de requête seront traitées immédiatement .

Les commentaires sur la réponse originale semblent faux.

La question qui se pose est de savoir quelle est la différence entre, par exemple, débit = rafale 6r / s = 0 et débit = rafale 1r / s = 5 nodelay

Les réponses sont excellentes pour expliquer la différence lorsque l'option nodelay n'est PAS présente - dans ce cas, les demandes font la queue avec la rafale et sont 503'd sans la rafale.

La réponse originale semble parfaite - avec nodelay, les demandes de rafale sont traitées immédiatement. Et par conséquent, la seule implication de cela est qu'il n'y a AUCUNE différence entre la spécification d'une rafale + nodelay vs la spécification d'une limite supérieure avec busrt = 0 en premier lieu.

Par conséquent, pour répondre plus succinctement à la question OP: la signification de burst lorsque le nodelay est spécifié est la même que la simple spécification d'un taux plus élevé sans burst.

Avec burstet nodelayspécifié, je trouve plus facile de comprendre le mécanisme comme celui-ci (l'inverse de ce qu'il est généralement compris):

1. Vous autorisez un maximum de burstdemandes. Avec $binary_remote_addrc'est le nombre maximum de demandes que vous acceptez d'une adresse donnée. Chaque demande augmente un compteur interne. Lorsque le compteur atteint bursttoutes les demandes supplémentaires sont refusées (et le compteur n'est pas augmenté au-delà de la burstvaleur).
2. Ce compteur est continuellement diminué à un taux spécifié en utilisant rate.

Cette logique suggère qu'il est parfaitement logique de spécifier une burstvaleur élevée (par exemple 100 et plus) et une ratevaleur faible (même quelque chose comme 2r / s). Cela gère mieux la navigation normale (un lot de demandes parallèles suivies d'une période de silence) tout en protégeant contre le flux de demandes de bot soutenu.

J'ai posé la question de Nicolas au gars qui a écrit le post ci-dessous sur le site Web de nginx. NGINX Rate limit . Sa réponse est la suivante

Dans l'ancienne limite de taux, nginx acceptera les demandes consécutives à des intervalles de 1 / 6e de seconde. il n'acceptera pas une rafale de demandes qui ne satisfont pas à cet intervalle de temps minimum. D'un autre côté, dans cette dernière définition, nginx acceptera une rafale de jusqu'à 6 requêtes quel que soit l'intervalle de temps entre les requêtes. Lien de réponse

Sur la base de l'excellente réponse de Dan et du code source de nginx , un résumé concis du nodelaycomportement semble être le suivant:

• burstest le nombre de nouvelles demandes simultanées autorisées.
• rateest le nombre de nouvelles demandes simultanées devenant anciennes par unité de temps. (Cette mise à jour se fait progressivement: une fois par requête mais pas par seconde.)

Je suggère de lire ce fil: limit_req_zone limit by location / proxy

et cette réponse: stackoverflow