• ベストアンサー

FINパケット、RSTパケットが返却される理由?

アパッチのヘルスチェックにて、パケットをみました。 シーケンス番号を追っていきましたが、下記のような 通常ではない動作がありました。 <ケース1> (1)サーバからのHTTPのGETに対して、クライアントがFIN.ACKパケットを返却する。 (2)サーバがFIN.ACKパケットをクライアントに送る。 (3)クライアントからRSTパケットが返却される。 ※RSTパケット内にて、broken tcpとの記載あり <ケース2> (1)サーバからのFIN.ACKパケットに対して、クライアントからRST.ACKパケットが返却される。 ・質問1 それぞれについて、正常な動作とはおもえないのですが、 異常でしょうか? ・質問2 FIN.ACKパケット又はRSTパケットが返却されるのはどんな場合が想定されるのでしょうか? ・質問3 FIN.ACKパケット→RST.ACKパケットは異常な動作でしょうか? よろしくお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • Moryouyou
  • ベストアンサー率41% (140/334)
回答No.1

おつかれさまです。 質問1 ケース1というのはおかしいですね。 サーバからのHTTPのGETというのはありえません。 GETはクライアントから送信されるものです。 言葉のアヤでGETの応答電文がサーバから送信 されている間にFINがクライアンから来るという ことであってもおかしくないと思います。 ケース2のRSTパケットについてもおかしくありません。 よくブラウザ上で通信途中(画面が全部表示されない) で次のページへ移動することなどありますよね。 またサーバもクライアントも、keepaliveという 機能があります。一連のやりとりが終わっても、 次の通信のために一定期間コネクションを保持する 機能です。これは意外とおせっかい機能で時間が たつと勝手にRSTを発行したりします。 質問2 FINは一連の通信が終わった時です。 上述のkeepaliveの機能も一応決まりがあって、 httpヘッダにカウンドダウンする数字があって もうこの通信で終わりですよって1まで来たら FINが発行されます。 またはkeepaliveのtimeout時間が過ぎると RSTが出ます。 他のケースとしては通信不良で再送リトライ オーバとなった場合とか、通信不良で通信の シーケンスが合わなくなった場合とかに RSTが出ることはあります。 質問3 FIN→RST クライアントがFINを出してコネクションを 開放した後に、FINをサーバが返してきたら、もう コネクションはないのでサーバ側も開放してねと RSTを投げるケースはあるでしょうね。 とにかく、 ケース1(1)以外はよくあることです。 クライアント(PCのブラウザだと思いますが...)は 人が操作しているので、ブラウザを×するとか F5キー押すとか、いろんなことをやるでしょう。 WindowsやIEのそのあたりの動きは結構アバウトな 作りであることは確かですが.... いかがでしょう?

関連するQ&A