コネクション数を制限する (IIS)
このエントリ名は変更されました。旧エントリ名は「「接続のタイムアウト」を変更する (IIS)」でした。(2004/03/19 追記)
IISに接続できない事が最近多くなりました。
HTTP 403.9 - アクセスは許可されていません: 多数のユーザーが接続中です。
TCPレベルでの同時接続数が最大で10個までに制限される。1人のユーザーが多数のTCP接続を開始している場合には、それだけで10個のTCP接続がいっぱいになってしまう可能性がある
Windows TIPS -- Knowledge：Professional版に付属するIISの制限
接続されているコネクション数が多いのが原因っぽい。
アクセス数が多くなったか、同じクライアントから沢山のコネクションが張られてるからか？
とりあえず「接続のタイムアウト」を短くしてみました。
「接続のタイムアウト」は、アクティブではない接続を切断するまでにサーバーが待機する時間です。(秒単位)
緩和策としては間違ってはないですよね？
同じクライアントからのコネクション数をサーバ側で制限したかったけど、この方法は分かりませんでした。
HTTP/1.1ならクライアント側が開くコネクション数は「2」もあれば十分なんじゃないですかね？
「インターネット インフォメーション サービス」＞「サイト名(既定の Web サイト)など」右クリック＞「プロパティ」＞「Web サイト」タブ＞「接続のタイムアウト」で設定できます。
60(秒)に変更しました。
デフォルトは900(秒)でした。
「adsutil.vbs」を使うならこんな感じ。
# 現在のConnectionTimeout値を表示 C:\Inetpub\AdminScripts> CScript.exe adsutil.vbs GET /w3svc/ConnectionTimeout ConnectionTimeout : (INTEGER) 900 # 60秒に変更します C:\Inetpub\AdminScripts> CScript.exe adsutil.vbs SET /w3svc/ConnectionTimeout 60 ConnectionTimeout : (INTEGER) 60
もしかしたら、いじらないといけないのは、「/w3svc/サイトの番号/ConnectionTimeout」の方かもしれません。
こっちをいじると、上記「インターネット インフォメーション サービス」の「接続のタイムアウト」の値が変更されます。
■ コネクション数の監視 (2004/03/19 追記)
パフォーマンスモニタで監視してみます。
「Web Service」オブジェクトの「Current Connections」を追加すれば良いと思います。
スケールは「規定値」のままだと見にくいので適当にセットしましょう。
更に、指定したコネクション数を超えたらイベントログ(アプリケーションログ)に記録するようにします。
「パフォーマンスログと警告」＞「警告」から右クリックして「新しい警告の設定」を選択します。
例えば、こんな感じにします。
操作タブ、スケジュールタブもちらりと見ておいてください。
これで、イベントログ(アプリケーションログ)に種類が「情報」として記録されます。
■ クライアント側の接続のタイムアウトの設定の関係
KeepAlive 値は、クライアントとWeb サーバーの小さい方の値が使われるはず。
結果から言うと、IISの「接続のタイムアウト」を 600 から 60 に変更した場合、クライアントがIEの場合は IE のタイムアウトが60秒だから変化ないっぽい。
Firefox はデフォルトのタイムアウトが300秒だから意味ありそう。
●Internet Explorer
・Internet Explorer のデフォルトの Keep-Alive タイムアウト値を変更する方法
http://support.microsoft.com/default.aspx?scid=kb;ja;813827
Internet Explorer のデフォルトの Keep-Alive タイムアウト値は1分のようです。
● Firefox
Firefox 0.8はデフォルトで5分。
ロケーションに「about:config」と入力して「network.http.keep-alive.timeout」の値で設定を変更できます。
(2004/08/18 追記 ここから)
Firefox 0.9.3で「about:config」した時のタイムアウト関係の設定は以下の様になっていました。
network.http.connect.timeout 30 network.http.keep-alive.timeout 300 network.http.request.timeout 120
(2004/08/18 追記 ここまで)
● 確認方法
TCPViewを使って調べました。
- IISの「ConnectionTimeout」を十分大きい値にします。
- TCPViewを起動します。
- ブラウザでWEBサイトにアクセスします。
- IPアドレス、プログラム名などから、プロセスを特定します。
- そのプロセスが「ESTABLISHED」になっている時間を時計で計測 (アナログな方法！)
IISの設定を60秒、Firebirdの設定をデフォルト(300秒)でアクセスすると90秒でコネクションが切れてるっぽい。
60秒で切れる予定なんだけどなぁ・・・。
SEE:
ローカルマシンのオープンポートを調べるツール (このblogより)
こういう時にも使えるんですね。:)
(2004/08/18 追記 ここから)
再度、「接続のタイムアウト」を変更して、TCPコネクションが切れるまでの時間を計ってみました。
| 接続のタイムアウト | IE 6SP1 | Firefox 0.9.3 |
| 10秒 | 60秒位 | 60秒位 |
| 20秒 | 60秒位 | 60秒位 |
| 60秒 | 60秒位 | 90秒位 |
| 120秒 | 60秒位 | 150秒位 |
「IE 6SP1」の場合必ず60秒になってしまいました。
サーバー側の「接続のタイムアウト」を短くしても IE (クライアント側) のデフォルトの60秒が使われてるのかなぁ？
「Firefox 0.9.3」の方はどういう基準だろう？
根本的に考え方が間違えてるのかなぁ？
「HTTP キープアライブ」と「TCPコネクション」とはまったく別物なんだろうか？
だとしたら、恥ずかしい・・・。
→ 金床さんからコメントを頂きました。同じで良いそうです。Thanks。
「HTTP キープアライブを有効にする」のチェックを外すと、「TCPコネクション」が確立してもすぐに切断します。
TCPコネクションのオーバーヘッドが増えるけど、こういう回避策でも良いのかも。
でも、「統合Windows認証」とかは使えなくなるっぽい。「基本認証」も？「基本認証」は大丈夫。
(2004/08/18 追記 ここまで)
■ 「Connection: close」を付けてみる (2004/10/16 追記)(2004/10/17 編集)
「HTTP キープアライブを有効にする」のチェックを外すと「統合Windows認証」が使えなくなるので、チェックをつけたままにしていました。
最近アクセスが多くて、自分が必要なデータを見たい時もアクセスできない事がしばしば有るので、少し考えてみました。
「HTTPヘッダー」タブの「カスタムHTTPヘッダー」に「Connection: close」を追加します。
とりあえずこれでレスポンスに「Connection: close」を常に(強引に！)追加して返すので、コネクションをすぐに切断するはず。
「HTTP キープアライブを有効にする」のチェックを外すと、「統合Windows認証」 (Basic認証も？Basic認証は出来ました) が出来なくなったけど、この方法だと大丈夫っぽい。
時々、「Connection: close」をレスポンスで返していても、暫く接続しっぱなしになってる人がいるみたいです。
そうなってしまう条件がいまいち分かりません。
「Connection: close」が返った時の動作は、クライアント側の実装によるんでしょうか？(よりそう)
ちょっと見ていたら、UAは
- Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1)
- Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1)+Opera+7.53++[ja]
- Mozilla/4.0+compatible;+MSIE+6.0;+Windows+NT+5.1)+Opera+7.11++[ja]
- Opera/7.52+(Windows+NT+5.0;+U)++[ja]
- RssBar/1.02
- VVmgjaykeeaapmVsspytyyutouswxoairhh6qh (なんじゃ？こりゃ？)
などなど。
UAは簡単に書きかえられちゃうからあまりあてにはなりませんが・・・。
純粋に転送に時間がかかってコネクションしっぱなしのものも含まれてるかも？？
沢山の人が来て403になってるんじゃなくて、一人の人が沢山のコネクションを張って403になってる気がします。
IISへの同じIPアドレスからの接続数を制限するISAPIなり、外部プログラムがあると良いのかなぁ？
AOLとかDoCoMoなど複数のプロキシー経由で接続してくるプロバイダもあるのであまり意味ないかな？
IISへ一定時間以上接続しっぱなしになってるTCPコネクションを強制的に切断する外部プログラムでもいいかも？(擬似タイムアウト？)
持続的接続にならないので、オーバーヘッドは増えるけど、「Connection: close」の方法でちょっと様子見。
閲覧、書き込み、その他に不都合があったら教えてください。
・ハイパーテキスト転送プロトコル -- HTTP/1.1 (RFC2616)
http://www.studyinghttp.net/rfc_ja/rfc2616.ja.xhtml.gz
なんとなく見てた場所。
■ パケットの流れを追ってみた (2004/10/17 追記)
「HTTP キープアライブを有効にする」のチェックを外した場合と、「Connection: close」を追加した場合 (キープアライブは有効)で、パケットの流れを追ってみました。
Windows統合認証アクセスのリクエストを一回送ります。
必要なパケットを省略して書いちゃってるかもしれないけど、こういう感じだと思います。
Where:
→ : クライアントからサーバー
← : サーバーからクライアント
⇔ : 相互
あれ？「FIN」って、3ハンドシェイクみたいに、相互に送り合わなくて良いんだ？
接続は確認したいけど、切断はどうでもいいって事かなぁ？
●「HTTP キープアライブを有効にする」のチェックを外した場合 (IE 6 SP1)
⇔TCPネゴ
→HTTPリクエスト(GET)
←HTTPレスポンス(401 Access Denied) (Connection: close付き)
←FIN (*1)
→FIN
⇔TCPネゴ
→HTTPリクエスト(GET) (NTLMSSP_NEGOTIATE)
←HTTPレスポンス(401 Access Denied) (NTLMSSP_CHALLENGE) (Connection: close付き)
←FIN (*1)
→HTTPリクエスト(GET) (NTLMSSP_AUTH)
→FIN
なんでリクエスト送ってるくせにFINするの？
2回目のHTTPレスポンスに付いてた「Connection: close」の作用？
FINがちゃんといた・・
←RST (*2)
←RST (*2)
(*1) あああ、送ってた。。追記
(*2) RSTが居たので追加
で、「サーバーが見つからないか、DNS エラーです。」のエラーが出て、繋がらない。
●「Connection: close」を追加した場合 (キープアライブは有効) (IE 6 SP1)
⇔TCPネゴ →HTTPリクエスト(GET) ←HTTPレスポンス(401 Access Denied) (Connection: close付き) ←FIN (*3) →FIN ⇔TCPネゴ →HTTPリクエスト(GET) (NTLMSSP_NEGOTIATE) ←HTTPレスポンス(401 Access Denied) (NTLMSSP_CHALLENGE) (Connection: closeなし) →HTTPリクエスト(GET) (NTLMSSP_AUTH) ←HTTPレスポンス(200 OK) (Connection: close付き) →FIN ←FIN
(*3)2004/10/18にやったら付いてたので追加
となって、接続できます。
カスタムヘッダで毎回「Connection: close」を送れって言ってるのに送ってないんだよなぁ。
(それだから上手く接続できたんだけど)
トラックバック(1)
このブログ記事を参照しているブログ一覧: コネクション数を制限する (IIS)
このブログ記事に対するトラックバックURL: http://kinshachi.ddo.jp/mt/mt-tb.cgi/223
IIS 5.1の同時接続数を細工したいの続きエラーメッセージのレスポンスを使ってみる同時接続数10を超えるとエラーメッセージが返ってくるので、エラーメッセージがもとのコンテンツを参照して表示するようにすればいいんじゃないかなと考え、あーだこーだしてみた。ます、... 続きを読む
はじめまして。IISの設定は経験がないのですが…
＞「HTTP キープアライブ」と「TCPコネクション」とはまったく別物なんだろうか？
同じものです。間違ってませんよ。
根本的に、同時に許可される接続数があまりにも少ないように思えます。
サーバー側のタイムアウトの値を5〜10秒ほどの短い時間にしてしまうというのも有効だと思います（ただ、この場合HTTPSでサービスを提供していると古いIEとの相性が悪くなる場合がありますけれども）。
金床さん。
はじめまして。
>＞「HTTP キープアライブ」と「TCPコネクション」とはまったく別物なんだろうか？
>同じものです。間違ってませんよ。
それが分かって安心しました。 :)
>根本的に、同時に許可される接続数があまりにも少ないように思えます。
えぇ、そうなんですよ・・・。
使用ソフトの関係上クリアできないんです・・・。
(ランレベル3でも良いので)Linuxがさくさく走るノートPCが手に入ればそっちに移行したいなぁと思うんですがー。(おねだり(違))
デスクトップは、音と消費電力が・・・。
>サーバー側のタイムアウトの値を5〜10秒ほどの短い時間にしてしまうというのも有効だと思います
本文に書いてあるように、サーバー側のタイムアウト値を小さくしても(10秒とか)、TCPコネクションが切れるまで60秒かかってしまうんです。
何でか分からないでいます。
本文の「「Connection: close」を付けてみる」の項目をちょっと編集しましたー。
大変参考になりました。
ありがとうございます。
>使用ソフトの関係上クリアできないんです・・・
なるほど。
>本文に書いてあるように、サーバー側のタイムアウト値を小さくしても(10秒とか)、TCPコネクションが切れるまで60秒かかってしまうんです。
あらら、そうでしたか。これではどうしようもないですよね。IISがおかしいですね（笑）。
ところで余談ですが、TCPコネクションがいつ切断されているのかを観察するには、tcpdumpやEtherealなどでリアルタイムでパケットを眺めるのが一番分かりやすいと思ってます。
それぞれのパケットのタイムスタンプも記録されるので、後からのんびり時間（何秒で切断されたか）を計算することもできますし。
>「Connection: close」が返った時の動作は、クライアント側の実装によるんでしょうか？(よりそう)
クライアント側の実装によりますね。
普通、Connection: closeがサーバーからクライアントへ送られる場合、サーバー側からTCP接続の切断が行われます。
しかしikeさんの現在のファンキーな設定（笑）だと、サーバーがConnection: closeを宣言しているにもかかわらずTCP接続を切断しないという、ある種特別な状況になっているわけです。
このような状況を想定して作成されているHTTPクライアントはあまり無いでしょうから、それぞれによって動作に差が出てきているのだと思います。
さらに別件ですが、持続接続の有無と「統合Windows認証（というのが何なのか知らないのですが）」という機能に相関関係が存在すること自体もおかしいですよね。マイクロソフトのやることは良く分からない…。Basic認証についても、本来持続接続との関連性は無いはずですので、持続接続の設定によって出来たり出来なくなったりするようだと、やはりIISの実装がおかしいということになると思います。
金床さん。
丁寧な返事ありがとうございます。
長文になってしまいました。
>ところで余談ですが、TCPコネクションがいつ切断されているのかを観察するには、tcpdumpやEtherealなどでリアルタイムでパケットを眺めるのが一番分かりやすいと思ってます。
なるほど、なるほど。
SYNとFINのパケットを見るという事でいいかしら？
Etherealなら「適当なパケットを右クリック」＞「Follow TCP Stream」して最初と最後を見る方がいいかな？
EtherealのTimeに表示される数字は最初のパケット送受信からの秒数なのかな？(調べてないんです・・・)
>しかしikeさんの現在のファンキーな設定（笑）だと、
はい、ファンキーなのは自覚しております(^^;)
どうにも出来なくて、苦肉の策なもので。。。
>サーバーがConnection: closeを宣言しているにもかかわらずTCP接続を切断しないという、ある種特別な状況になっているわけです。
うぅーん。
個人的には、(表示や書き込みが出来ない、人様に迷惑かける、悪さされる、リソースを食いつぶすなどの) 悪影響がなかったら、規格外でも良いかなぁとか、甘く考えてます。(^^;)
良いのか？＞自分
まぁ、仕事サーバーじゃないですし。
大丈夫かなぁ。。
>持続接続の有無と「統合Windows認証（というのが何なのか知らないのですが）」という機能に相関関係が存在すること自体もおかしいですよね。
「統合Windows認証」はIISのチャレンジ&レスポンス方式の認証と私は認識しています。(違うかも？)
「チャレンジ値を受け取る時と、レスポンスを返す時で同じTCPセッションじゃないといけないのかな」と漠然と予想してました。
パケットを拾ってみたら、そういうわけでもないみたい？
レスポンスを返すHTTPリクエストの直後にTCPコネクションをぶち切ってました。
必要そうな場所だけ抜き出して本文に追記してみたので(「パケットの流れを追ってみた」の項目)、興味があったら見てください。
私的には「なんか変なのー」って感じです。
>Basic認証についても、本来持続接続との関連性は無いはずですので
すいません。よく調べずに本文を書いてしまいました・・・。
Basic認証は、持続接続と関係なく(「HTTP キープアライブを有効にする」のチェックを外しても)接続できました。
本文を修正しておきます。
Basic認証は HTTP 1.0 時代からあったでしょうから(よく知りませんが)、持続接続なしにして動かなかったら困りますよねー、きっと。
>やはりIISの実装がおかしいということになると思います。
私の設定方法や確認方法が間違ってない事を祈ります。 (^_^;)
お、リンクは、「Guardian@JUMPERZ.NET」ですね。
中の人ですか？
・ユーザーズマニュアル日本語版 (Guardian@JUMPERZ.NET)
http://www.jumperz.net/guardian_manual/ja/body.html
日本語マニュアルもありますねー。
今度(いつか？)ゆっくり見ようと思ってたんですよー。
長文失礼しました。
>あれ？「FIN」って、3ハンドシェイクみたいに、相互に送り合わなくて良いんだ？
>接続は確認したいけど、切断はどうでもいいって事かなぁ？
ご指摘通り、普通はFIN-ACKが相互に送られます。片方からのFIN-ACKだけで返事がないのは異常ですね。
RSTで切断する場合には返事はないのが普通だと思います。
>なんでリクエスト送ってるくせにFINするの？
全くですね（笑。
>2回目のHTTPレスポンスに付いてた「Connection: close」の作用？
おそらくそうだと思います。
以前の書き込みで「IISが悪い」と書いたことがありますが、IEが悪い部分もありそうですね。
IEの設定で、HTTP/1.1を使わないようにしてみて試してみるのも面白そうです。
また、IEのこのような細かいバグは内緒で修正されていたりすることもあるので、パッチを当てると直ったり（挙動が変わったり）することもあります。VMWareなどで複数のIE環境を作ることができるようであれば、パッチを当てたIEでテストしてみるのもおすすめです。
#Windows統合認証っていうくらいだから、OperaやMozilla、Netscapeなんかではテストできないんですよね？
>SYNとFINのパケットを見るという事でいいかしら？
HTTPのやりとりが終わった後、接続しっぱなしの時間がどの程度になるのかを知りたい、というのが目的だとすると、HTTPの通信の最後のパケット（PUSHとかACKとか立ってるかな？）からFIN-ACKもしくはRSTまでの時間を見ると良いと思います。以前同じような実験を色々やったときに、このような方法で時間を求めると分かりやすいなぁと思いました。
>Etherealなら（略）
私はtcpdumpの方を使っていたのでちょっと今すぐには分かりません、すみませんです。
>個人的には、(表示や書き込みが出来ない、人様に迷惑かける、悪さされる、リソースを食いつぶすなどの) 悪影響がなかったら、規格外でも良いかなぁとか、甘く考えてます。(^^;)
そのような意見には賛成です（笑）。たまに「けしからん！」っていう人もいますけど、私も「動けばOK」派です。
>Basic認証は HTTP 1.0 時代からあったでしょうから(よく知りませんが)、持続接続なしにして動かなかったら困りますよねー、きっと。
なるほどその通りですね。
しかし基本的に、持続接続とその他のHTTPの色々な仕組みには関連性はないと思います（あるとなると、仕組みが全体がとても複雑になってしまうはず）ので、やはりIEかIISの実装がおかしいのではないかと思います。
>お、リンクは、「Guardian@JUMPERZ.NET」ですね。
>中の人ですか？
中の人です（笑）
Guardian@JUMPERZ.NETは先日専用サイトを立ち上げました。
http://guardian.jumperz.net/index.html
日本語版マニュアルは
http://guardian.jumperz.net/manual/ja/body.html
にあります。
お試し頂ければとてもありがたいです。
金床さん。
うわぁーあ。もう一回やったら、FINがちゃんと居ました。
Etherealの「Info」の項目が「Continuation」ってなっててFlagsが書かれてなかったから見落としました(言い訳)。
とすると、そんなにおかしい動作じゃないのかもなぁ・・・。(混乱中)
面白みのない結論になってしまいました？
ううぅ。
本文を書き換えてるので、コメントとかみ合わなくなってきてますね(^^;)
>#Windows統合認証っていうくらいだから、OperaやMozilla、Netscapeなんかではテストできないんですよね？
Mozillaはv1.4位から対応してるみたいです。
http://www.mozilla-japan.org/releases/mozilla1.4/README.html
「NTLM 認証」とか「Windows 統合セキュリティ」とか言ってる部分がそれだと思ってます。
Operaは未確認ですー。
ちなみに、HTTP キープアライブを無効にしてFirefoxで統合 Windows 認証へアクセスすると、繋ぎに行って切断されてを繰り返して、いつまでも終わりません。
おお、本当に中の人だったんですねぇー。
そして、「ハッキングツール・プログラム大全」な方だったんですねー。見つけちゃった:-)。
道理で詳しいはずですー。
>Etherealの「Info」の項目が「Continuation」ってなっててFlagsが書かれてなかったから見落としました
Etherealは親切すぎて、実際に起きている現象が分かりにくくなってしまう場合がありますね。
>Mozillaはv1.4位から対応してるみたいです。
おぉ、すごいなMozilla。なるほど、確認ありがとうございます。
>ちなみに、HTTP キープアライブを無効にしてFirefoxで統合 Windows 認証へアクセスすると、繋ぎに行って切断されてを繰り返して、いつまでも終わりません。
あららら…（笑
僕はIIS環境が無いので検証できないのが残念ですが、NTLM認証は癖がありそうな感じですね。
>そして、「ハッキングツール・プログラム大全」な方だったんですねー。見つけちゃった:-)。
ぁぃゃー
見つかってるし（笑
>道理で詳しいはずですー。
いえいえ、まだまだです。
金床さん。
「Guardian@JUMPERZ.NET」使ってみましたー。
ていうか、「Guardian@JUMPERZ.NET」はサイト名？アプリ名？その両方ですか？
新しいエントリーに書いたので、興味があったら、見てくださいー。