Nginx - який сенс визначити `лопнутий ', якщо є опція` nodelay`

У конфігурації Nginx, коли ви хочете обмежити швидкість обробки запиту за допомогою limit_req_zone/ limit_req instructions, я не розумію використання nodelayпараметра.
Наскільки я розумію, він припиняє запити вище визначеної ставки, не відкладаючи їх. Тож це здається рівнозначним burst=0. Ось чому я не розумію наступного прикладу:

limit_req zone=one burst=5 nodelay;

burstвизначає кількість запитів, які можуть бути відкладені, тож який сенс визначити, burstякщо є nodelayваріант?

Я вважаю, що limit_reqдокументація досить чітка.

burst задокументовано таким чином:

Надмірна кількість запитів затримується до тих пір, поки їх кількість не перевищить максимальний розмір […]

nodelay задокументовано таким чином:

Якщо затримка надмірних запитів при обмеженні запитів не бажана, слід використовувати параметр nodelay

Заявки обмежені відповідно до визначеної ставки. Якщо запити надходять із більш високою швидкістю, подається не більше визначеної кількості запитів на одиницю часу . Потім потрібно вирішити, що робити з цими іншими запитами.

• За замовчуванням (ні burst, ні nodelay) запити відхиляються з помилкою HTTP 503.
• З burst, ви стек певну кількість запитів в черзі очікування, але не обробляти їх швидше , ніж певних запитів в одиницю часу швидкості .
• З, burstі nodelayчерга не буде чекати, і вибухові запити будуть оброблені негайно .

Коментарі до оригінальної відповіді здаються неправильними.

Справа в тому, яка різниця між, скажімо, швидкістю = 6р / с розривом = 0 і швидкістю = 1р / с розривом = 5 вузлів

Відповіді чудово пояснюють різницю, коли параметр nodelay НЕ присутній - у такому випадку запити стоять у черзі з пакетом, і вони є 503'd без пакетного.

Оригінальна відповідь здається точковою - із вузлом затримки обробляються запити негайно. І, отже, єдиним наслідком цього є те, що немає різниці між вказівкою прорив + вузол порівняно з просто зазначенням вищої межі з busrt = 0 в першу чергу.

Отже, щоб більш коротко відповісти на питання ОП: значення лопнув, коли задається nodelay, те саме, що просто вказати більшу швидкість без розриву.

За допомогою burstта nodelayуточнення мені легше зрозуміти такий механізм (навпаки, ніж це зазвичай розуміється):

1. Ви дозволяєте максимум burstзапитів. Оскільки $binary_remote_addrце максимальна кількість запитів, які ви приймаєте з певної адреси. Кожен запит збільшує внутрішній лічильник. При досягненні лічильника burstвсі додаткові запити відхиляються (а лічильник не збільшується понад burstзначення).
2. Цей лічильник постійно зменшується зі швидкістю, визначеною за допомогою rate.

Ця логіка дозволяє припустити, що є доцільним зазначити високе burstзначення (наприклад, 100 і більше) і низьке rateзначення (навіть щось на зразок 2р / с). Це обробляє звичайний перегляд (партія паралельних запитів, що супроводжується тихим періодом) краще, захищаючи від постійного потоку запитів бота.

Я запитав питання Ніколя до хлопця, який написав нижче повідомлення на веб-сайті nginx. Обмеження швидкості NGINX. Його відповідь наведено нижче

У колишньому обмеженні швидкості nginx буде приймати послідовні запити з інтервалом на 1/6 секунди. він не прийме пакет запитів, які не задовольняють цей мінімальний часовий інтервал. З іншого боку, в останньому визначенні nginx прийме пакет до 6 запитів незалежно від часового інтервалу між запитами. Посилання для відповідей

На основі чудової відповіді Дана та вихідного коду nginx , стислий підсумок nodelayповедінки виглядає наступним чином:

• burst- скільки нових одночасних запитів дозволено.
• rate- скільки нових одночасних запитів старіють за одиницю часу. (Це оновлення відбувається поступово: один раз за запит, але не за секунду.)

Я пропоную прочитати цю тему: limit_req_zone limit за місцем розташування / проксі

і ця відповідь: stackoverflow