Internet Information Server (IIS) で接続のタイムアウト時間経過後、切断対象のアイドル セッションに対して TCP の RST パケットが送信されない場合がある

適用対象: Windows Server 2008 R2 StandardWindows Server 2008 R2 DatacenterWindows Server 2008 R2 Enterprise

現象


Internet Information Server (IIS) で [接続のタイムアウト] 秒 (既定では 120 秒) を経過後、以下のすべての条件を満たした場合、切断対象のアイドル セッションに対して、TCP の RST パケットが送信されません。

接続のタイムアウト時間の経過後、IIS ではセッションはクローズされますが、クライアント側ではセッションが残った状態になります。その後、クライアントが残存したセッションを使用して通信を試みると、正常に接続できずエラーが発生する場合があります。

現象が発生する条件 :
  • タイマーを管理する http.sys ドライバが 5 秒間隔で実行するアイドル状態のコネクションの切断時に、切断対象のアイドルコネクションが複数存在する場合
  • 切断対象の複数コネクションへの IIS サーバーから見た Next-Hop IP アドレスが同一である場合 (デフォルト ゲートウェイ経由の通信など)
  • RST パケット送信時に Next-Hop IP アドレスへの ARP 解決が実行される場合

原因


IIS では、クライアントが接続後に [接続のタイムアウト] の時間を経過すると、クライアントに TCP の RST パケットを送信し、セッションをクローズします。

IIS で、タイムアウト時のように連続したパケットを送信する場合、ARP 解決実行時には UDP や TCP に関わらず、パケット ドロップが発生します。ただし、TCP の場合、RST パケット以外はリトライ処理がされるため通常問題は顕在化しません。この動作は、"ARP が少なくとも 1 つのパケットを保持しなければならない" と規定した RFC 1122 の 2.3.2.2 ARP Packet Queue に準拠したものです。その結果、複数の RST パケットのうち、最後の RST パケットのみがバッファに保持されて正常に送信され、それ以外の RST パケットはドロップします。

回避策


この現象を回避するには、以下の 3 つのいずれかの方法を実行してください。

方法 1 : ARP エントリを静的登録する

IIS サーバーが指定しているデフォルト ゲートウェイなど、クライアントへ通信する場合の Next-Hop IP アドレスに対して ARP エントリを静的登録します。IIS で ARP エントリを静的登録することで、RST 送信時の ARP 解決を抑止します。



Windows Server 2008 以降でのコマンド設定例 :

netsh interface ipv4 add neighbor "NIC名" 1.1.1.1 00-00-00-00-00-01

Windows Server 2003 でのコマンド設定例 :

arp -s 1.1.1.1 00-00-00-00-00-01

注 : arp コマンドでの静的登録は OS の再起動により削除されます。OS の 起動時に実行するタスクなどでコマンドの実行を登録しておくなどの対処が必要です。

方法 2 : クライアント側のタイムアウト値を短縮する

IIS 側の [接続のタイムアウト] 時間より、クライアント側のタイムアウト時間を短く設定します。クライアント側のタイムアウト時間を短くすることでクライアント側から先にセッションが終了されます。


方法 3 : HTTP キープアライブを無効化する

IIS 側で、HTTP キープアライブ (HTTP Keep Alive) を無効化します。無効化することでクライアント接続後のセッションが維持されなくなります。



HTTP キープアライブの無効化の方法については、次のマイクロソフト Web サイトを参照してください。



HTTP キープアライブを有効にする
http://technet.microsoft.com/ja-jp/library/cc780771(WS.10).aspx
IIS 7.0: HTTP Keep-Alive 応答ヘッダーを有効にする
http://technet.microsoft.com/ja-jp/library/cc772183(WS.10).aspx