Nginx - Was macht die Nodelay-Option, wenn Anforderungen begrenzt werden?

Mit dem nginx HttpLimitReq- Modul können Anforderungen durch IP begrenzt werden. Ich verstehe jedoch nicht, was die Option "Nodelay" bewirkt.

Wenn die überschüssigen Anforderungen innerhalb der Limit-Burst-Verzögerung nicht erforderlich sind, sollten Sie das Nodelay verwenden

limit_req   zone=one  burst=5  nodelay;

Die Dokumentation hier enthält eine Erklärung, die sich nach dem anhört, was Sie wissen möchten:

Die Direktive gibt die Zone (Zone) und die maximal möglichen Bursts von Anforderungen (Burst) an. Wenn die Rate die in der Zone angegebenen Anforderungen überschreitet, wird die Anforderung verzögert, sodass Abfragen mit einer bestimmten Geschwindigkeit verarbeitet werden

Soweit ich weiß, werden Anforderungen über den Burst verzögert (nehmen Sie sich mehr Zeit und warten Sie, bis sie bedient werden können). Mit den nodelayOptionen wird die Verzögerung nicht verwendet und überschüssige Anforderungen werden mit einem 503-Fehler abgelehnt.

Dieser Blog-Beitrag ( archive.org ) gibt eine gute Erklärung, wie die Ratenbegrenzung auf Nginx funktioniert:

Wenn Sie wie ich sind, fragen Sie sich wahrscheinlich, was der Teufel wirklich bedeutet. Hier ist der Trick: Ersetzen Sie das Wort "Burst" durch "Bucket" und nehmen Sie an, dass jeder Benutzer einen Bucket mit 5 Token erhält. Jedes Mal, wenn sie die Rate von 1 Anfrage pro Sekunde überschreiten, müssen sie einen Token bezahlen. Sobald sie alle ihre Token ausgegeben haben, erhalten sie eine HTTP 503-Fehlermeldung, die im Wesentlichen zum Standard für "Zurück, Mann!" Geworden ist.

TL; DR: Die Nodelay-Option ist nützlich, wenn Sie ein Ratenlimit festlegen möchten, ohne den zulässigen Abstand zwischen Anforderungen einzuschränken.

Es fiel mir schwer, die anderen Antworten zu verdauen, und dann entdeckte ich eine neue Dokumentation von Nginx mit Beispielen, die dies beantworten: https://www.nginx.com/blog/rate-limiting-nginx/

Hier ist der relevante Teil. Gegeben:

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

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

Der Burst-Parameter definiert, wie viele Anforderungen ein Client über die von der Zone angegebene Rate hinaus stellen kann (bei unserer Beispiel-Mylimit-Zone beträgt das Ratenlimit 10 Anforderungen pro Sekunde oder 1 alle 100 Millisekunden). Eine Anforderung, die früher als 100 Millisekunden nach der vorherigen eingeht, wird in eine Warteschlange gestellt. Hier setzen wir die Warteschlangengröße auf 20.

Das heißt, wenn 21 Anforderungen gleichzeitig von einer bestimmten IP-Adresse eingehen, leitet NGINX die erste sofort an die Upstream-Servergruppe weiter und stellt die verbleibenden 20 in die Warteschlange. Anschließend wird alle 100 Millisekunden eine Anforderung in der Warteschlange weitergeleitet, und 503 wird nur dann an den Client zurückgegeben, wenn bei einer eingehenden Anforderung die Anzahl der Anforderungen in der Warteschlange über 20 liegt.

Wenn Sie nodelay hinzufügen:

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

Mit dem Nodelay-Parameter weist NGINX weiterhin Slots in der Warteschlange gemäß dem Burst-Parameter zu und legt das konfigurierte Ratenlimit fest, jedoch nicht durch Abstand zwischen der Weiterleitung von Anforderungen in der Warteschlange. Wenn eine Anfrage "zu früh" eintrifft, leitet NGINX sie sofort weiter, solange in der Warteschlange ein Steckplatz dafür verfügbar ist. Dieser Slot wird als "belegt" markiert und erst nach Ablauf der entsprechenden Zeit (in unserem Beispiel nach 100 Millisekunden) für die Verwendung durch eine andere Anforderung freigegeben.

Ich sehe es so:

1. Anfragen werden so schnell wie möglich bearbeitet, bis die Zonenrate überschritten wird. Die Zonenrate ist "im Durchschnitt". Wenn Ihre Rate also " 1r/sBurst" ist 10, können Sie 10 Anfragen in einem 10-Sekunden-Fenster haben.

2. Nachdem die Zonenrate überschritten wurde:

   ein. Ohne nodelaywerden weitere Anfragen bis burstverzögert.

   b. Mit nodelaywerden weitere Anfragen bis zu burstso schnell wie möglich bearbeitet.

3. Nachdem der burstWert überschritten wurde, gibt der Server eine Fehlerantwort zurück, bis das Burst-Fenster abläuft. Beispielsweise muss der Client für Rate 1r/sund Burst 10bis zu 10 Sekunden auf die nächste akzeptierte Anfrage warten.

