web-dev-qa-db-ja.com

Nginx-リクエストを制限する場合、nodelayオプションは何をしますか？

Nginx HttpLimitReq を使用すると、モジュールリクエストをIPで制限できます。ただし、「nodelay」オプションの機能がわかりません。

限界バースト遅延内の過剰なリクエストが必要ない場合は、nodelayを使用する必要があります

limit_req   zone=one  burst=5  nodelay;
nginxrate-limiting
11
Xeoncross

ドキュメント here には、あなたが知りたいように聞こえる説明があります：

ディレクティブは、ゾーン（zone）と要求の可能な最大バースト（burst）を指定します。レートがゾーンで概説されている要求を超えると、要求が遅延するため、クエリは所定の速度で処理されます

私が理解していることから、バースト上のリクエストは遅延されます（より多くの時間がかかり、サービスが提供されるまで待機します）。nodelayオプションを使用すると、遅延は使用されず、過剰なリクエストは503エラーで拒否されます。

このブログ投稿 （ archive.org ）は、nginxでレート制限がどのように機能するかを説明しています。

あなたが私のような人なら、一体破裂が本当に何を意味するのか疑問に思うでしょう。トリックは次のとおりです。単語「バースト」を「バケット」に置き換え、すべてのユーザーに5つのトークンのバケットが与えられると想定します。 1秒あたりのリクエスト数が1を超えるたびに、トークンを支払う必要があります。すべてのトークンを使い果たすと、HTTP 503エラーメッセージが表示されます。これは、本質的に「バックオフ、マン！」の標準になっています。

11
coredump

TL; DR：nodelayオプションは、リクエスト間の許容される間隔を制限せずにレート制限を課したい場合に役立ちます。

私は他の答えを消化するのに苦労しました、そしてそれからこれに答える例を含むNginxからの新しいドキュメントを発見しました： https://www.nginx.com/blog/rate-limited-nginx/

ここに関連する部分があります。与えられた：

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

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

バーストパラメータは、ゾーンで指定されたレートを超えてクライアントが作成できるリクエストの数を定義します（サンプルのmylimitゾーンでは、レート制限は1秒あたり10リクエスト、つまり100ミリ秒ごとに1リクエストです）。前のリクエストがキューに入れられてから100ミリ秒より早く到着するリクエスト。ここでは、キューサイズを20に設定しています。

つまり、21個のリクエストが特定のIPアドレスから同時に到着した場合、NGINXは最初のリクエストをすぐに上流のサーバーグループに転送し、残りの20個をキューに入れます。次に、キューに入れられた要求を100ミリ秒ごとに転送し、着信要求によってキューに入れられた要求の数が20を超えた場合にのみ、503をクライアントに返します。

Nodelayを追加する場合：

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

Nodelayパラメータを使用すると、NGINXは引き続きバーストパラメータに従ってキュー内のスロットを割り当て、構成されたレート制限を課しますが、キューに入れられた要求の転送の間隔を空けることはしません。代わりに、リクエストが「遅すぎて」到着した場合、キューに使用可能なスロットがある限り、NGINXはすぐに転送します。これは、そのスロットを「取得済み」としてマークし、適切な時間が経過するまで（この例では100ミリ秒後）、そのスロットを別の要求が使用できるように解放しません。

10
Mark Woon

私がそれを見る方法は次のとおりです：

  1. ゾーンレートを超えるまで、リクエストは可能な限り迅速に処理されます。ゾーンのレートは「平均的」であるため、レートが1r/sおよびバースト10 10秒のウィンドウで10件のリクエストを処理できます。

  2. ゾーンレートを超えた後：

    a。 nodelayがない場合、burstまでの以降のリクエストは遅延します。

    b。 nodelayを使用すると、burstまでのリクエストが可能な限り速く処理されます。

  3. burstを超えた後、バーストウィンドウが期限切れになるまで、サーバーはエラー応答を返します。例えばレート1r/sおよびバースト10、クライアントは次の受け入れられたリクエストを最大10秒待つ必要があります。

