Nginx - qual é o significado para definir `burst 'se houver a opção` nodelay`

Na configuração do Nginx, quando você deseja limitar a taxa de processamento de solicitações usando o limit_req_zone/ limit_req instructions, eu realmente não entendo o uso da nodelayopção.
No meu entender, ele finaliza os pedidos acima da taxa definida sem atrasá-los. Então parece equivalente a burst=0. É por isso que não entendo o seguinte exemplo:

limit_req zone=one burst=5 nodelay;

burstdefine o número de solicitações que podem ser adiadas; então, qual é o significado para definir burstse existe a nodelayopção?

Acho a limit_reqdocumentação clara o suficiente.

burst está documentado dessa maneira:

Solicitações excessivas atrasam até que seu número exceda o tamanho máximo de intermitência [...]

nodelay está documentado dessa maneira:

Se o atraso de solicitações excessivas enquanto as solicitações estiverem sendo limitadas não for desejado, o parâmetro nodelay deve ser usado

As solicitações são limitadas para atender à taxa definida. Se as solicitações forem recebidas a uma taxa mais alta, não será mais do que o número definido de solicitações por unidade de tempo . Você precisa decidir o que fazer com esses outros pedidos.

• Por padrão (não burst, não nodelay), as solicitações são negadas com um erro HTTP 503.
• Com burst, você empilha o número definido de solicitações em uma fila de espera, mas não as processa mais rapidamente do que as solicitações definidas por taxa de unidade de tempo .
• Com burste nodelay, a fila não estará aguardando e as solicitações serão processadas imediatamente .

Os comentários na resposta original parecem errados.

A questão em questão é qual é a diferença entre, digamos, taxa = 6r / s burst = 0 e taxa = 1r / s burst = 5

As respostas são ótimas para explicar a diferença quando a opção nodelay NÃO está presente - nesse caso, as solicitações ficam na fila com o burst e são 503'd sem o burst.

A resposta original parece certa - com nodelay, as solicitações de burst são processadas imediatamente. E, portanto, a única implicação disso é que não há diferença entre especificar um burst + nodelay versus apenas especificar um limite mais alto com busrt = 0 em primeiro lugar.

Portanto, para responder de forma mais sucinta à pergunta do OP: o significado de burst quando nodelay é especificado é o mesmo que especificar uma taxa maior sem burst.

Com burste nodelayespecificado, acho mais fácil entender o mecanismo dessa maneira (ao contrário do que geralmente é entendido):

1. Você permite um máximo de burstsolicitações. Com $binary_remote_addresse é o número máximo de solicitações que você aceita de um determinado endereço. Toda solicitação aumenta um contador interno. Quando o contador chega, bursttodas as solicitações adicionais são negadas (e o contador não aumenta além do burstvalor).
2. Este contador é diminuído continuamente na taxa especificada usando rate.

Essa lógica sugere que faz todo sentido especificar um burstvalor alto (por exemplo, 100 e mais) e um ratevalor baixo (até algo como 2r / s). Ele lida melhor com a navegação normal (um lote de solicitações paralelas seguidas de um período silencioso) e protege contra o fluxo de solicitações de bot sustentado.

Fiz a pergunta de Nicolas para o cara que escreveu a postagem abaixo no site da nginx. Limite de taxa NGINX . Sua resposta é como abaixo

No antigo limite de taxa, o nginx aceitará solicitações consecutivas em intervalos de 1/6 de segundo. não aceitará uma explosão de solicitações que não satisfaçam esse intervalo de tempo mínimo. Por outro lado, na última definição, o nginx aceitará uma explosão de até 6 solicitações, independentemente do intervalo de tempo entre as solicitações. Link de resposta

Com base na excelente resposta de Dan e no código-fonte do nginx , um resumo conciso do nodelaycomportamento parece ser o seguinte:

• bursté quantas novas solicitações simultâneas são permitidas.
• rateé quantas novas solicitações simultâneas ficam antigas por unidade de tempo. (Essa atualização ocorre gradualmente: uma vez por solicitação, mas não por segundo.)

Estou sugerindo a leitura deste tópico: limit_req_zone limit by location / proxy

e esta resposta: stackoverflow