Die Einstellung definiert, ob Anforderungen verzögert werden, damit sie der gewünschten Rate entsprechen, oder ob sie einfach abgelehnt werden ... etwas, ob die Ratenbegrenzung vom Server verwaltet wird oder die Verantwortung an den Client übergeben wird.

nodelay Geschenk

Anfragen werden so schnell wie möglich bearbeitet. Anfragen, die über das angegebene Limit gesendet werden, werden mit dem Code as abgelehntlimit_req_status

nodelay abwesend (auch bekannt als verzögert)

Anfragen werden mit einer Rate bearbeitet, die dem angegebenen Limit entspricht. Wenn beispielsweise eine Rate von 10 Req / s festgelegt ist, wird jede Anforderung in> = 0,1 (1 / Rate) Sekunden verarbeitet, wodurch nicht zugelassen wird, dass die Rate überschritten wird, sondern dass die Anforderungen gesichert werden. Wenn genügend Anforderungen gesichert werden, um den Bucket zu überlaufen (was auch durch ein gleichzeitiges Verbindungslimit verhindert würde), werden sie mit dem Code as abgelehnt limit_req_status.

Die wichtigsten Details finden Sie hier: https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L263, wo diese Logik einsetzt, wenn das Limit noch nicht überschritten wurde, und jetzt die Verzögerung wird optional auf die Anfrage angewendet. Die Anwendung nodelayinsbesondere der Richtlinie kommt hier ins Spiel: https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L495, wodurch der Wert von delayoben 0 ausgelöst wird Der Handler muss sofort zurückkehren, NGX_DECLINEDwodurch die Anforderung an den nächsten Handler weitergeleitet wird (und nicht NGX_AGAIN, dass sie erneut verarbeitet werden muss).

Das habe ich beim ersten Lesen der Einführung von https://www.nginx.com/blog/rate-limiting-nginx/ nicht verstanden .

Jetzt bin ich sicher, dass ich es verstehe und meine Antwort ist bisher die beste. :) :)

Nehmen wir an : 10r/sgesetzt, die maximale Leistungsfähigkeit des Servers ist zB 10000r/sdas ist , 10r/msund es gibt nur 1 Client im Moment.

Hier ist der Hauptunterschied zwischen 10r/s per IP burst=40 nodelayund 10r/s per IP burst=40.

Wie unter https://www.nginx.com/blog/rate-limiting-nginx/ dokumentiert ( ich empfehle dringend, zuerst den Artikel zu lesen (mit Ausnahme des Abschnitts zur zweistufigen Ratenbegrenzung )), behebt dieses Verhalten ein Problem. Welcher?:

In unserem Beispiel wartet das 20. Paket in der Warteschlange 2 Sekunden auf die Weiterleitung. Zu diesem Zeitpunkt ist eine Antwort darauf für den Client möglicherweise nicht mehr nützlich.

Überprüfen Sie den Entwurf, den ich gemacht habe. Die 40thAnfrage erhält eine Antwort um, 1swährend die andere um 40theine Antwort erhält 4s.

Dies kann die Serverfunktionen optimal nutzen: Antworten werden so schnell wie möglich zurückgesendet, wobei die x r/sBeschränkung auf einen bestimmten Client / eine bestimmte IP beibehalten wird.

Aber hier gibt es auch Kosten. Die Kosten betragen:

Wenn Sie viele Clients auf dem Server sagen wir mal Client Warteschlangen A, Bund C.

Ohne nodelaywerden die Anfragen in einer ähnlichen Reihenfolge wie zugestellt ABCABCABC.
Mit nodelayist die Reihenfolge eher AAABBBCCC.

Ich möchte den Artikel https://www.nginx.com/blog/rate-limiting-nginx/ hier zusammenfassen.

Die wichtigste Konfiguration ist vor allem x r/s.

1. x r/s Nur überschüssige Anfragen werden sofort abgelehnt.

2. x r/s+ burst, überschüssige Anfragen werden in die Warteschlange gestellt.

1.vs 2., die Kosten sind, dass auf der Client-Seite die in der Warteschlange befindlichen Anfragen die Chancen späterer Anfragen in Anspruch nehmen, die die Chance hatten, bedient zu werden.

Zum Beispiel 10r/s burst=20gegen 10r/sdas 11thwird Antrag soll unmittelbar nach der letztgenannten Bedingung abgelehnt werden, aber jetzt ist es eine Warteschlange gestellt und serviert. Die 11thAnfrage nimmt die 21thChance der Anfrage ein.

3. x r/s+ burst+ nodelay, Bereits erklärt.

PS Der Abschnitt zur zweistufigen Ratenbegrenzung des Artikels ist sehr verwirrend. Ich verstehe nicht, aber das scheint keine Rolle zu spielen.

Beispielsweise:

Mit dieser Konfiguration tritt bei einem Client, der einen kontinuierlichen Anforderungsstrom mit 8 U / s erstellt, das folgende Verhalten auf.

8 U / s? Ernsthaft? Es werden 17 Anfragen innerhalb von 3 Sekunden im Bild angezeigt, 17/3 = 8?