インターネットドラフト HTTP の RateLimit ヘッダーフィールド 2026年5月
Polli, et al. 2026年11月24日に期限切れ [ページ]
作業部会:
HTTPAPI
インターネットドラフト:
draft-ietf-httpapi-ratelimit-headers-11
公開日:
予定ステータス:
標準化過程
期限切れ:
著者:
R. Polli
Team Digitale、イタリア政府
A. Martinez
Red Hat
D. Miller
Microsoft

HTTP の RateLimit ヘッダーフィールド

概要

この文書は、サーバーがクォータポリシーと現在のサービス制限を通知し、それによってクライアントがスロットリングされることを回避できるようにするための RateLimit-Policy および RateLimit HTTP ヘッダーフィールドを定義します。

この文書について

この注記は、RFC として公開される前に削除される予定です。

この文書のステータス情報は https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/ で確認できます。

この文書に関する議論は HTTPAPI Working Group メーリングリスト(mailto:httpapi@ietf.org)で行われ、 そのアーカイブは https://mailarchive.ietf.org/arch/browse/httpapi/ にあります。 購読は https://www.ietf.org/mailman/listinfo/httpapi/ で行えます。 作業部会の情報は https://datatracker.ietf.org/wg/httpapi/about/ にあります。

このドラフトのソースと issue tracker は https://github.com/ietf-wg-httpapi/ratelimit-headers にあります。

このメモの位置づけ

このインターネットドラフトは、BCP 78 および BCP 79 の規定に完全に準拠して提出されています。

インターネットドラフトは、Internet Engineering Task Force(IETF)の作業文書です。他のグループも作業文書をインターネットドラフトとして配布する場合があることに注意してください。 現在のインターネットドラフトの一覧は https://datatracker.ietf.org/drafts/current/ にあります。

インターネットドラフトは、最長6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 インターネットドラフトを参考資料として使用したり、「作業中」以外のものとして引用したりすることは不適切です。

このインターネットドラフトは2026年11月24日に期限切れになります。

目次

1. はじめに

HTTP クライアントのレート制限は、特に HTTP API において広く行われるようになっています。通常、サーバーはそのような場合、所定の時間ウィンドウ内で受け入れ可能なリクエスト数(例: 1 秒あたり 10 リクエスト)を制限します。HTTP におけるレート制限の現在の使用状況に関する詳細は、付録 Aを参照してください。

現在、クライアントがエラーを防ぐために自身のリクエストをスロットリングできるよう、サーバーがクォータを伝達する標準的な方法はありません。この文書は、レート制限を可能にするため、次の標準 HTTP ヘッダー フィールド群を定義します。

これらのフィールドにより、複数かつ可変の時間ウィンドウや動的クォータの使用、並行数制限の実装を含む、複雑なレート制限ポリシーを確立できます。

1.1. 目標

この文書の目標は次のとおりです。

相互運用性:

レート制限ヘッダーの名前とセマンティクスを標準化し、その適用と採用を容易にすること。

回復性:

クライアントがリクエストをスロットリングし、4xx または 5xx レスポンスを防ぐために有用な情報を提供することで、HTTP インフラストラクチャの回復性を高めること。

文書化:

API 文書に詳細なクォータ制限や関連フィールドを含める必要をなくすことで、API 文書を簡素化すること。

次の機能は、この文書の範囲外です。

認可:

RateLimit ヘッダーフィールドは、認可やその他の種類のアクセス制御をサポートすることを意図したものではありません。

レスポンスステータスコード:

RateLimit ヘッダーフィールドは、成功レスポンス([HTTP] の Section 15.3 を参照)と非成功レスポンスの両方で返される場合があります。この仕様は、非成功レスポンスがクォータ使用量に数えられるかどうかを扱わず、RateLimit 値と返されるステータスコードとの相関を義務付けるものでもありません。

スロットリングアルゴリズム:

この仕様は、特定のスロットリングアルゴリズムを義務付けません。ウィンドウサイズを含め、フィールドで公開される値は、静的または動的に評価できます。

サービスレベル合意:

伝達されたクォータのヒントは、いかなるサービス保証も意味しません。サーバーは、特定の状況下で、サーバーが推奨する制限を順守しているクライアントを自由にスロットリングできます。

1.2. 表記上の規約

この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されます。

Origin という用語は、[WEB-ORIGIN] の Section 7 に記述されているとおりに解釈されます。

この文書では、構文および解析を指定するために、[SF] の Section 3 の List、Item、および Integer という用語を、「bare item」の概念とともに使用します。

この文書における "problem type" という用語は、 [PROBLEM] に記述されているとおりに解釈されます。

2. 用語

クォータ:

クォータとは、リソースサーバーがクライアントリクエストを制限するために使用する容量の割り当てです。その容量は、クライアントが時間ウィンドウ内で消費できるクォータ単位で測定されます。

クォータ単位:

クォータ単位とは、クライアントの活動を測定するために使用される測定単位です。

クォータパーティション:

クォータパーティションとは、異なるクライアント、ユーザー、および所有リソースにわたるサーバー容量の分割です。

時間ウィンドウ:

時間ウィンドウは、割り当てられたクォータに関連付けられた期間を示します。

クォータポリシー:

クォータポリシーは、定義された時間ウィンドウにわたり、指定されたクォータパーティション内の活動を、クォータ単位で定量化して規制するためにサーバーによって実装されます。この活動は、クォータとして知られる事前定義済みの制限に制約されます。クォータポリシーはサーバーによって通知できますが、通知は必須ではなく、クライアントからサーバーへの特定のリクエストに対して複数のクォータポリシーが影響を及ぼす場合があります。

サービス制限:

サービス制限とは、特定のクォータポリシーの下で現在利用可能なクォータであり、定義されている場合には、クライアントが利用可能なクォータを超えて使用できない有効時間ウィンドウです。

List:

Item の [SF] list

Item:

関連付けられたパラメーターの集合を持つ [SF] item

3. RateLimit-Policy フィールド

"RateLimit-Policy" レスポンスヘッダーフィールドは、クォータポリシー項目(Section 3.1)の空でない List[SF] です。Item[SF] 値は String[SF] でなければなりません(MUST)。

フィールド値は、一連の HTTP レスポンスにわたって一貫しているべきです(SHOULD)。この特性により、リクエストごとに変化する可能性がある情報を含む RateLimitSection 4 フィールドと区別されます。"RateLimit-Policy" フィールドにより、クライアントはサーバーが提供するポリシー情報に基づいて、自身のリクエストの流れを制御できます。スロットリング制約が非常に動的な状況では、クライアントが反応できる最新のサービス情報を伝達する RateLimit フィールドSection 4 を使用する方が適しています。両方のフィールドは、適切な場合にサーバーによって伝達できます。

