mod_dosdetectorの反応への反応 - stanaka's blog
先日(id:stanaka:20070204)、公開したmod_dosdetectorですが、ブクマ数が300users越えと予想以上の反響でした。その中で、いくつかFAQ的な反応があったので、それらに対する回答です。 mod_limitipconnでもできるんじゃないの？ mod_limitipconnは、同時接続数を制限して、越えた場合は、接続拒否をするというモジュールです。mod_dosdetectorは、DoS判定したクライアントのみを対象とした制御が可能です。この手の定量的なアクセス制御モジュールは、これまでにいくつか開発されているのですが、ほとんどのモジュールが単純にアクセス拒否するだけ、というのも、mod_dosdetectorの開発動機の一つです。 パフォーマンスは？ 確かに余分な処理が必要となっているため、CPU負荷は増えています。しかし、はてなのサーバ構成では、リバース
サーバにDoS耐性を付ける - stanaka's blog
ウェブサービスでは、アクセスが集中して、サイトが落ちる、というのは、よくある話です。純粋に人気が出てアクセス集中するなら、サーバ管理側の責任と言われても、しかたないと思います。しかし、botやF5アタックによる突発的な集中アクセスで、落ちてしまう、というのは、運営側としても、あまり納得がいくものではありません。 そのような突発的なアクセスに対応するために、大量のアクセスをしてくるクライアントを検出し、優先度を落すか、アクセス禁止にする方法などがあります。 というわけで、Apacheモジュールでそれを検出するためのmod_dosdetectorを開発しました。(ちなみにコア部分の開発期間は、Apacheモジュールって、どう書くんだっけ、という状態から、3日でした。) mod_dosdetectorは、Apacheモジュールとして動作し、クライアントのIPアドレスごとにアクセス頻度を測定し、設
[ThinkIT] 第5回：サーバの追加とロードバランシング (1/2)
さて、サービスがオープンしてしばらく経ってくるとトラフィックも増えて、アプリケーションサーバーの負荷が高くなってくることでしょう。そこで、アプリケーションサーバーを増やすことになります。同じ構成のアプリケーションサーバーをもう一台作って対応します。 ここでふと気づくわけですが、Webサーバーがproxy×1＋mod_perl×1の場合は、クライアントから受け付けたリクエストを振り分けて処理するといったことは意識する必要がありませんでした。 しかし、proxy×1＋mod_perl×2になると、リクエストを受け取ったリバースproxy側では、どちらのアプリケーションサーバーにリクエストを転送するかを考慮する、つまりロードバランシングをする必要が出てきます。 結論から言うと、ロードバランシングもリバースproxyでやってしまうことができます。 Apache 2.2にはmod_proxy_bal
[ThinkIT] 第4回：Backend Evolution（後編） (1/2)
前回は「リバースproxyとは」と「Webサーバーのメモリ使用率」について解説しました。今回は前回の続きとして、「HTTPのKeepAlive」と「リバースproxyの構築」について解説していきます。 話は変わって、KeepAliveです。 1つのWebページをブラウザーが表示するにあたっては、htmlに加えてページ中に配置された複数の画像やスクリプトファイル、つまり複数のドキュメントをサーバーからダウンロードする必要があります。 この複数のリクエストを取得するのに、サーバーとクライアントの間で複数のコネクションを張ってやりとりするのは効率が良くありません。 サーバー側でKeepAlive設定が有効になっている場合、クライアントは、1つ目のドキュメントのダウンロードが完了したあとも接続を維持します。これにより必要なコンテンツを1つのコネクションで取得できるようになり、クライアントから見ても
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mod_dosdetector
