1分60件までの制限に対し、境目の前後に集めて送りました。固定の窓では2秒で120件が通ります。
滑る窓なら60件です。同じ上限を書いていても、数え方で2倍違います。
数え方は仕様の外です。同じ上限を書いていても、実装によって通る量が変わります。
レート制限の実装について、RFCは範囲を明示しています。この仕様は、送り元の伺いを立てる側が利用者をどう見分けるかも、要求をどう数えるかも定めないことに注意することという記述です。
つまり数え方は自分で決めます。3つの数え方を実装し、同じ要求の列に当てました。
1分60件までの制限に対し、境目の直前に60件、直後に60件を送ります。2秒の間に120件です。
1分あたり 60件まで通す。窓の境目の前後に要求を集める 境目の直前に60件、直後に60件を送る（合わせて2秒の間に120件） 数え方 2秒の間に通った数 1分あたりに直すと 固定の窓 120件 3,600件 滑る窓 60件 1,800件 溜める器 61件 1,830件
固定の窓では120件すべてが通りました。上限の2倍です。
滑る窓では60件で止まります。直近60秒を見ているので、境目という概念がありません。
固定の窓は、窓が変わると数を0に戻します。直前の60件は前の窓、直後の60件は次の窓に数えられます。
どちらの窓も上限を守っています。それでも、2秒という短い時間では2倍が通ります。
この試し方は、そのまま検査になります。境目にそろえて送り、通った数を数えるだけです。
どの窓も上限を守っているのに、またぐと2倍通る。
Note that this specification does not define how the origin server identifies the user, nor how it counts requests.原文RFC 6585「Additional HTTP Status Codes」 この内容の有効期限2027-02-18
厳密さと、覚えておく量が釣り合います。滑る窓は正確ですが、時刻を全部持ちます。
レート制限の実装で返す答えは決まっています。RFCは429という状態の符号は、利用者が与えられた時間の中で多くの要求を送りすぎたことを示すと定めています。
返し方は共通でも、数え方は3通りあります。それぞれ覚えておく量が違います。
2番目だけが、上限に比例した量を持ちます。1分1万件なら、1万個の時刻を利用者ごとに持ちます。
1番目と3番目は2つの値だけです。利用者が増えても、1人あたりの量は変わりません。
境目を狙わない普段の要求では、3つの差は小さくなります。60分ぶんを流して数えました。
1分あたり 60件まで通す。60分ぶんを流す 要求の来る割合を変えて、通った数を比べる 要求の割合 来た数 固定の窓 滑る窓 溜める器 （通った数） 0.5件/秒 1766件 1766件 1766件 1766件 1件/秒 3544件 3370件 3237件 3529件 2件/秒 7026件 3600件 3541件 3659件 5件/秒 17872件 3600件 3600件 3659件
上限に届かない量なら、3つとも1766件で同じです。差が出るのは詰まってからです。
5件/秒でも、通った数は3600件前後で揃います。長い目で見れば、どれも上限を守っています。
つまり選ぶ基準は平均ではありません。短い時間にどれだけ通すかと、覚えておく量です。
The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").原文RFC 6585「Additional HTTP Status Codes」 この内容の有効期限2027-02-18
分ける単位が公平さを決めます。ただし分けると、全体を通る量が増えます。
レート制限の実装では、断ったあとの案内も求められます。RFCは応答の表現は、その状況を説明する詳細を含むべきであり、新しい要求を出す前にどれだけ待つべきかを示す見出しを含んでもよいと述べています。
案内する前に、誰を断るかが問題になります。分ける単位を変えて数えました。
利用者50人のうち、1人が89.1%の要求を占める場面です。
利用者 50人・30分ぶん。要求は合わせて 40,088件 うち1人が 35,733件（89.1%）を占める 分け方 通った数 その1人ぶん 他の49人ぶん 他の人が断られた割合 全体で1つ 1800件 1576件 224件 94.9% 利用者ごとに1つ 6155件 1800件 4355件 0.0%
全体で1つにすると、他の49人は94.9%が断られます。通ったのは224件だけです。
利用者ごとに分ければ0.0%です。他の人は誰も断られません。
左の列を見てください。通った数が1800件から6155件へ、3.4倍になります。
利用者ごとに1分60件を許すので、50人なら合計3000件まで通り得ます。全体の上限を守りたいなら、別に置くことになります。
だから実際には2段にすることになります。利用者ごとの上限と、全体の上限の両方です。
断られたあとの再試行が山を作る問題は、待ち行列の側の話につながります。その形はジョブキューの記事で扱いました。
要求の来る時刻は一定の割合で引いたもので、実際には波があります。1人が89.1%を占めるという偏りも置いたものです。3つの数え方はこの場で実装したもので、実際の製品では窓を細かく分けて近似するなど、中間の方式もあります。ここで見せているのは、同じ上限でも数え方によって短い時間の通り方が2倍変わること、分ける単位が公平さと総数の両方を動かすことの2つです。
The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.原文RFC 6585「Additional HTTP Status Codes」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る