2つのホスト（A & B）間でTCP接続が確立されていて、ホストAがホストBに5オクテットを送信し、ホストBがクラッシュしたとします（原因不明のため）。 ホストAは肯定応答を待つが、それを取得しないと、オクテットを再送し、送信者ウィンドウのサイズも小さくする。 これは、パケット損失のためにウィンドウサイズがゼロになるまで数回繰り返します。私の質問は、次に何が起こるかです。マシンの1つが停止した場合、TCP接続はどのように終了しますか？
この場合、TCPは最終的にackを待ってタイムアウトし、アプリケーションにエラーを返します。アプリケーションは、そのエラーについて知るためにTCPソケットからread/recvする必要があります。その後のwrite/send呼び出しも失敗します。 TCPが接続がなくなったと判断するまで、書き込み/送信呼び出しは失敗しません。ソケットバッファがいっぱいであれば、アプリケーションやブロックから見て成功するでしょう。
ホストBがACKを送信した後にホストBが消滅した場合、ホストAは何かをBに送信するまでそのことを知りません。結果的にタイムアウトになるか、ICMPエラーになります。 （通常、最初の書き込み/送信コールは失敗しません。なぜなら、TCPは接続にすぐに失敗しないため、書き込み/送信コールは完了するまでACKを待たないということです）。
再送信によってウィンドウサイズが縮小されないことにも注意してください。
このlink
が今私の見解では、あなたの質問に非常に単純な答えは、接続がタイムアウトされていると閉鎖されるに従ってください。別の可能性としては、応答の遅いマシンのためにICMPエラーが発生する可能性があります。
また、クラッシュしたマシンが再びオンラインになっている場合は、上記で貼り付けたリンクiで説明した手順が実行されます。
OSの実装によって異なります。つまり、ACKを待ち、タイムアウトするまでパケットを再送します。その後、接続が切断されます。 Linuxで何が起こるかを正確に見るためには、hereの他のOSも同様のアルゴリズムに従ってください。
あなたのケースでは、残存ノードによってFINが生成され、最終的に接続はCLOSED状態に移行します。宛先IPアドレスでnetstat出力をgrepingし続けると、ESTABLISHED状態からTIMED_WAITへの移行を監視し、最後に消滅します。
あなたのケースでは、TCPは送信したパケットのACKを取得するタイマーを保持しているため、このようなことが起こります。このタイマーは十分に長くないので、検出はかなり早く行われます。
しかし、マシンAがACKを取得した後にAが何も送信しない場合、上記のタイマーは同じイベントを検出できませんが、別のタイマー（アイドルタイムアウトを呼び出す）がその条件を検出し、接続が終了します。このタイムアウト期間は、デフォルトでは高く設定されています。しかし、通常これはそうではありません。マシンAは間に物事を送信しようとし、送信パスのエラー状態を検出します。
要するに、TCPは、1つのケース（アイドルタイムアウト：デフォルトでは非常に高い）を除いて、接続自体を閉じて（アプリケーションに知らせるのに十分なほど）スマートです。通常のケースで
cforfun
、各側は、FIN（仕上げ）ビットが設定された特別なメッセージを送信することによって、接続の終わりに終了します。 このFINを受信したデバイスは、受信したことを示すFINに対する確認応答を返します。 FINを送信して肯定応答を受信することによって、両方のデバイスがシャットダウン手順を完了するまで、接続全体が終了したとはみなされません。
これはsyn floodingですか？ –