クォータポリシー項目(Section 3.1)のリストは、[SF] の Section 3.1 に記述されているように、同じ HTTP レスポンス内の複数の "RateLimit-Policy" フィールドに分割できます。

   RateLimit-Policy: "burst";q=100;w=60,"daily";q=1000;w=86400

3.1. クォータポリシー項目

クォータポリシー Item は、ポリシーの識別子と、そのポリシーに対するサーバーの容量割り当てに関する情報を含む Parameters[SF] の集合を含みます。

次のパラメーターが定義されています。

q:

必須(REQUIRED)の "q" パラメーターは、このポリシーによって割り当てられたクォータを、クォータ単位で測定して示します。

qu:

任意(OPTIONAL)の "qu" パラメーター値は、"q" パラメーターに関連付けられたクォータ単位を伝達します。既定のクォータ単位は "requests" です。

w:

任意(OPTIONAL)の "w" パラメーター値は、時間ウィンドウを伝達します。

pk:

任意(OPTIONAL)の "pk" パラメーター値は、対応するリクエストに関連付けられたパーティションキーを伝達します。

その他のパラメーターは許可され、コメントとみなすことができます。

実装固有またはサービス固有のパラメーターは、ベンダー識別子を持つ接頭辞付きパラメーターにするべきです(SHOULD)。例: acme-policy, acme-burst

このフィールドは trailer section に現れてはなりません(MUST NOT)。

3.1.1. クォータパラメーター

"q" パラメーター値は、非負の Integer でなければなりません(MUST)。この値は、特定のクォータパーティションについて、クライアント活動に割り当てられたクォータ(クォータ単位で測定)を示します。

3.1.2. クォータ単位 パラメーター

"qu" パラメーター値は、クォータ(Section 3.1.1)に適用されるクォータ単位を伝達します。 この値は String でなければなりません(MUST)。許可される値は、RateLimit Quota Units レジストリSection 10.3に列挙されています。この仕様では、次の 3 つのクォータ単位を定義します。

requests:

この値は、クォータがリソースサーバーによって処理されたリクエスト数に基づくことを示します。特定のリクエストが実際にクォータ単位を消費するかどうかは、実装固有です。

content-bytes:

この値は、クォータがリソースサーバーによって処理された content bytes の数に基づくことを示します。

concurrent-requests:

この値は、クォータがリソースサーバーによって処理された同時リクエスト数に基づくことを示します。

3.1.3. ウィンドウパラメーター

"w" パラメーター値は、クォータ(Section 3.1.1)に適用される時間ウィンドウを伝達します。 時間ウィンドウは、[HTTP] の Section 10.2.3 で定義されている "delay-seconds" 規則と同様に、秒単位の間隔を表す非負かつ非ゼロの Integer 値でなければなりません(MUST)。サブ秒精度はサポートされません。

3.1.4. パーティションキー パラメーター

"pk" パラメーター値は、リクエストに関連付けられたパーティションキーを伝達します。この値は Byte Sequence でなければなりません(MUST)。サーバーは、サーバー容量を異なるクライアントとリソースに分割するためにパーティションキーを使用してもよいです(MAY)。クォータはパーティションキーごとに割り当てられます。

3.2. RateLimit Policy フィールドの例

このフィールドは、次の例に示すように、クォータに関連付けられた時間ウィンドウを伝達してもよいです(MAY)。

   RateLimit-Policy: "default";q=100;w=10

次の例は、複数のポリシーが返されることを示します。

   RateLimit-Policy: "permin";q=50;w=60,"perhr";q=1000;w=3600

次の例は、パーティションキーを持つポリシーを示します。

   RateLimit-Policy: "peruser";q=100;w=60;pk=:cHsdsRa894==:

次の例は、パーティションキーとクォータ単位を持つポリシーを示します。

   RateLimit-Policy: "peruser";q=65535;qu="content-bytes";w=10;pk=:sdfjLJUOUH==:

4. RateLimit フィールド

サーバーは "RateLimit" レスポンスヘッダーフィールドを使用して、特定のパーティションキーについて、クォータポリシーの現在のサービス制限を伝達します。

このフィールドは、サービス制限項目(Section 4.1)の List[SF] として表されます。

サービス制限項目のリストは、[SF] の Section 3.1 に記述されているように、同じ HTTP レスポンス内の複数の "RateLimit" フィールドに分割できます。

   RateLimit: "default";r=50;t=30

4.1. サービス制限項目

各サービス制限 Item[SF] は、リクエストに関連付けられたクォータポリシー(Section 3.1)を識別し、現在のサービス制限に関する情報を持つ Parameters[SF] を含みます。

この仕様では、次のパラメーターが定義されています。

r:

この必須(REQUIRED)パラメーター値は、識別されたポリシーの下で利用可能なクォータを伝達します(Section 4.1.1)。

t:

この任意(OPTIONAL)パラメーター値は、識別されたポリシーの下での有効ウィンドウ、すなわちクライアントが利用可能なクォータを超えて使用できない時間を伝達します(Section 4.1.2)。

pk:

任意(OPTIONAL)の "pk" パラメーター値は、対応するリクエストに関連付けられたパーティションキーを伝達します。

このフィールドは trailer section に現れてはなりません(MUST NOT)。その他のパラメーターは許可され、コメントとみなすことができます。

実装固有またはサービス固有のパラメーターは、ベンダー識別子を持つ接頭辞付きパラメーターにするべきです(SHOULD)。例: acme-policy, acme-burst

4.1.1. 利用可能クォータ パラメーター

"r" パラメーターは、識別されたポリシーの下で利用可能なクォータを示します。

これは、クォータ単位で表される非負の Integer です。 クライアントは、正の利用可能クォータが、以後のリクエストが処理される保証であると想定してはなりません(MUST NOT)。 利用可能クォータが低い場合、それはサーバーがまもなくクライアントをスロットリングする可能性があることを示します(Section 6 を参照)。

4.1.2. 有効 ウィンドウパラメーター

"t" パラメーターは、識別されたポリシーの下での有効ウィンドウ、すなわちクライアントが利用可能なクォータを超えて使用できない秒数を示します。

