要約

  • 429 Too Many Requests は、サーバーが同じ主体に帰属させた要求列がローカルな予算を越えたことを示す。要求の構文不良や、自然人による濫用を証明する符号ではない。
  • Retry-After は次に試す時期を示せるが、将来の処理枠を予約しない。待った後も、その時点の負荷、権限、方針、資源状態によって判断は変わる。
  • RFC 6585 は利用者の識別方法も計数方法も定義しなかった。429 は帳簿の結果を可視化する一方、その帳簿の正しさを保証しない。

同じ要求が一つ遅く届いたとき

ある API が、ログイン済みアカウントごとに一時間五十回まで受け付けるとする。五十回目と五十一回目は同じ形式で、同じ資源を求め、同じ正当な資格情報を持ち得る。それでも後者だけが拒否される。違いは要求の内部ではなく、サーバーが保存してきた過去との関係にある。

頻度制限に固有の応答がなければ、クライアントは一般的な 4xx を見て内容を直そうとするかもしれない。503 を見れば、全サービスが止まったと考えるかもしれない。RFC 6585 は 2012 年、この間に 429 を置いた。選ばれた主体の現在の要求量が、選ばれた時間と範囲の上限を越えた、と伝えるためである。

ただし RFC は判定の裏側を共通化しない。応答は状態の説明を含むべきで、Retry-After を含めてもよい。一方、オリジンが利用者をどう識別するか、要求をどう数えるかは定義しない。共通になったのは結論であって、台帳ではない。

「利用者」は実名ではなく集計の境界

機械が早い段階で利用できる手掛かりには、認証アカウント、API キー、セッション cookie、テナント、送信元アドレスなどがある。RFC 6585 が資格情報と cookie を例に挙げても、それらが一人の人間を表すとは限らない。

送信元 IP はエッジで安く得られる。しかし CGNAT、企業の出口、プライバシー中継の後ろでは、多数の無関係な人が一つに見える。誰かの急増が全員の枠を使い切ることもある。そのとき 429 はアドレス単位の判定として成立しても、拒否された各人が自分の割当を超えた証拠にはならない。

認証済みアカウントにも別の曖昧さがある。一つのアカウントを複数端末やチームが使い、キーが共有または盗用されることがある。識別材料が違えば、正当に言える範囲も違う。アドレスを数えた結果を、人への非難に拡張してはならない。

429 が示すのは「この方針が作った主体の枠が尽きた」という局所的事実である。誰であるかを証明する力は持たない。

どこまでを一つの財布にするか

RFC 6585 は、資源ごと、サーバー全体、複数サーバーの集合という計数範囲を例示する。高価な検索だけを別に制限すれば、設定画面は動き続ける。サーバー全体を一つにすれば共有容量を守りやすいが、軽い確認と重い生成が同じ一単位になるかもしれない。

テナント単位は契約に合わせやすいが、全要求を正しい契約主体へ結び付ける必要がある。地域をまたぐ共通カウンターは一貫した枠を作る一方、複製の遅れ、分断、計数基盤の障害時にどちらへ倒すかを決めなければならない。

「一要求」の時点すら自明ではない。受信で数えるのか、認証後か、処理を認めた時か、完了後か。リダイレクト、取り消された HTTP/2 ストリーム、プロキシの再送は何単位か。規格が一つに決めないのは、実行資源と状態を持つ場所がサービスごとに違うからである。

正しい形式の 429 が、誤ったカウンターから出ることはあり得る。プロトコル適合は会計監査ではない。

待ち時間は予約票ではない

RFC 9110 によれば、Retry-After は HTTP 日付または受信後の非負秒数で表せる。429 に付けるかどうかは任意である。どちらも「この前には再訪しないでほしい」という情報であり、「この時刻なら必ず通す」という約束ではない。

絶対日付には時刻の基準が必要で、秒数には受信を起点にできる利点がある。しかし多数のクライアントが同じ境界で一斉に目覚めれば、回復時刻が次の山を作る。他の負荷、方針変更、資格の失効、対象資源の変化も、待機後の結果を変える。

クライアントには独自の節度が要る。試行回数を限定し、再開時刻を散らし、仕事の期限を保存し、メソッドの作用に応じて再送可否を決める。非べき等な操作は、時計が進んだだけでは安全にならない。通信障害の中で以前の操作が実行されたかどうかは別の証拠を要する。

429 と 503 は同じ混雑を別名で呼ぶのではない

RFC 9110 の 503 は、過負荷や保守によりサーバーが一時的に要求を処理できないことを表す。429 は、サーバーの頻度方針が選んだ主体について要求が多すぎることを表す。どちらも Retry-After を使えるが、支配している条件が違う。

一つのテナントだけ 429 になり、他が通常どおり使える場合がある。全体が 503 でも、個別枠を超えた者はいない場合がある。両方の保護を持つサービスは、実際に拒否を決めた条件を名乗るべきである。

全体の容量不足をクライアントの過失として語れば責任を移す。局所枠の消費を全停止として語れば、残る経路を隠す。精密な符号は、責任の位置を精密にするためにある。

断るにも計算が要る

RFC 6585 のセキュリティ考察は、攻撃時に全要求へ 429 を返すだけでも資源を消費すると警告する。そのためサーバーは常に 429 を使う必要がなく、接続を落とすなどの手段を選べる。

一つの丁寧な拒否までに、復号、解析、認証、分散カウンター参照、本文生成、暗号化送信が行われるかもしれない。小さな入力でその一式を強制できれば、説明自体が攻撃面になる。エッジで早く止めれば安いが、そこで見える識別材料は弱く、共有アドレスへの巻き添えが増える。

よって説明量には道徳的な定数がない。現在の予算で扱える証拠に比例した、最も狭い作用を選ぶ必要がある。

キャッシュが拒否を延命してはならない

RFC 6585 は 429 応答の保存を禁止する。判定は特定の主体、時刻、範囲、現在値に結び付く。キャッシュが後で再利用すれば、終了した窓を延ばしたり、別の要求文脈へ他者の拒否を適用したりする。

中間者が自分の容量方針を持つなら、新しい状態から 429 を生成できる。古い 429 を表現内容として再生することはできない。判定は、いまの予算を観測できる場所に残される。

429 が言い切らないこと

429 は悪意、濫用、公平な配分、正確な計数、将来の成功を証明しない。すべての過負荷で説明応答を要求することもない。できるのは、内容の誤りや全体の不能とは異なる「局所予算の超過」をクライアントに知らせることだ。

HTTP は配分を発明しなかった。配分の結果に共通の声を与え、その声が台帳そのものを支配しないよう境界を残した。429 の価値は、この狭さにある。

出典