ThrottleSecondsとはいったい何なのか?

hxxk.jp - Movable Type の HTTP error: 403 Throttled に関するまとめ

よいまとめですね。Movable Typeの混乱した仕様をよく説明できています。一番の混乱の原因は、ThrottleSecondsというパラメータに"ad hocに"複数の意味を持たせ、それをそのままにしていることだと私は考えているので、このエントリーではその観点からまとめてみましょう。

ThrottleSecondsは、現在、MT::App::Comments, MT::App::Trackback, MT::App::Searchの3つの標準MTアプリケーションのThrottling機能で利用されています(プラグインから利用することもできますが省略)。以下では、各アプリケーション別にThrottleSecondsの役割と無効化の可否、そしてコメントを述べます。

MT::App::Comments

役割

ThrottleSeconds秒以内の、同一IPアドレスからのコメント投稿をスロットルします。また、(ThrottleSeconds * 10 - 1)秒以内の、同一IPアドレスからの8件以上のコメント投稿をスロットルします。

無効化の可否

ThrottleSecondsに0以下の値を設定すると、スロットリングは実施されません。

妥当な仕様に思えます。

MT::App::Trackback

役割

一時間にOneHourMaxPings個以上のトラックバック受信をスロットルします。また、(ThrottleSeconds * 4000 + 1)秒間にOneDayMaxPings個以上のトラックバック受信をスロットルします。

無効化の可否

ThrottleSecondsを0以下に設定しても、スロットリングは実施されます。

0未満の値を設定すると「未来のある時点以降に受信したトラックバックの個数がOneDayMaxPingsを超えたときにスロットルする」という意味になるので、実質的にOneDayMaxPingsによるスロットリングだけは無効化できます。また、OneHourMaxPings, OneDayMaxPingsの値を極めて大きな値にすることでも実質的に無効化できます。

どちらも「実質的に無効化」できるだけでスロットリング機能をスキップする手段がありません。

そもそもThrottleSecondsの値を使う理由がありません。悪くともThrottleSecondsとは独立の変数で制御すべきですね。

OneDayMaxPingsがその名前が規定する機能を正しく持つべきであるという観点からすれば、24時間以内のOneDayMaxPings個以上のトラックバック受信をスロットルするのが妥当な仕様です。逆に言えば、現状の仕様ではOneDayMaxPingsというディレクティブ名はユーザの誤解を招くだけです。

また、スロットリング機能をスキップする手段が用意されていないのは、コメントのスロットリングと比較すると、対称性に欠けます。

MT::App::Search

役割

(タグ検索を除く)通常検索時に、ThrottleSeconds秒以内の、同一IPアドレスからの検索をスロットルします。

スロットルに用いるアクセス履歴を記録するため、TempDirディレクティブで指定したディレクトリ(デフォルトでは/tmp)にmt-throttle.dbという名前のBerkeleyDBファイルを作ります。

無効化の可否

ThrottleSecondsを0にしてもスロットル機能は有効です。

ThrottleSecondsに0以下の値を設定すると、「実質的に」スロットルが無効になります。

無効化はできませんが仕様自体は妥当に思えます。ただし、コメント投稿のスロットリング機能と同じThrottleSecondsの値を利用する理由もありません。別のディレクティブで指定する仕様であってもよいでしょう。

また、アクセス履歴の格納場所と方法に関しては一考の余地があります。

まず、格納場所について。例えば、レンタルサーバなどでの利用を想定してみるとよいでしょう。複数のユーザが/tmpを共有しており、CGIはsuExecでユーザ権限で実行されるとします。すると、複数のユーザが同一の/tmp/mt-throttle.dbを共有することになります。しかし実際には「最初に」MT::App::Searchを使ったユーザの権限でmt-throttle.dbが作られ、他のユーザは書き込めません。このため、スロットリング機能が有効に使えないという事態が起き得ます。

根本的に格納場所についての周知が不足しています。本来は、TempDirはMovable Typeのインストールベースに対してユニークなディレクトリを指定すべきですが、そうしなかった場合のデメリットが広く知られているようには思えません。

次に格納方法についてですが、Movable TypeのDBではなくて独自のBDBファイルを使う理由が分かりません。BDBを用いた方が単純に速いという観測に基づいているのかもしれませんが、そもそもMT::App::Search自体がDBへのアクセスを必要とする低速な処理であり、履歴管理を少々軽量化できても効果は無視できる程度です。ですから、Movable TypeのDBを使ってもよいはずです。MT::Sessionのように任意のデータを一時的にストアしておく仕組みを利用すれば実装自体は容易でしょう。また、当然ですが上で述べた/tmp/mt-throttle.dbが共有されてしまう問題の抜本的な解決にもなります。

Tags:

Ogawa::Memoranda