Nginx - qual è il significato per definire `burst` se esiste l'opzione` nodelay`

Nella configurazione di Nginx, quando vuoi limitare la velocità di elaborazione della richiesta usando limit_req_zone/ limit_req instructions, non capisco davvero l'uso nodelaydell'opzione.
A mio avviso, termina le richieste al di sopra della tariffa definita senza ritardarle. Quindi sembra equivalente a burst=0. Ecco perché non capisco il seguente esempio:

limit_req zone=one burst=5 nodelay;

burstdefinisce il numero di richieste che potrebbero essere ritardate, quindi qual è il significato da definire burstse esiste l' nodelayopzione?

Trovo la limit_reqdocumentazione abbastanza chiara.

burst è documentato in questo modo:

Le richieste eccessive vengono ritardate fino a quando il loro numero non supera la dimensione massima [...]

nodelay è documentato in questo modo:

Se non si desidera ritardare richieste eccessive mentre le richieste sono limitate, è necessario utilizzare il parametro nodelay

Le richieste sono limitate per adattarsi alla tariffa definita. Se le richieste arrivano a un tasso più elevato, non verrà servito più del numero definito di richieste per unità di tempo . È quindi necessario decidere cosa fare con quelle altre richieste.

• Per impostazione predefinita (no burst, no nodelay), le richieste vengono negate con un errore HTTP 503.
• Con burst, è impilare il numero definito di richieste in una coda di attesa, ma non li elabora più velocemente di quanto gli definiti richieste per unità di tempo dei tassi .
• Con burste nodelay, la coda non attenderà e le raffiche di richieste verranno elaborate immediatamente .

I commenti sulla risposta originale sembrano sbagliati.

La domanda a portata di mano è quale sia la differenza, diciamo rate = 6r / s burst = 0 e rate = 1r / s burst = 5 nodelay

Le risposte sono ottime per spiegare la differenza quando l'opzione nodelay NON è presente - nel qual caso, le richieste fanno la fila con il burst e vengono 503 senza il burst.

La risposta originale sembra perfetta: con nodelay, le richieste di burst vengono elaborate immediatamente. E quindi, l'unica implicazione di ciò è che NON c'è alcuna differenza tra la specifica di un burst + nodelay rispetto al solo specificare un limite superiore con busrt = 0 in primo luogo.

Pertanto, per rispondere in modo più succinto alla domanda OP: il significato di burst quando viene specificato nodelay è lo stesso di specificare un tasso più grande senza burst.

Con burste nodelayspecificato trovo più facile capire il meccanismo in questo modo (viceversa di quanto di solito sia compreso):

1. Consenti un massimo di burstrichieste. Con $binary_remote_addrquesto è il numero massimo di richieste accettate da un determinato indirizzo. Ogni richiesta aumenta un contatore interno. Quando il contatore raggiunge bursttutte le richieste aggiuntive vengono negate (e il contatore non viene aumentato oltre il burstvalore).
2. Questo contatore viene continuamente ridotto a una velocità specificata utilizzando rate.

Questa logica suggerisce che ha perfettamente senso specificare un burstvalore elevato (ad es. 100 e più) e un ratevalore basso (anche qualcosa come 2r / s). Questo gestisce meglio la normale navigazione (una serie di richieste parallele seguite da un periodo di inattività), proteggendo al contempo da flussi di richieste bot sostenute.

Ho fatto la domanda di Nicolas al ragazzo che ha scritto il post qui sotto nel sito web di nginx. NGINX Limitazione della velocità. La sua risposta è la seguente

Nel precedente limite di velocità, nginx accetterà richieste consecutive a intervalli di 1/6 di secondo. non accetterà una serie di richieste che non soddisfano tale intervallo di tempo minimo. D'altra parte in quest'ultima definizione, nginx accetterà una raffica di un massimo di 6 richieste indipendentemente dall'intervallo di tempo tra le richieste. Link di risposta

Sulla base dell'ottima risposta di Dan e del codice sorgente di nginx , un breve riassunto del nodelaycomportamento sembra essere il seguente:

• burstindica quante nuove richieste simultanee sono consentite.
• rateindica quante nuove richieste simultanee diventano obsolete per unità di tempo. (Questo aggiornamento avviene gradualmente: una volta per richiesta ma non al secondo.)

Sto suggerendo di leggere questa discussione: limit_req_zone limit per posizione / proxy

e questa risposta: stackoverflow