攻撃中でもコンテンツ(DBアクセス)は正常に動作していたのですが、
IISのログには、１万７千(HTTP200ステータス)しか記録されていませんでした。
残りのリクエストはどこに消えたのでしょうか？
考えられる事を教えてください。
条件
LAN外からの発射です。
各ページはキャッシュに残さないような作りをしています。ルータ(RT-200KI)のログが見れない？のでルータまで到達したのか、フィルタリングしたのか不明です。
No.3
761
28
36pt
プロバイダーにより帯域制限がかけられたのでは？
http://www.nikkeibp.co.jp/sj/special/92/06.html
http://www.nikkeibp.co.jp/sj/special/92/06.html
HTTP GET Flood攻撃は、TCPセッションのみを大量に確立させるだけでなく、セッション確立後に大量のHTTP GET要求を送信し、サーバーに対して高負荷をかけることでサービス不能状態へと陥れる攻撃だ。一番シンプルな攻撃としては、クライアントPCのブラウザーでリロード操作を大量に行い（通常、F5キーにリロードが割り当てられているので、F5キーを何度も押下する）、手動ながらHTTP GETを大量に要求する「F5アタック」、そしてツールを使ったもので代表的なものといえば「田代砲」がある。…HTTP GET Flood攻撃を抑制するためには、サーバーの性能限界を凌駕（りょうが）する規模のGET Flood攻撃に対して、一定時間内のパケット数で制限をかけるなどの「帯域制御」を行い、ある程度の規模のGET Flood攻撃にも耐えられるようにサーバーのチューニングを行うのも一つの方法である。
余談：
例のタイムズ紙サイトへの田代砲によるリクエストが思わぬ実効をあげた後、超田代砲、拡散田代砲といったより強力なスクリプトの流出や田代砲抑止としてそれぞれが思い思いに自サイトに砲台を実装といったことが生じたため、当然プロバイダー各社もパケット数の監視や抑制に積極的に乗り出さざるを得ないのでしょう…
＞帯域制限・・・
帯域制限があると噂されるプロバイダなので、ありえるかと思います。
ただ、「攻撃中でもアプリが正常に動作する」というのはどう説明できるのでしょうか。
補足ですが、LAN外から発射し、同LAN(砲配置しているLAN)からアプリの動作確認をしました。
また、私は「２５万リクエストを発射」と記述したのですが、砲のカウンタを見てそう思ったのですが、
そもそも１万７千しか発射できていなかったのではないかとも感じてきました。
（スクリプトでロケーションをセットするものの、ブラウザが追いついていかない？とか）
No.4
260
18pt
RT-200KIのパケット処理能力を超えたため
パケットが廃棄された。
もしくはサーバ側で処理しきれない。
切り分けのためルータを咬ませないで
直接、宅サバとクライアントをつないで切り分けを
してみてはどうでしょうか。
これで改善されればルータ
されなければ宅サバがボトルネックですかね。
＞ルータでパケットが廃棄された。
「攻撃中でもアプリが正常に動作する」というのはどう説明できるのでしょうか。
しつこく動作確認したのですが、エラーとなるようなことはありませんでした。
パケットが適度に破棄されたならば、たまにはエラーになっても良い気がするのですが・・・。
＞もしくはサーバ側で処理しきれない。
サーバのログにも、アプリのログにも消失分は残っていません。
処理しきれないのであれば、幾つかの件数でも２００以外のログが残っても良いような気がするんですよね。
コンピュータカテゴリ、ネタ・ジョークカテゴリで１位まで上り詰めてしまい、ビックリしました。
今度、機会がありましたら、違う田代砲とかで、発射間隔を広げて、試してみたいとおもいます。
回答しい頂いた皆様、ありがとうございました。
| 回答者 | 回答 | 受取 | ベストアンサー | 回答時間 | |
|---|---|---|---|---|---|
| 1 |  ekusutasii |
224回 | 142回 | 0回 | 2006-05-19 02:21:41 |
5
2
2
1
1
54
51
当砲では宅サバすら落とせないのでしょうか