Nginx – 如果有`nodelay`选项，定义`burst'的含义是什么

我发现足够清楚的limit_req文档。

burstlogging是这样的：

过多的请求被延迟，直到它们的数量超过最大突发大小[…]

nodelay这种方式loggingnodelay ：

如果在请求被限制时延迟了过多的请求，则不需要使用参数nodelay

请求被限制为符合规定的速率。 如果请求以更高的速率传入，则每个时间单元的请求数量不会超过规定的数量。 然后，您需要决定如何处理这些其他请求。

• 默认情况下（没有burst ，没有nodelay ），请求被拒绝HTTP 503错误。
• 在burst ，您可以将已定义的请求数量堆叠到等待队列中， 但不会按照每个时间单位速率定义的请求速度处理它们 。
• 使用burst和nodelay ，队列不会等待，并且请求突发将立即得到处理 。

对原始答案的评论似乎是错误的。

现在的问题是比率= 6r / s突发= 0和速率= 1r / s突发= 5节点之间的差异

当nodelay选项不存在时，答案是很好的解释差异 – 在这种情况下，请求排队与突发，并没有突发503'd。

原来的答案似乎现场 – 与节点，突发请求得到立即处理。 因此，唯一的含义就是指定一个突发+ nodelay与指定busrt = 0的上限是没有区别的。

因此，要更简洁地回答OP问题：指定nodelay时的突发含义与只指定较大的速率而没有突发相同。

通过指定burst和nodelay我发现更容易理解这样的机制（比通常理解的另一种方式）：

1. 您允许最大的burst请求。 使用$binary_remote_addr ，这是您从给定地址接受的最大请求数。 每个请求增加一个内部计数器。 当计数器达到burst所有附加请求都被拒绝（计数器不会超出burst值）。
2. 这个计数器以指定的rate不断减less。

这个逻辑表明，指定高burst值（例如100以上）和低rate值（甚至类似2r / s）是非常有意义的。 这样可以更好地处理正常浏览（一批并行请求，然后是安静期），同时保护持续的僵尸程序请求stream。

我build议阅读这个线程： limit_req_zone限制的位置/代理

和这个答案： stackoverflow