6
Hendy Irawan

設定は、要求が遅延して希望のレートに準拠するか、単に拒否されるかを定義します。レート制限がサーバーによって管理されるのか、クライアントに責任が渡されるのかは多少異なります。

nodelayプレゼント

リクエストは可能な限り迅速に処理されます。指定された制限を超えて送信されたリクエストは、コードをlimit_req_statusに設定して拒否されます

nodelay欠落（別名遅延）

リクエストは、指定された制限に準拠したレートで処理されます。したがって、たとえばレートが10リクエスト/秒に設定されている場合、各リクエストは> = .1（1/rate）秒で処理されるため、レートを超えることはできませんが、リクエストをバックアップできます。バケットをオーバーフローさせるのに十分な数のリクエストがバックアップされると（同時接続制限によっても防止されます）、コードはlimit_req_statusとして設定されて拒否されます。

悲惨な詳細はここにあります： https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L26 ここで、制限がない場合にロジックが開始されますまだ渡されており、遅延はオプションでリクエストに適用されます。特にディレクティブからのnodelayのアプリケーションがここに作用します： https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L495 上記のdelayの値を0にすると、そのハンドラーはNGX_DECLINEDをすぐに返し、リクエストを次のハンドラーに渡します（NGX_AGAINではなく、リクエストを効果的に再キューイングします）再度処理されます）。

3
Matt Whipple

https://www.nginx.com/blog/rate-limited-nginx/ から紹介を読んでいたとき、最初はそれがわかりませんでした。

今、私は理解しており、私の答えはこれまでのところ最高です。 :)

仮定：10r/sが設定されている場合、サーバーの最大機能は次のようになります。 10000r/sは10r/msで、現時点でクライアントは1つだけです。

10r/s per IP burst=40 nodelayと10r/s per IP burst=40の主な違いは次のとおりです。

enter image description here

https://www.nginx.com/blog/rate-limited-nginx/ 記載されているように（最初に記事を読むことを強くお勧めします（Two-Stage Rate Limitingセクションを除く））、この動作は1つの問題を修正します。どれ？：

この例では、キュー内の20番目のパケットが転送されるまで2秒待機します。この時点で、そのパケットへの応答はクライアントにとってもはや役に立たない可能性があります。

私が作成したドラフトを確認します。40thリクエストは1sで応答を取得し、他の40thは4sで応答を取得します。

これにより、サーバーの機能を最大限に活用できます。つまり、特定のクライアント/ IPにx r/s制約を維持しながら、可能な限り迅速に応答を送り返します。

しかし、ここにも費用がかかります。費用は次のとおりです。

サーバー上にキューイングしているクライアントが多い場合は、クライアントA、B、Cとしましょう。

nodelayがない場合、リクエストはABCABCABCと同様の順序で処理されます。
nodelayを使用すると、注文はAAABBBCCCになる可能性が高くなります。

記事をまとめたいと思います https://www.nginx.com/blog/rate-limited-nginx/ こちら。

とりわけ、最も重要な構成はx r/sです。

  1. x r/sのみ、超過したリクエストはすぐに拒否されます。

  2. x r/s + burst、超過したリクエストはキューに入れられます。

1.対2.、コストは、クライアント側では、キューに入れられたリクエストが、サービスを受ける可能性があった後のreuqestの可能性をとることです。

たとえば、10r/s burst=20と10r/sの場合、11thリクエストは、後者の状況ではすぐに拒否されるはずですが、現在はキューに入れられて処理されます。 11thリクエストは、21thリクエストのチャンスを利用します。

  1. x r/s + burst + nodelay、説明済み。

追伸記事のTwo-Stage Rate Limitingセクションは非常に混乱しています。わかりませんが、問題ではないようです。

例えば：

この構成を使用すると、8 r/sでリクエストの連続ストリームを作成するクライアントは、次の動作を経験します。

8 r/s？真剣に？画像に示すように、3秒以内に17件のリクエストがあります。17/ 3 = 8？

1
Rick