これは delay-seconds 規則と互換性のある非負の Integer です。その理由は次のとおりです。

  • クロック同期に依存せず、クライアントとサーバー間のクロック調整およびクロックスキューに対して回復性があるため([HTTP] の Section 5.6.7 を参照)。

  • 同じタイムスタンプで処理されるクライアントが多すぎる場合に発生する thundering herd に関連するリスクを軽減するため。

クライアントは、有効ウィンドウパラメーターで示された時間の後に自身のサービス制限が完全に回復すると想定してはなりません(MUST NOT)。サーバーは、たとえばリソース飽和の場合やスライディングウィンドウポリシーを実装するために、後続のリクエスト間で利用可能クォータと有効ウィンドウを任意に変更してもよいです(MAY)。

4.1.3. パーティションキー パラメーター

"pk" パラメーター値は、リクエストに関連付けられたパーティションキーを伝達します。この値は Byte Sequence でなければなりません(MUST)。サーバーは、サーバー容量を異なるクライアントとリソースに分割するためにパーティションキーを使用してもよいです(MAY)。クォータはパーティションキーごとに割り当てられます。

4.2. RateLimit フィールドの例

この例は、利用可能クォータが 50 単位で、有効ウィンドウが 30 秒である RateLimit フィールドを示します。

   RateLimit: "default";r=50;t=30

この例は、時間ウィンドウを持たないパーティションキーについて、利用可能クォータが 999 リクエストであることを示します。

   RateLimit: "default";r=999;pk=:dHJpYWwxMjEzMjM=:

この例は、次の 60 秒間にアプリケーションで利用可能な 300MB のクォータを示します。

   RateLimit: "default";r=300000000;t=60;pk=:QXBwLTk5OQ==:

5. 問題タイプ

5.1. クォータ超過

この節は、 "https://iana.org/assignments/http-problem-types#quota-exceeded" 問題タイプを定義します。サーバーは、クライアントが送信したリクエストが 1 つ以上のクォータポリシーを超過していることをクライアントに伝達したい場合、この問題タイプを使用してもよいです(MAY)。この問題タイプは、拡張メンバー "violated-policies" を文字列の配列として定義し、その値はクォータが超過したポリシーの名前です。

HTTP/1.1 429 Bad Request
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#quota-exceeded",
  "title": "Request cannot be satisfied as assigned quota has been exceeded",
  "violated-policies": ["daily","bandwidth"]
}

5.2. 一時的な容量低下

この節は、 "https://iana.org/assignments/http-problem-types#temporary-reduced-capacity" 問題タイプを定義します。サーバーは、サーバー容量の一時的な低下により、クライアントのリクエストを現在満たせないことを伝達したい場合、この問題タイプを使用してもよいです(MAY)。サーバーは、新しい一時的に低いクォータを示す RateLimit-Policy フィールドを含めることを選択してもよいです(MAY)。この問題タイプは、拡張メンバー "violated-policies" を文字列の配列として定義し、その値はクォータが超過したポリシーの名前です。

HTTP/1.1 503 Server Unavailable
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#temporary-reduced-capacity",
  "title": "Request cannot be satisfied due to temporary server capacity constraints",
  "violated-policies": ["hourly"]
}

5.3. 異常な使用の検出

この節は、 "https://iana.org/assignments/http-problem-types#abnormal-usage-detected" 問題タイプを定義します。サーバーは、クライアント側の意図しない動作または悪意ある動作を示唆するリクエストパターンを検出したことをクライアントに伝達するために、この問題タイプを使用してもよいです(MAY)。この問題タイプは、拡張メンバー "violated-policies" を文字列の配列として定義し、その値はクォータが超過したポリシーの名前です。

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json

{
  "type": "https://iana.org/assignments/http-problem-types#abnormal-usage-detected",
  "title": "Request not satisifed due to detection of abnormal request pattern",
  "violated-policies": ["hourly"]
}

6. サーバーの動作

サーバーは、レスポンスステータスコードとは独立して RateLimit ヘッダーフィールドを返してもよいです(MAY)。 これには、スロットリングされたレスポンスも含まれます。この文書は、RateLimit ヘッダーフィールド値と返されるステータスコードとの間にいかなる相関も義務付けません。

サーバーは、リダイレクトレスポンス(すなわち 3xx ステータスコードのレスポンス)で RateLimit ヘッダーフィールドを返す際には注意するべきです。利用可能クォータが低いと、クライアントがリクエストを発行できなくなる可能性があるためです。たとえば、以下の RateLimit ヘッダーフィールドがある場合、利用可能クォータが 0 であるため、クライアントは "Location" ヘッダーフィールド([HTTP] の Section 10.2.2 を参照)に従う前に 10 秒待つことを決定する可能性があります。

HTTP/1.1 301 Moved Permanently
Location: /foo/123
RateLimit: "problemPolicy";r=0;t=10

レスポンスに Retry-After と RateLimit ヘッダーフィールドの両方が含まれる場合、 Retry-After フィールド値は、有効ウィンドウの終了より前の時点を参照するべきではありません(SHOULD NOT)。

RateLimit ヘッダーフィールドを使用するサービスは、望ましくない量のリクエストを露出する値を伝達してはならず(MUST NOT)、 利用可能クォータ値と有効ウィンドウ値の比率に上限を設けるメカニズムを実装するべきです(SHOULD)(Section 8.5 を参照)。これは、クォータポリシーが大きな時間ウィンドウを使用する場合に特に重要です。

特定の条件下では、サーバーは、たとえばサービス拒否攻撃への対応やリソース飽和の場合に、後続のリクエスト間で RateLimit ヘッダーフィールド値を人為的に下げてもよいです(MAY)。

6.1. パーティションキーの生成

サーバーは、異なる利用者または異なるリソースに割り当てられたクォータを区別するパーティションキーを返すことを選択してもよいです(MAY)。サーバー容量を分割する戦略には、ユーザー単位、アプリケーション単位、HTTP メソッド単位、リソース単位、またはそれらの組み合わせなど、幅広いものがあります。サーバーは、クライアントが将来のリクエストについてキー値を予測し、そのリクエストを実行するのに十分なクォータが利用可能かどうかを判断できるよう、パーティションキーの生成方法を文書化するべきです(SHOULD)。サーバーは、機微情報を含むパーティションキーを返すことを避けるべきです。サーバーは、パーティションキーの生成に、リクエスト内に存在する情報のみを使用するべきです(SHOULD)。

6.2. 性能に関する考慮事項

サーバーは、すべてのレスポンスで RateLimit ヘッダーフィールドを返す必要はなく、クライアントはこれを考慮に入れる必要があります。たとえば、性能を懸念する実装者は、特定のクォータが枯渇に近い場合にのみ RateLimit ヘッダーフィールドを提供するかもしれません。

