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

11

nginx HttpLimitReqモジュールを使用すると、IPによってリクエストを制限できます。ただし、「nodelay」オプションが何をするのか理解していません。

制限バースト遅延内の過剰な要求が不要な場合は、nodelayを使用する必要があります

limit_req   zone=one  burst=5  nodelay;
nginx  rate-limiting 
— Xeoncross
ソース

回答:

11

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

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

私が理解していることから、バーストをnodelay超えるリクエストは遅延します（より時間がかかり、処理できるようになるまで待機します）。オプションで遅延は使用されず、過剰なリクエストは503エラーで拒否されます。

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

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

— コアダンプ
ソース
4
あなたは間違っていると思います、nginxマニュアルには、「過剰なリクエストは、その数が最大バーストサイズを超えるまで遅延されます」とあります。最大バーストを超えるまでは、あなたが言ったバーストよりも完全に異なる意味であることに注意してください。あなたはまた、融合し、バーストと過剰要求、私は信じて過剰要求し、それはまだ下回るかもしれないが、それは、ゾーンの上だ手段を最大バースト。
— ヘンディイラワン14
10

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ミリ秒後）別のリクエストで使用できるように解放しません。

— マーク・ウーン
ソース
6

私が見る方法は次のとおりです。

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

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

    a。がなければnodelay、それまでのリクエストburstは遅れます。

    b。を使用するとnodelay、それまでのリクエストburstはできるだけ早く処理されます。

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

— ヘンディ・イラワン
ソース
3

この設定は、要求が目的のレートに準拠するように遅延するか、単に拒否するかを定義します...レート制限がサーバーによって管理されるか、責任がクライアントに渡されるかによって決まります。

nodelay プレゼント

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

nodelay 不在（別名遅延）

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

厄介な詳細はこちらです：https : //github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L263 ここで、制限がまだ渡されていないときに遅延が開始され、遅延が発生しますオプションでリクエストに適用されます。適用nodelayディレクティブから特にここで戦場に出る：https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L495 の値引き起こしdelay上記はそれを0トリガーされるようにハンドラーはすぐに戻りNGX_DECLINED、リクエストを次のハンドラーに渡します（実際にリクエストをNGX_AGAIN再キューイングして再処理するのではありません）。

— マット・ホイップル
ソース
1

はじめに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。

ここに画像の説明を入力してください

以下のようhttps://www.nginx.com/blog/rate-limiting-nginx/文書（私が強く最初の記事を読んでお勧めします（ただし、二段階のレート制限のセクションを））、この動作の修正問題の一つ。どれ？：

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

作成したドラフトを確認してください。40thリクエストはで応答し1s、もう一方40thはで応答し4sます。

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

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

サーバー上に多くのクライアントがキューイングしている場合A、client 、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.、コストは、クライアント側で、キューに入れられたリクエストが、後でリクエストされる可能性があり、サービスを受ける可能性があるということです。

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

  1. x r/s+ burst+ nodelay、すでに説明した。

PSこの記事の2段階のレート制限セクションは非常にわかりにくいです。わかりませんが、それは問題ではないようです。

例えば：

この構成を適切に設定すると、8 r / sで連続した要求のストリームを作成するクライアントで次の動作が発生します。

8 r / s？マジ？画像に示されている3秒以内に17のリクエストがあります。17/ 3 = 8？

— リック
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.