アクティブクローザーがTIME WAITに入る理由は、最終ACKが失われないことを確認するためであることがわかりました。しかし、最終ACKが失われたかどうかはどのようにしてわかりますか?パッシブクローザーはFINを再送信し、アクティブクローザーはACKが失われたことを認識しますか?TCP FSMの写真を次に示します。
アクティブクローザーがTIME WAITに入る理由は、最終ACKが失われないことを確認するためであることがわかりました。しかし、最終ACKが失われたかどうかはどのようにしてわかりますか?パッシブクローザーはFINを再送信し、アクティブクローザーはACKが失われたことを認識しますか?TCP FSMの写真を次に示します。
回答:
パッシブクローザーはFINを再送信し、アクティブクローザーはACKが失われたことを認識しますか?
はい。TCP接続管理セクションのTCP / IP Illustrated Volume 1からの引用:
- クローズを完了するために、最後のセグメントには最後のFINのACKが含まれています。FINが失われた場合、そのACKが受信されるまで再送信されることに注意してください。
タイムアウトがあります。の場合、タイムアウトが発生LAST_ACK
すると、パッシブクローザーFIN
が失われたと見なして再送します。それが実際に失われた場合、アクティブなクローザーは最終的に再送信されたものFIN
を受信し、に入りTIME_WAIT
ます。場合はFIN
失われなかったが、最終的にはACK
失われた、そして近いアクティブにしているTIME_WAIT
と受け取るFIN
再び。これが発生すると-受信するFIN
とTIME_WAIT
- ACK
が再送信されます。
のタイムアウト値TIME_WAIT
は、再送信には使用されません。にタイムアウトがある場合、パッシブクローザーがパケットを再送信しなかったため、TIME_WAIT
ファイナルACK
が正常に配信されたと見なされFIN
ます。したがって、タイムアウトはTIME_WAIT
、もう一方の端が何も送信しなかった場合、最終的なものを受信しACK
て接続を閉じたためであると安全に想定できる時間だけです。
しかし、最終ACKが失われたかどうかはどのようにしてわかりますか?
タイムアウト期間内に受信しなかったためです。私はそれが「当たり前」の答えであることを知っていますが、それがまさにこれらの状態とタイムアウトが存在する理由です。
パッシブクローザーはFINを再送信しますか
いいえ。そのストリームにさらにパケットが到着しない限り、「RST」(リセット)が送信されることはありません。
ネットワーク障害の可能性があるにもかかわらず、プロセス全体が複雑な状態マシンであり、正常なシャットダウンを実行します。ネットワークが壊れ、リンクにエラーが発生し、リンクが飽和状態になり、パケットをドロップする必要がある、デバイスに障害が発生するなど。演習として、エンドポイントの1つが消えたとき(電源障害など)にアクティブな接続の状態ツリーを実行します
TL; DRその状態ツリーは、考えられるすべての障害モードを処理するように設計されています。
TIME_WAITの目的は、ネットワークが「古い、既存の」接続に属するものとして到着するパケットを新しいものと区別できるようにすることです。推奨事項は、TIME_WAITタイマーを最大セグメント寿命(MSL)の2倍に設定することです。私のシステムではMSLは1分なので、接続はTIME_WAIT状態のまま2分間残ります。
この時間が経過すると、到着したパケットは古い接続に関連付けられなくなります。
TIME_WAITは、ACKパケットの送信を直接待機していません。これは、CLOSE_WAITおよびFIN_WAIT状態によって駆動されます。TIME_WAIT状態になると、ソケットはすでに閉じられています。
参照:http : //www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/ linux-tcpip-tuning /