レスポンスフィールドのサイズを懸念する実装者は、コンテンツ長に対する比率を考慮したり、 [HPACK] のようなヘッダー圧縮 HTTP 機能を使用したりすることがあります。

7. クライアントの動作

RateLimit ヘッダーフィールドは、関連付けられたリクエストがサーバーのクォータポリシーを順守したかどうかを判断するため、および後続のリクエストが成功するかどうかの指標として、クライアントによって使用できます。ただし、サーバーは将来のリクエストを処理する際に他の基準を適用する可能性があるため、クォータポリシーはリクエストが成功するかどうかを完全に反映するとは限りません。

たとえば、次のフィールドを持つ成功レスポンスがあるとします。

   RateLimit: "default";r=1;t=7

これは、次のリクエストが成功することを保証しません。サーバーの動作は他の条件に左右される場合があります。

クライアントは、返された RateLimit ヘッダーフィールド値が、スループットおよびレイテンシーに関して合理的なクライアント動作を引き起こすようにする責任があります (Section 8.5 および Section 8.5.1 を参照)。

RateLimit ヘッダーフィールドを受信したクライアントは、将来のレスポンスに同じ RateLimit ヘッダーフィールドが含まれる、または RateLimit ヘッダーフィールドが一切含まれると想定してはなりません(MUST NOT)。

不正な形式の RateLimit ヘッダーフィールドは無視しなければなりません(MUST)。

クライアントは、有効ウィンドウパラメーターで表される時間内に利用可能クォータを超過するべきではありません(SHOULD NOT)。

有効ウィンドウパラメーターの値はレスポンス時に生成されます。大きなネットワークレイテンシーを認識しているクライアントは、それに応じて動作し、他の情報(例: "Date" レスポンスヘッダーフィールド、または別途収集されたメトリクス)を使用してリクエストをスケジュールしてもよいです(MAY)。

RateLimit-Policy ヘッダーフィールドで提供される詳細は情報提供であり、無視してもよいです(MAY)。

レスポンスに RateLimit と Retry-After の両方のフィールドが含まれる場合、Retry-After フィールドが優先されなければならず(MUST)、有効ウィンドウは無視してもよいです(MAY)。

この仕様は特定のスロットリング動作を義務付けず、実装者は次のような好みのポリシーを採用できます。

7.1. パーティションキーの消費

単一のクライアントが異なるクォータ割り当てを消費するリクエストを行う可能性が高い場合、パーティションキーはクライアントにとって有用です。たとえば、異なるユーザーの代理で、または独立したクォータ割り当てを持つ異なるリソースに対してリクエストを行うクライアントなどです。

サーバーがパーティションキー生成アルゴリズムを文書化している場合、クライアントは将来のリクエストのためにパーティションキーを生成してもよいです(MAY)。このキーを使用し、サーバーから返されたキーと比較することで、クライアントはリクエストを実行するのに十分なクォータが利用可能かどうかを判断できます。

サーバーのパーティションキー生成アルゴリズムが不明な場合、クライアントは、過去のリクエストとの類似性に基づいて、将来のリクエストが成功するかどうかを推測するためのヒューリスティックを使用してもよいです(MAY)。

7.2. 仲介者

この節は、[HTTP] の Section 16.3.2 で助言されている考慮事項を文書化します。

発信元サービスインフラストラクチャの一部ではなく、Origin Server が使用するクォータポリシーのセマンティクスを認識していない仲介者は、より寛容なクォータポリシーを伝達するような形で RateLimit ヘッダーフィールドの値を変更するべきではありません(SHOULD NOT)。これには、RateLimit ヘッダーフィールドの削除も含まれます。

仲介者は、次の場合に、より制限的なクォータポリシーを伝達するように RateLimit ヘッダーフィールドを変更してもよいです(MAY)。

  • Origin Server が使用するクォータ単位セマンティクスを認識している場合。

  • この仕様を実装し、フィールドで伝達されたものよりも制限的なクォータポリシーを適用している場合。

仲介者は、リクエストが処理されない可能性があると推定する場合でも、リクエストを転送するべきです(SHOULD)。RateLimit ヘッダーフィールドを返すサービスが、伝達されたクォータポリシーを適用する唯一の責任を持ち、受信リクエストを処理するかどうかは常に自由です。

この仕様は、再試行に関して仲介者にいかなる動作も義務付けず、仲介者がクォータポリシーを尊重する役割を持つことも要求しません。たとえば、プロキシがクライアントに通知せずにリクエストを再送信し、その結果クォータ単位を消費することは正当です。

プライバシーに関する考慮事項Section 9では、仲介者に関するさらなる指針を提供します。

7.3. キャッシュ

[HTTP-CACHING] は、RateLimit ヘッダーフィールドを持つレスポンスを含め、レスポンスを保存し、後続のリクエストに再利用する方法を定義します。 キャッシュされたレスポンス上の RateLimit ヘッダーフィールドの情報は最新でない可能性があるため、 キャッシュから来たレスポンス (すなわち、正の current_age を持つもの。[HTTP-CACHING] の Section 4.2.3 を参照)では、それらは無視されるべきです(SHOULD)。

8. セキュリティに関する考慮事項

8.1. スロットリングはクライアントによるリクエスト発行を防止しない

この仕様は、クライアントがリクエストを行うことを防ぎません。 サーバーは、リソース枯渇を防ぐメカニズムを常に実装するべきです。

8.2. 情報開示

サーバーは、そのインフラストラクチャリソースを飽和させるために使用され得る運用容量情報を、信頼できない相手に開示するべきではありません。

この仕様は、非成功レスポンスがクォータを消費するかどうかを義務付けませんが、 エラーレスポンス(401 (Unauthorized) や 403 (Forbidden) など)がクォータにカウントされる場合、 悪意あるクライアントはエンドポイントを探査して、別のユーザーのトラフィック情報を取得できる可能性があります。

仲介者は、ユーザーエージェントの事前知識なしにリクエストを再送信し、 クォータ単位を消費する場合があるため、 RateLimit ヘッダーフィールドは、仲介者の存在をユーザーエージェントに明らかにする可能性があります。

パーティションキーがクライアントアプリケーションまたはユーザーの識別情報を含む場合、サーバーはなりすましの可能性を認識し、適切なセキュリティメカニズムを適用するべきです。

8.3. 利用可能なクォータ単位は許可済みリクエストではない

