Nginx - O que a opção nodelay faz ao limitar as solicitações?

Question

Com as solicitações de módulo nginx HttpLimitReq podem ser limitadas por IP. No entanto, não estou entendendo o que a opção "nodelay" faz.

If the excess requests within the limit burst delay are not necessary, you should use the nodelay

limit_req   zone=one  burst=5  nodelay;

    

Answer 1

A documentação aqui tem uma explicação que parece com o que você quer saber:

The directive specifies the zone (zone) and the maximum possible bursts of requests (burst). If the rate exceeds the demands outlined in the zone, the request is delayed, so that queries are processed at a given speed

Pelo que entendi, as solicitações sobre o burst serão atrasadas (leve mais tempo e espere até que elas possam ser atendidas), com as opções nodelay o atraso não é usado e solicitações em excesso são negadas com um erro 503. / p>

Esta postagem do blog ( archive.org ) dá uma boa explicação de como a limitação de taxa funciona nginx:

If you’re like me, you’re probably wondering what the heck burst really means. Here is the trick: replace the word ‘burst’ with ‘bucket’, and assume that every user is given a bucket with 5 tokens. Every time that they exceed the rate of 1 request per second, they have to pay a token. Once they’ve spent all of their tokens, they are given an HTTP 503 error message, which has essentially become the standard for ‘back off, man!’.

    

Answer 2

TL; DR: A opção nodelay é útil se você quiser impor um limite de taxa sem restringir o espaçamento permitido entre as solicitações.

Eu tive dificuldade de digerir as outras respostas e, em seguida, descobri a nova documentação do Nginx com exemplos que respondem a isso: link

Aqui está a parte pertinente. Dado:

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

location /login/ {
  limit_req zone=mylimit burst=20;
  ...
}

The burst parameter defines how many requests a client can make in excess of the rate specified by the zone (with our sample mylimit zone, the rate limit is 10 requests per second, or 1 every 100 milliseconds). A request that arrives sooner than 100 milliseconds after the previous one is put in a queue, and here we are setting the queue size to 20.

That means if 21 requests arrive from a given IP address simultaneously, NGINX forwards the first one to the upstream server group immediately and puts the remaining 20 in the queue. It then forwards a queued request every 100 milliseconds, and returns 503 to the client only if an incoming request makes the number of queued requests go over 20.

Se você adicionar o nodelay:

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

With the nodelay parameter, NGINX still allocates slots in the queue according to the burst parameter and imposes the configured rate limit, but not by spacing out the forwarding of queued requests. Instead, when a request arrives “too soon”, NGINX forwards it immediately as long as there is a slot available for it in the queue. It marks that slot as “taken” and does not free it for use by another request until the appropriate time has passed (in our example, after 100 milliseconds).

    

Answer 3

A maneira que eu vejo é a seguinte:

1. As solicitações serão exibidas o mais rápido possível até que a taxa da zona seja excedida. A taxa de zona é "em média", portanto, se a sua taxa for 1r/s e% de rajada10, você poderá ter 10 solicitações em uma janela de 10 segundos.

2. Após a taxa da zona ser excedida:

   a. Sem nodelay , pedidos adicionais até burst serão atrasados.

   b. Com nodelay , pedidos adicionais até burst serão exibidos o mais rápido possível.

3. Após o burst ser excedido, o servidor retornará uma resposta de erro até que a janela de burst expire. por exemplo. para a taxa 1r/s e% rajada10, o cliente precisará aguardar até 10 segundos para a próxima solicitação aceita.

Answer 4

A configuração define se as solicitações serão atrasadas para que estejam em conformidade com a taxa desejada ou se serão simplesmente rejeitadas ... um pouco, se a limitação de taxa for gerenciada pelo servidor ou a responsabilidade for passada para o cliente.

nodelay presente

As solicitações serão tratadas o mais rápido possível; quaisquer solicitações enviadas acima do limite especificado serão rejeitadas com o código definido como limit_req_status

nodelay ausente (também atrasado)

As solicitações serão tratadas em uma taxa que esteja em conformidade com o limite especificado. Assim, por exemplo, se uma taxa for definida como 10 req / s, cada solicitação será tratada em > = .1 (1 / rate) segundos, não permitindo, portanto, que a taxa seja excedida, mas permitindo que as solicitações sejam submetidas a backup. Se houver solicitações suficientes de backup para estourar o bucket (o que também seria impedido por um limite de conexão simultânea), elas serão rejeitadas com o código configurado como limit_req_status .

Os detalhes estão aqui: link onde essa lógica entra em ação quando o limite ainda não foi passado e agora o atraso é opcionalmente aplicado à solicitação. A aplicação de nodelay em particular da diretiva entra em jogo aqui: link fazendo com que o valor de delay acima seja 0 acionando esse manipulador para retornar imediatamente NGX_DECLINED que passa a solicitação para o próximo manipulador (em vez de NGX_AGAIN , que efetivamente enfileirará o processamento para ser processado novamente).