TCP ウェーブ 4 回
4 つのウェーブの導入
まず、データ送信が完了すると、クライアント A とサーバー B の両方が ESTABLISHED 状態になり、通信中の両方の当事者が同時に接続を解放したり、接続を閉じたりできることがわかります。ただし、より一般的な状況は、クライアントがシャットダウン要求を開始する場合です。
最初のウェーブ: 図では、クライアント A が初めてウェーブを行い、キー ビットを含む長さ 1 のメッセージをサーバーに送信します。 FIN が含まれています。1 に設定すると、終了を意味し、接続の解放を要求します。開始バイト シーケンス番号 seq は u です。ここでの seq はサーバー側の seq とは異なることに注意してください。そして、A は ESTABLISHED 状態から FIN-WAIT-1 (終了状態 1) に入ります。
第 2 の波: A のメッセージを閉じるリクエストを受信した後、サーバー B は反応し、A からメッセージを閉じるリクエストを受信したことを確認します。ここでの ACK 確認は 1 で、対応する確認番号 u+1 が有効になり、それ自体の開始バイト シーケンス番号 seq は v になり、B は ESTABLISHED 状態から CLOSE-WAIT (クローズ待ち) 状態に入り、A は確認を受け取ります。 from B メッセージ後、FIN-WAIT-1(終了状態1)からFIN-WAIT-2(終了状態2)に変化します。この時点では、TCP 接続はまだ 半クローズ 状態です。つまり、B は A にデータを送信でき、A は受信を希望しています。しかし、A は B にデータを送信できません。
第 3 の波: 前述したように、TCP は第 2 の波の後もまだセミクローズ状態にあるため、サーバー B がセミクローズ状態であることを確認するまで待ちます。送信前にデータがありません。その後、3 回目のウェーブが行われます。キー フィールド FIN=1 は接続を解放する要求を表し、ACK=1 および ack=u+1 は、最初に受信したウェーブでクライアントによって送信された開始バイトを表します。レスポンスのシリアルナンバーです。そして、このマシンの開始バイト シーケンス番号は v+1 ではなく w です。これは、サーバー B が 2 番目のウェーブと 3 番目のウェーブの間にメッセージを A に送信した可能性があり、バイト シーケンス番号の一部が使い果たされているためです。途中でデータが送信されない場合、各メッセージの長さは 1 バイトであるため、w=v+1 となります。次に、B は CLOSE-WAIT (クローズ待ち) 状態から LAST-ACK 状態に変わります。クライアントが B の第 3 ウェーブ メッセージを受信すると、状態は FIN-WAIT-2 (終了状態 2) から TIME-WAIT (時間待ち状態) に変わります。
第 4 ウェーブ: クライアント A が第 3 ウェーブ メッセージを受信すると、すぐにサーバー B に第 4 ウェーブを送信します。メッセージの内容は実際には同じです。 2 番目の波として、メッセージの受信を確認し、対応する正しい確認番号 (このマシンのメッセージの開始バイト シーケンス番号) を与えます。その後、サーバー B が 4 番目のウェーブ メッセージを受信してクローズ状態になり、2MSL を待った後、クライアント A もクローズ状態になります。
4 番目のウェーブの後、クライアントが接続を解放するまでに 2MSL 待たなければならないのはなぜですか?
2MSL は、メッセージ セグメントの最大存続期間、つまりメッセージ セグメントが TCP 接続内で存続できる最大時間の 2 倍です。
MSL (最大セグメント寿命)
確認メッセージ (第 4 ウェーブ) + 要求メッセージ (第 3 ウェーブ) )
説明:
クライアントは ACK=1 メッセージを送信した後、2MSL タイマーの維持を開始します。クライアントは最後に ACK=1 を送信して、サーバーの終了の受信を確認するとします。接続メッセージ。ネットワークでスタックし、サーバーに到達していません。サーバーはクライアントから一定期間 ACK=1 応答を受信していないため、3 回目のウェーブに対して接続解放メッセージを再送信します。このメッセージを受信したクライアントは、2MSL タイマーをリセットし、再度 ACK=1 メッセージをサーバーに送信します。2MSL タイマーが期限切れになるまでにサーバーから再送信された接続解放メッセージを受信しない場合、クライアントは TCP 接続を解放します。
クライアントがこの時点で TCP 接続を解放しており、2MSL を待っていない場合、サーバーによって再送信された接続解放メッセージを受信できません。再送信されたメッセージは、対応する接続を見つけることができません。クライアントがサーバーに TCP 接続要求を送信した場合、もう一度言いますが、この時点では 2 つの接続のポート番号が異なるという保証はありません。その場合、前の接続の一部のデータがネットワーク内で滞り、確立後にこれらの遅延データがクライアントに到達するという問題が発生する可能性があります。古い接続と新しい接続の違いにより、ポート番号と IP が同じ場合、TCP プロトコルは遅延データが新しい接続に属するものとみなして、新しい接続はダーティ データを受信することになります。データパケットの混乱を引き起こします。
なぜ 4 回手を振る必要があるのに、3 回手を振るとうまくいかないのでしょうか?
TCP 接続は全二重通信、つまりクライアントとサーバーの両方がデータを送受信できるため、切断する際にはサーバーとクライアントの両方が相手が送信しなくなったことを確認する必要があります。データ。
説明:
最初のウェーブでは、クライアントがサーバーに送信し、サーバーはクライアントがデータを送信しなくなることを学習します。
2 回目の Wave、サーバーはクライアントに送信します。クライアントは、クライアントがデータを送信しなくなることをサーバーがすでに知っていることを学習します。
3 回目の Wave、サーバーは送信します。
第 4 の波では、クライアントはデータをサーバーに送信し、サーバーは、サーバーがデータを送信しないことをクライアントがすでに知っていることを知ります。データは送信されなくなりました
1 回目と 2 回目 ウェーブするとき、サーバーはまだクライアントにデータを送信している可能性があるため、2 回目のウェーブと 3 回目のウェーブをマージすることはできません。
接続は確立されているが、クライアントが失敗した場合はどうなるでしょうか?
ハートビート メカニズムを使用して生存を維持する
説明: サーバーはタイマーを維持します。サーバーはクライアントからリクエストを受信するたびに、タイマーをリセットします。クライアントが受信されない場合は、タイマーがリセットされます。一定時間経過後、サーバーはクライアントにプローブメッセージを一定間隔で送信しますが、一定数のプローブメッセージを連続して送信しても応答がない場合、サーバーはクライアントに障害があると判断し、接続を切断します。
参考ブログ: https://blog.csdn.net/qq_37348221/article/details/114572978
参考書籍: 『コンピュータ ネットワーク (第 7 版)』謝西仁