RateLimit ヘッダーフィールドは、クライアントがスロットリングされるのを避けるのを助けるために、サーバーからクライアントへヒントを伝達します。

クライアントは、利用可能クォータパラメーターSection 4.1.1をサービスレベル合意とみなしてはなりません(MUST NOT)。

リソース飽和の場合、サーバーは、通知されたクォータに関係なく、返される値を人為的に下げたり、リクエストを処理しなかったりしてもよいです(MAY)。

8.4. 有効ウィンドウの変動性

有効ウィンドウパラメーターSection 4.1.2は、サーバーがいつ利用可能クォータを増やすかについて何も意味しません。有効ウィンドウは必ずしも固定された時点で終了するとは限りません。

後続のリクエストは、並行数を制限したり、動的または適応的なスロットリングポリシーを実装したりするために、より高い有効ウィンドウ値を返す場合があります。

8.5. リソース枯渇

有効ウィンドウ値を返す場合、サーバーは、多数のスロットリングされたクライアントが指定されたまさにその瞬間に戻ってくる可能性があることを認識していなければなりません。

これは Retry-After にも当てはまります。

たとえば、クォータが毎日 18:00:00 にリセットされ、 サーバーがそれに応じて有効ウィンドウを返す場合、

   Date: Tue, 15 Nov 1994 18:00:00 GMT
   RateLimit: "daily";r=1;t=86400

すべてのクライアントが 18:00:00 に現れる可能性が高くなります。

これは、有効ウィンドウにいくらかのジッターを追加することで軽減できます。

リソース枯渇の問題は、大きな時間ウィンドウを使用するクォータポリシーに関連する可能性があります。ユーザーエージェントが偶然または意図的に、かなり短い間隔で自身のクォータ単位の大部分を消費する可能性があるためです。

この動作は、提供された RateLimit ヘッダーフィールドによって引き起こされることさえあります。 次の例は、1000 秒あたり 10000 クォータ単位の未消費クォータポリシーを持つサービスを説明します。

RateLimit-Policy: "somepolicy";q=10000;w=1000
RateLimit: "somepolicy";r=10000;t=10

利用可能クォータと有効ウィンドウの単純な比率を実装するクライアントは、平均スループットを 1 秒あたり 1000 クォータ単位と推論する可能性があります。一方、ポリシーのクォータおよびウィンドウパラメーターは、平均 1 秒あたり 10 クォータ単位を伝達しています。 サービスがそのような負荷を処理できない場合、より低い利用可能クォータまたはより高い有効ウィンドウを返すべきです。 さらに、大きな時間ウィンドウのクォータポリシーを短い時間ウィンドウのものと組み合わせることで、これらのリスクを軽減できます。

8.5.1. サービス拒否

RateLimit ヘッダーフィールドは、偶然または意図的に予期しない値を含む場合があります。 たとえば、過度に高い利用可能クォータは、次のような可能性があります。

  • 悪意ある仲介者によって、サービス拒否攻撃を引き起こしたり、 リクエストを増加させてクライアントリソースを消費させたりするために使用される。

  • 誤設定されたサーバーによって渡される。

または、大きな有効ウィンドウは、クライアントがサーバーに連絡することを抑制する可能性があります(例: "Retry-after: 1000000" を受信する場合と同様)。

このリスクを軽減するために、クライアントは、クォータ単位、時間ウィンドウ、同時リクエスト、またはスループットの観点から合理的と考えるしきい値を設定し、RateLimit がそれらのしきい値を超えた場合の一貫した動作を定義できます。 たとえば、これは 1 秒あたりの最大リクエスト数に上限を設けること、または有効ウィンドウが 10 分を超える場合に再試行を実装することを意味します。

上記の考慮事項は RateLimit ヘッダーフィールドに限定されず、クライアントが後続のリクエストでどのように動作するかに影響するすべてのフィールド(例: Retry-After)に適用されます。

9. プライバシーに関する考慮事項

レート制限を求めるリクエストに基づいて動作するクライアントは、 潜在的に再識別可能です([PRIVACY] の Section 5.2.1 を参照)。 これは、それらのクライアントにのみ与えられる可能性がある情報に反応するためです。 これは他のフィールド(例: Retry-After)にも適用される可能性があることに注意してください。

レート制限は通常、クライアントが識別されている、またはプロファイル化されている文脈 (例: 異なるユーザーに異なるクォータ単位を割り当てる場合)で実装されるため、 これはめったに懸念事項にはなりません。

RateLimit ヘッダーフィールドを使用するプライバシー強化インフラストラクチャは、 再識別リスクを軽減するための特定の技術を定義できます。

10. IANA に関する考慮事項

IANA には、2 つのレジストリを更新し、1 つの新しいレジストリを作成することが求められます。

10.1. HTTP フィールド名レジストリの更新

"Hypertext Transfer Protocol (HTTP) Field Name Registry" レジストリ([HTTP])に、次のエントリーを追加してください。

表 1
フィールド名 構造化型 ステータス 仕様
RateLimit List permanent RFC nnnn の Section 4
RateLimit-Policy List permanent RFC nnnn の Section 3

10.2. HTTP 問題タイプ レジストリの更新

IANA には、https://www.iana.org/assignments/http-problem-types にある "HTTP Problem Types" レジストリに、次のエントリーを登録することが求められます。

10.2.1. "quota-exceeded" 問題タイプの登録

タイプ URI: https://iana.org/assignments/http-problem-types#quota-exceeded

タイトル: クォータ超過

推奨 HTTP ステータスコード: 429

参照: この文書の Section 5.1

10.2.2. "temporary-reduced-capacity" 問題タイプの登録

タイプ URI: https://iana.org/assignments/http-problem-types#temporary-reduced-capacity

タイトル: 一時的な容量低下

推奨 HTTP ステータスコード: 503

参照: この文書の Section 5.2

10.2.3. "abnormal-usage-detected" 問題タイプの登録

タイプ URI: https://iana.org/assignments/http-problem-types#abnormal-usage-detected

タイトル: 異常な使用の検出

推奨 HTTP ステータスコード: 429

参照: この文書の Section 5.3

10.3. RateLimit クォータ単位 レジストリ

この仕様は、"Hypertext Transfer Protocol (HTTP) RateLimit Quota Units" レジストリを確立し、 https://www.iana.org/assignments/http-ratelimit-quota-units に配置します。登録は、IESG またはその委任先によって任命された Designated Expert の助言に基づいて行われます。すべてのエントリーは Specification Required([IANA], Section 4.6)です。

