- ベストアンサー
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パケットは異常な動作でしょうか? よろしくお願いします。
- みんなの回答 (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のそのあたりの動きは結構アバウトな 作りであることは確かですが.... いかがでしょう?