このレジストリは、次の初期内容を持ちます。

表 2
クォータ単位 参照 注記
request RFC nnnn
content-bytes RFC nnnn
concurrent-requests RFC nnnn

10.3.1. 登録 テンプレート

RateLimit Quota Units レジストリの登録テンプレートは次のとおりです。

  • クォータ単位: クォータ単位の名前。

  • 参照: クォータ単位を指定する文書への参照。

  • 注記: クォータ単位に関する追加の注記。

11. 参考文献

11.1. 規範的参考文献

[HTTP]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
[IANA]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[PROBLEM]
Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, , <https://www.rfc-editor.org/rfc/rfc9457>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[SF]
Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, , <https://www.rfc-editor.org/rfc/rfc9651>.
[WEB-ORIGIN]
Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, , <https://www.rfc-editor.org/rfc/rfc6454>.

11.2. 参考情報としての参考文献

[HPACK]
Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, , <https://www.rfc-editor.org/rfc/rfc7541>.
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, , <https://www.rfc-editor.org/rfc/rfc9111>.
[PRIVACY]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, , <https://www.rfc-editor.org/rfc/rfc6973>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/rfc/rfc3339>.
[RFC6585]
Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, , <https://www.rfc-editor.org/rfc/rfc6585>.
[UNIX]
The Open Group, "The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98", .

付録 A. レート制限とクォータ

サーバーは、システム過負荷を避けるため、計算リソースの公平な分配を確保するため、または他のポリシー(例: 収益化)を適用するために、クォータメカニズムを使用します。

基本的なクォータメカニズムは、所定の時間ウィンドウ内で受け入れ可能なリクエスト数を制限します。例: 1 秒あたり 10 リクエスト。

クォータが超過した場合、サーバーは通常、リクエストを処理せず、代わりに 4xx HTTP ステータスコード(例: 429 または 403)で応答するか、接続を切断するなど、より積極的なポリシーを採用します。

クォータは、さまざまな基準(例: ユーザーごと、IP ごと、地理的領域ごとなど)およびさまざまなレベルで適用される場合があります。たとえば、ユーザーは次を発行することを許可される場合があります。

さらに、システムメトリクス、統計、およびヒューリスティックを使用して、受け入れ可能なリクエスト数と時間ウィンドウを動的に計算する、より複雑なポリシーを実装できます。

クライアントがリクエストをスロットリングするのを助けるため、 サーバーは、クォータポリシーの評価に使用されるカウンターを HTTP ヘッダーフィールドを介して公開できます。

それらのレスポンスヘッダーは、API ゲートウェイやリバースプロキシなどの HTTP 仲介者によって追加される場合があります。

Web 上では、所定の時間ウィンドウ内で許可されるリクエスト数や、ウィンドウがリセットされる時点を通常含む、さまざまなレート制限ヘッダーを見つけることができます。

一般的な選択は、次を含む 3 つのヘッダーを返すことです。

A.1. 相互運用性の問題

スロットリングにおける主要な相互運用性の問題は、標準ヘッダーの欠如です。その理由は次のとおりです。

  • 各実装が、同じヘッダーフィールド名に異なるセマンティクスを関連付ける。

  • ヘッダーフィールド名が増殖する。

したがって、異なるサーバーとやり取りするユーザーエージェントは、異なるヘッダーを処理する必要があるかもしれません。 または、異なるリバースプロキシの背後にある同じアプリケーションインターフェイスが、 異なるスロットリングヘッダーで応答する場合があります。

付録 B.

B.1. ポリシーを定義しないレスポンス

一部のサーバーは、RateLimit-Policy ヘッダーフィールドでポリシー制限を公開しない場合があります。クライアントは、それでも RateLimit ヘッダーフィールドを使用してリクエストをスロットリングできます。

B.1.1. レスポンス内のスロットリング情報

クライアントは、次の 50 秒間のクォータを使い果たしました。 制限と時間ウィンドウは帯域外で伝達されます。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "default";r=0;t=50

{"hello": "world"}

フィールド値は必ずしもレスポンスステータスコードと相関しているわけではないため、 後続のリクエストが失敗することは要求されません。 下の例は、利用可能クォータが 0 であっても、サーバーがリクエストを処理することを決定したことを示します。 別のサーバー、または別の負荷条件下の同じサーバーは、 代わりにリクエストをスロットリングすることを決定したかもしれません。

リクエスト:

GET /items/456 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "default";r=0;t=48

{"still": "successful"}

B.1.2. レスポンス内の複数のポリシー

サーバーは、クライアントのリクエストを制限するために 2 つの異なるポリシーを使用します。

  • 日次 5000 クォータ単位。

  • 時間単位 1000 クォータ単位。

クライアントは最初の 14 時間で 4900 クォータ単位を消費しました。

次の時間単位制限が 1000 クォータ単位であるにもかかわらず、 到達に最も近い制限は日次のものです。

そこでサーバーは、クライアントに次を知らせるために RateLimit ヘッダーフィールドを公開します。

  • 日次クォータには 100 クォータ単位しか残っておらず、 ウィンドウは 10 時間後に終了する。

サーバーは、時間単位ポリシーが日次ポリシーと同じクォータ単位を使用し、日次ポリシーが枯渇に最も近いものであるため、時間単位ポリシーを返すことを省略してもよいです(MAY)。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "dayLimit";r=100;t=36000

{"hello": "world"}

B.1.3. 並行数を制限するための使用

RateLimit ヘッダーフィールドは、並行数を制限するために使用される場合があります。 飽和の場合に通常より低い制限を通知することで、可用性を高めます。

サーバーは、1 分あたり 100 クォータ単位の基本ポリシーを採用し、 リソース枯渇の場合には、利用可能クォータ値と有効ウィンドウ値の両方を下げることで、返される値を適応させました。

2 秒後、クライアントは 40 クォータ単位を消費しました。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Policy: "basic";q=100;w=60
RateLimit: "basic";r=60;t=58

{"elapsed": 2, "issued": 40}

後続のリクエストでは、リソース枯渇のため、 サーバーは r=20 のみを通知します。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Policy: "basic";q=100;w=60
RateLimit: "basic";r=20;t=56

{"elapsed": 4, "issued": 41}

B.1.4. スロットリングされたレスポンスでの使用

クライアントはクォータを使い果たし、サーバーは Retry-After を送信してクライアントをスロットリングします。

この例では、Retry-After と RateLimit ヘッダーフィールドの値は同じ瞬間を参照しますが、これは要件ではありません。

429 (Too Many Request) HTTP ステータスコードは単なる例として使用されています。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Date: Mon, 05 Aug 2019 09:27:00 GMT
Retry-After: Mon, 05 Aug 2019 09:27:05 GMT
RateLimit: "default";r=0;t=5

{
"type": "https://iana.org/assignments/http-problem-types#quota-exceeded"
"title": "Too Many Requests",
"status": 429,
"violated-policies": ["default"]
}

B.2. 定義済みポリシーを伴うレスポンス

B.2.1. パラメーターで指定されたスロットリングウィンドウ

クライアントには、次の 50 秒間に 99 クォータ単位が残っています。 時間ウィンドウは w パラメーターによって伝達されるため、スループットが 1 分あたり 100 クォータ単位であることがわかります。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit: "fixedwindow";r=99;t=50
RateLimit-Policy: "fixedwindow";q=100;w=60
{"hello": "world"}

B.2.2. パラメーター化されたウィンドウによる動的制限

RateLimit-Policy ヘッダーフィールドによって伝達されるポリシーは、 サーバーが 1 分あたり 100 クォータ単位を受け入れることを述べています。

リソース枯渇を避けるため、サーバーはスロットリングヘッダーで返される実際の制限を人為的に下げます。

その後、RateLimit ヘッダーフィールドは、クライアントを減速させるため、次の 50 秒間について 9 クォータ単位のみを通知します。

サーバーは RateLimit ヘッダーフィールド内の他の値も下げることができた点に注意してください。この仕様は、後続のレスポンスに含まれるフィールド値間の関係をいかなる形でも義務付けません。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 Ok
Content-Type: application/json
RateLimit-Policy: "dynamic";q=100;w=60
RateLimit: "dynamic";r=9;t=50


{
  "status": 200,
  "detail": "Just slow down without waiting."
}

B.2.3. 押し戻しと減速のための動的制限

前の例の続きとして、クライアントが 10 秒待って新しいリクエストを実行し、 リソース枯渇のためにサーバーがそれを拒否して押し戻し、次の 20 秒間について r=0 を通知するとします。

サーバーは、20 秒が経過した後の元のウィンドウの残り期間に対してクライアントを減速させるため、より小さいウィンドウとより低い制限を通知します。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
RateLimit-Policy: "dynamic";q=15;w=20
RateLimit: "dynamic";r=0;t=20

{
  "status": 429,
  "detail": "Wait 20 seconds, then slow down!"
}

B.3. Retry-After による押し戻しと減速のための動的制限

あるいは、前の例が始まる同じ文脈において、Retry-After を介して同じ情報をクライアントに伝達できます。 これには、リトライ時刻の後に適用されるポリシーの公称制限とウィンドウをサーバーが指定できるという利点があります。たとえば、その時点までにリソース枯渇が解消される可能性が高いと仮定すれば、通知されたポリシーを調整する必要はなく、それでも一定期間リクエストを停止し、現在のウィンドウの残りを減速させることに成功します。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 20
RateLimit-Policy: "dynamic";q=100;w=60
RateLimit: "dynamic";r=15;t=40

{
  "status": 429,
  "detail": "Wait 20 seconds, then slow down!"
}

この最後のレスポンスでは、クライアントは Retry-After を尊重し、指定された時間の間リクエストを行わないことが期待されます。一方、前の例では、有効ウィンドウの終了前にクライアントがリクエストを停止することを強制しません。リクエストが拒否される可能性が高いとしても、クライアントはサーバーに再度問い合わせる自由が残されているためです。

B.3.1. 複数のウィンドウでの使用

これは、付録 B.1.2 で詳述されたポリシーを記述する標準化された方法です。

  • 日次 5000 クォータ単位。

  • 時間単位 1000 クォータ単位。

クライアントは最初の 14 時間で 4900 クォータ単位を消費しました。

次の時間単位制限が 1000 クォータ単位であるにもかかわらず、 到達に最も近い制限は日次のものです。

そこでサーバーは、クライアントに次を知らせるために RateLimit ヘッダーフィールドを公開します。

  • 100 クォータ単位しか残っていない。

  • 有効ウィンドウは 10 時間である。

  • expiring-limit は 5000 である。

リクエスト:

GET /items/123 HTTP/1.1
Host: api.example

レスポンス:

HTTP/1.1 200 OK
Content-Type: application/json
RateLimit-Policy: "hour";q=1000;w=3600, "day";q=5000;w=86400
RateLimit: "day";r=100;t=36000

{"hello": "world"}

FAQ

この節は、RFC として公開される前に削除される予定です。

  1. なぜスロットリングのために標準フィールドを定義するのですか。

    スロットリングポリシーの適用を簡素化し、クライアントがスロットリングされることを避けるためにリクエストを制約できるようにするためです。

  2. スロットリングされたレスポンス(例: ステータスコード 429)で RateLimit ヘッダーフィールドを使用できますか。

    はい、使用できます。

  3. これらの仕様は RFC 6585 に結び付いていますか。

    いいえ。[RFC6585]429 ステータスコードを定義しており、私たちはそれをスロットリングされたリクエストの例として使用しているだけです。 その代わりに 403 や任意のステータスコードを使用することもできます。

  4. なぜパーティションキーが必要なのですか。

    パーティションキーがない場合、サーバーは実質的に 1 つのスコープ(別名 partition)しか持てず、これはほとんどのサービスにとって実用的ではありません。あるいは、スコープを帯域外で伝達する必要があります。 これにより、リクエストがスロットリングされることを防ぐために使用できる汎用コネクターコードの開発が妨げられます。 多くの API は、クォータを割り当てるために API キー、ユーザー ID、またはクライアント ID に依存しています。 単一のクライアントが複数のパーティションに対するリクエストを処理するようになると、クライアントは、割り当てられたクォータに対してリクエストを適切に追跡するために、対応するパーティションキーを知る必要があります。

  5. なぜ UNIX Timestamp ではなく delay-seconds を使用するのですか。 なぜサブ秒精度を使用しないのですか。

    delay-seconds を使用することは、429 レスポンスなどの類似した文脈で返される Retry-After と整合します。

    タイムスタンプにはクロック同期プロトコルが必要です ([HTTP] の Section 5.6.7 を参照)。 これは問題になる可能性があります(例: クロック調整、クロックスキュー、ハードコードされたクロック同期サーバーの障害、 IoT デバイスなど)。 さらに、タイムスタンプはクロック調整により単調増加しない可能性があります。 Another NTP client failure story を参照してください。

    サブ秒精度を使用しなかった理由は次のとおりです。

    • これは、adjtimex() Linux システムコールを介して実装されるようなシステムクロック補正の影響をより受けやすい。

    • レスポンス時間レイテンシーのため、その価値がない可能性があります。この主題に関する短い議論は、 httpwg ml にあります。

    • ほぼすべてのレート制限ヘッダー実装が使用していない。

  6. リクエストレートではなく並行数を制限すべきではありませんか。

    この仕様を使用して HTTP レベルで並行数を制限し ({#use-for-limiting-concurrency} を参照)、 クライアントがスロットリングされることを避けるようリクエストを整形するのを助けることができます。

    並行数を制限する問題のある方法は、接続を切断することです。 特に接続が多重化されている場合(例: HTTP/2)には、 これによりクライアントリクエストが処理されなくなり、 これは私たちが避けたいことです。

    並行数を制限するセマンティックな方法は、リソース飽和の場合(例: スラッシング、接続キューが長すぎる、 Service Level Objectives が満たされないなど)に 503 + Retry-After を返すことです。 飽和条件は動的でも静的でもあり得ます。これらすべては現在の文書の範囲外です。

  7. remaining パラメーターの正の値は、 将来のリクエストが処理されるというサービス保証を意味しますか。

    いいえ。FAQ は Section 4.1.1 に統合されています。

  8. quota-policy の定義は複雑すぎますか。

    いつでも最も単純な形式を返すことができます。

RateLimit:"default";r=50;t=60

ポリシーキーは、ポリシーの現在の使用状況を定義された制限に明確に結び付けます。 したがって、次のフィールドでは、

RateLimit-Policy: "sliding";q=100;w=60;burst=1000
RateLimit-Policy: "fixed";q=5000;w=3600;burst=0
RateLimit: "sliding";r=50;t=44

値 "sliding" は、報告されているポリシーを識別します。

  1. 仲介者は RateLimit ヘッダーフィールドを変更できますか。

    一般に、それはリクエストが処理されなくなる結果を招く可能性があるため、行うべきではありません。 ただし、仲介者が RateLimit ヘッダーフィールドを変更する妥当なユースケースもあります。 たとえば、より厳しいクォータポリシーを適用する場合や、 サービスの能動的な構成要素である場合です。 そのような場合、私たちはそれらを発信元インフラストラクチャの一部とみなします。

  2. なぜ w パラメーターは単なる情報提供なのですか。 クライアントがリクエストレートを判断するために使用できるのではありませんか。

    情報提供ではない w パラメーターは、クライアントとサーバーが密接に結合された環境では問題ないかもしれません。 この詳細を伴うポリシーを大規模に伝達することは非常に複雑であり、実装はおそらく相互運用できないでしょう。 そのため、w を情報提供パラメーターのままにし、スロットリング動作を定義するためには limit、remaining、reset パラメーターのみに依存することにしました。

  3. RateLimit フィールドを trailer で使用できますか。 サーバーは通常、レスポンスを作成する前に、リクエストがクォータ内であるかどうかを確立するため、その時点で RateLimit フィールド値はすでに利用可能であるべきです。 trailer をサポートする唯一の利点は、遅いレスポンスの場合に、より最新の情報をクライアントに提供できることです。 しかし、これはヘッダーと trailer のフィールドを結合すること、および trailer を削除する仲介者を考慮することに関して、クライアント実装を複雑にします。 trailer を使用する現在の実装はないため、これを将来の作業として残すことにしました。

Web で現在使用されている RateLimit ヘッダーフィールド

この節は、RFC として公開される前に削除される予定です。

一般的に使用されるヘッダーフィールド名は次のとおりです。

ヘッダーフィールド名でウィンドウが指定される変種もあります。例:

相互運用性の問題には次のようなものがあります。

RateLimit のセマンティクスはウィンドウ処理アルゴリズムに依存します。 たとえば、スライディングウィンドウポリシーでは、remaining パラメーター値が現在スループットと最大スループットの比率に関連する結果になる場合があります。 例:

RateLimit-Policy: "sliding";q=12;w=1
; using 50% of throughput, that is 6 units/s
RateLimit: "sliding";q=12;r=6;t=1

この場合、最適な解は次を達成することです。

RateLimit-Policy: "sliding";q=12;w=1
; using 100% of throughput, that is 12 units/s
RateLimit: "sliding";q=12;r=1;t=1

この時点で、リクエストレートを増やすことを停止するべきです。

謝辞

これらの仕様の初期コントリビューターである Willi Schoenborn、Alejandro Martinez Ruiz、Alessandro Ranellucci、 Amos Jeffries、 Martin Thomson、 Erik Wilde、Mark Nottingham に感謝します。 最初のコミュニティ実装者である Aapo Talvensaari、 Nathan Friedly、 Sanyam Dogra に敬意を表します。

上記の人々に加えて、この文書は HTTPAPI 作業部会での広範な議論に大きく依拠しています。 これには Rich Salz、 Julian Reschke が含まれます。

変更点

この節は、RFC として公開される前に削除される予定です。

draft-ietf-httpapi-ratelimit-headers-08 以降

この節は、RFC として公開される前に削除される予定です。

  • 問題タイプを追加

  • RateLimit-Policy と RateLimit フィールドをいつ使用するかを明確化

draft-ietf-httpapi-ratelimit-headers-07 以降

この節は、RFC として公開される前に削除される予定です。

  • 両方のフィールドを、ポリシーを識別しパラメーターを使用する Item のリストにリファクタリング

  • クォータ単位パラメーターを追加

  • パーティションキーパラメーターを追加

draft-ietf-httpapi-ratelimit-headers-03 以降

この節は、RFC として公開される前に削除される予定です。

  • RateLimit-Policy #81 でポリシー情報を分割

draft-ietf-httpapi-ratelimit-headers-02 以降

この節は、RFC として公開される前に削除される予定です。

  • スロットリングスコープ #83 に対応

draft-ietf-httpapi-ratelimit-headers-01 以降

この節は、RFC として公開される前に削除される予定です。

  • IANA considerations #60 を更新

  • Structured fields #58 を使用

  • 文書を再編成 #67

draft-ietf-httpapi-ratelimit-headers-00 以降

この節は、RFC として公開される前に削除される予定です。

  • delta-seconds ではなく delay-seconds への参照を含む I-D.httpbis-semantics を使用 #5

著者の連絡先

Roberto Polli
Team Digitale, Italian Government
イタリア
Alejandro Martinez Ruiz
Red Hat
Darrel Miller
Microsoft