この記事は、Huawei クラウド コミュニティ「TCP 接続切断の復号化: 4 つの波の秘密とデータ送信のセキュリティ」から共有されたものです。 ：ご苦労様です。
TCP接続が切断されました
今日のデジタル時代において、インターネットは人々の生活に欠かせないものとなっています。インターネットの基盤では、TCP プロトコルが重要な役割を果たし、ネットワーク内でのデータの信頼性の高い送信を担当します。 TCP 接続を確立する過程で、3 ウェイ ハンドシェイクのプロセスと原理はすでに理解しました。ただし、接続の確立は TCP プロトコルの一部にすぎず、接続の切断プロセスも同様に重要です。この記事では、4 回手を振るプロセスと状態の変化、4 回手を振る必要がある理由、および TIME_WAIT 状態が必要な理由など、TCP 接続の切断プロセスに焦点を当てます。 TCP 接続が切断されるプロセスを深く理解することで、ネットワーク通信の原理をより深く理解することができます。
TCP 4 ウェーブのプロセスとステータスの変更
TCP の切断には 4 つの波が必要です。双方ともアクティブに切断する機能を備えており、切断されると、ホスト内のさまざまな「リソース」が解放されます。それではTCPの4つのウェーブの原理とプロセスを詳しく解説していきます！
- クライアントが接続を閉じる場合、TCP ヘッダーの FIN フラグを 1 に設定したメッセージ、つまり FIN メッセージを送信します。その後、クライアントは FIN_WAIT_1 状態に入ります。
- サーバーがメッセージを受信すると、クライアントに ACK 応答メッセージを送信し、CLOSED_WAIT 状態に入ります。
- サーバーから ACK 応答メッセージを受信した後、クライアントは FIN_WAIT_2 状態に入ります。
- サーバーはデータが処理されるのを待った後、クライアントに FIN メッセージを送信し、LAST_ACK 状態に入ります。
- サーバーから FIN メッセージを受信した後、クライアントは ACK 応答メッセージで応答し、TIME_WAIT 状態に入ります。
- サーバーが ACK 応答メッセージを受信すると、CLOSE 状態になり、サーバーは接続の終了を完了します。
- 2MSL が一定期間経過すると、クライアントは自動的に CLOSE 状態になり、接続の終了も完了します。
TCP 接続の切断プロセス中に、各方向で FIN メッセージを送信し、ACK メッセージを受信する必要があることがわかります。そのため、このプロセスは通常 4 ウェーブと呼ばれます。
注意すべき点の 1 つは、接続の終了を積極的に開始した側のみが TIME_WAIT 状態になるということです。これは、接続を閉じた後、サーバーが独自の ACK 応答メッセージを確実に受信するために、クライアントは一定の時間 (通常は最大セグメント生存時間の 2 倍、つまり 2MSL) 待機する必要があるためです。この目的は、閉じられた接続に遅延セグメントが表示されるのを防ぎ、確実に接続を閉じることです。サーバーはこの期間待機する必要がないため、TIME_WAIT 状態は存在しません。
なぜ手を振るのに4回もかかるのですか？
なぜ 4 回の波が必要なのかをよりよく理解するために、双方の間で FIN パケットを送信するプロセスを確認してみましょう。したがって、4 つの波が必要な理由がわかります。
接続を閉じるときにクライアントがサーバーに FIN を送信するということは、クライアントがデータを送信しなくなったが、引き続きデータを受信できることを意味します。
サーバーがクライアントの FIN メッセージを受信すると、最初に ACK 応答メッセージで応答します。ただし、サーバーにはまだ処理して送信するデータがある可能性があるため、データの送信がなくなるまで待機してから、FIN メッセージをクライアントに送信して、接続を今すぐ閉じることに同意することを示します。
上記のプロセスを通じて、サーバーは通常、データの送信と処理の完了を待つ必要があることがわかります。そのため、サーバーの ACK と FIN は通常、別々に送信され、その結果、3 ウェイ ハンドシェイクよりも 1 つのウェーブが多くなります。
TIME_WAIT が 2MSL 待機するのはなぜですか?
MSL は Maximum Segment Lifetime であり、パケットの最大生存時間であり、パケットがネットワーク内に存在する最長時間を示します。この時間が経過すると、パケットは破棄されます。 TCP プロトコルは IP プロトコルに基づいているため、IP ヘッダーには、データグラムが通過できるルートの最大数を示す TTL フィールドがあります。ルーターを通過するたびに、TTL 値は 1 ずつ減ります。 TTL 値が 0 の場合、データグラムは破棄され、送信元ホストに通知するために ICMP メッセージが送信されます。
MSL と TTL の違いは単位です。 MSL の単位は時間、TTL は通過するルーティング ホップ数です。したがって、パケットが自然に終了したことを確認するには、MSL が TTL 消費量が 0 に達する時間以上である必要があります。
TIME_WAIT が MSL の 2 回待機することについての妥当な説明は、ネットワーク内に送信者からのパケットが存在する可能性があるということです。これらのパケットが受信側で処理されると、相手に応答が送信されるため、往復に 2 倍の時間がかかります。これは、最後の ACK がサーバーに確実に受信されるようにするためのもので、受信されなかった場合は、サーバーが FIN の 3 波目を再送信するのに十分な時間を与える必要があります。
たとえば、受動的終了側が切断に対する最後の ACK メッセージを受信しない場合、タイムアウトがトリガーされ、FIN メッセージが再送信されます。相手は FIN メッセージを受信した後、パッシブ クロージング パーティに ACK を再送信するため、往復には 2 MSL かかります。
2MSL 時間は、クライアントが FIN を受信した後、ACK を送信した時点から開始します。 TIME_WAIT 時間以内の場合、クライアントの ACK がサーバーに送信されず、クライアントがサーバーによって再送信された FIN メッセージを受信するため、2MSL 時間が再計測されます。
Linux システムでは、デフォルトの 2MSL 時間は 60 秒、つまり 1 MSL は 30 秒です。 Linux システムが TIME_WAIT 状態に留まる時間は 60 秒に固定されています。
Linux カーネル コードでは、その定義の名前は TCP_TIMEWAIT_LEN です。
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
state, about 60 seconds */コピーTIME_WAIT の長さを変更する場合は、Linux カーネル コードの TCP_TIMEWAIT_LEN の値を変更し、Linux カーネルを再コンパイルすることしかできません。
なぜ TIME_WAIT 状態が必要なのでしょうか?
TIME_WAIT 状態は、ネットワーク接続を確実に閉じるために存在します。接続の終了を積極的に開始する当事者 (つまり、アクティブに終了する当事者) のみが TIME_WAIT 状態になります。
TIME_WAIT 状態が必要になる主な理由は 2 つあります。
- 同じ「クアッド」を持つ「古い」パケットの受信を防止する: ネットワーク通信では、各 TCP 接続は、送信元 IP アドレス、送信元ポート番号、宛先 IP アドレス、宛先ポート番号の 4 つの要素によって一意に識別されます。クワッド」。一方の当事者が積極的に接続を閉じて TIME_WAIT 状態に入った場合でも、一定期間内に他方の当事者から遅延データ パケットを受信することができます。これは、ネットワーク内でデータ パケットの送信が遅延する可能性があるためで、TIME_WAIT 状態がない場合、これらの遅延したデータ パケットが新しい接続に誤って配信され、データの混乱が生じる可能性があります。 TIME_WAIT 状態を維持することで、古いパケットが新しい接続に干渉するのを防ぎます。
- 「接続を受動的に閉じる」側が正しく閉じることができることを確認します。接続の受動的に閉じる側は、アクティブな閉じる側から FIN メッセージ (接続が閉じられたことを示す) を受信すると、確認 ACK メッセージを送信する必要があります。アクティブなクロージング パーティに接続してクロージャの接続を完了します。ただし、ネットワークの信頼性が低く、送信中に ACK メッセージが失われる可能性があります。アクティブな終了側が ACK メッセージを受信する前に接続を終了すると、受動的な終了側は接続の終了を正常に完了できなくなります。 TIME_WAIT 状態の存在により、受動的終了側が最後の ACK メッセージを受信できることが保証され、接続を正常に終了できるようになります。
古い接続からのパケットを防止する
TIME-WAIT 状態に適切な待ち時間がないか、待ち時間が短すぎると、遅延したデータ パケットの到着後に重大な問題が発生する可能性があります。
たとえば、接続を閉じる前にサーバーによって送信された SEQ = 301 メッセージは、ネットワークによって遅延されます。次に、同じポートの TCP 接続が再利用され、遅延した SEQ=301 がクライアントに到達します。この場合、クライアントは期限切れのメッセージを正常に受信し、データの破損などの重大な問題が発生する可能性があります。
この問題を解決するために、TCP はメカニズムを設計しました。つまり、2MSL 以降は、接続の両方向のデータ パケットが破棄されるだけで十分です。このようにして、元の接続のデータ パケットはネットワーク内で自然に消滅し、再び現れるデータ パケットは新しく確立された接続によって生成される必要があるため、データの混乱などの問題が回避されます。
接続が正しく閉じられていることを確認してください
TIME-WAIT 状態の役割は、パッシブ シャットダウン パーティが最後の ACK メッセージを確実に受信し、正常にシャットダウンできるようにするために十分な時間を待機することです。
TIME-WAIT の待ち時間が適切でないか、短すぎる場合、切断により次のような問題が発生する可能性があります。
たとえば、クライアントが送信した最後の ACK メッセージが 4 つのウェーブの間にネットワークで失われ、クライアントの TIME-WAIT 状態が短すぎるか設定されていない場合、クライアントは直接 CLOSE 状態に入り、サーバーは常に LAST-ACK 状態になります。この場合、接続を正常に閉じることができません。
さらに、クライアントが接続を確立するために SYN リクエストを開始するときに、サーバーがクライアントに RST メッセージを送信すると、接続確立プロセスは終了します。
TIME-WAIT が十分に長く待機すると、次の 2 つのことが起こります。
- サーバーは通常、4 つの波の最後の ACK メッセージを受信するため、接続は正常に閉じられます。
- サーバーが 4 つの波の最後の ACK メッセージを受信しない場合、FIN 接続終了メッセージを再送信し、新しい ACK メッセージを待ちます。
したがって、クライアントは TIME-WAIT 状態で 2MSL 待機した後、両側の接続を正常に閉じることができます。
ここでも関連知識の普及が行われていますが、スリーウェイ ハンドシェイクとフォーウェイ ウェーブについてはほとんど言及されていません。 3回目に手を振るとackが送信されるのはなぜですか?フィンだけ送るのが普通じゃないですか？
TCP プロトコルでは、ACK フィールドが 0 に設定されている最初の接続の最初の SYN パケットを除き、他のすべての TCP パケットの ACK フィールドは 1 に設定されます。この ACK フィールドの目的は、受信者がデータを正常に受信したことを確認することです。 TCPプロトコルは、送信する必要のあるデータがある場合、相手のデータを確認するためにACKを付けて送信します。送信中にデータが失われた場合、TCP はデータを再送信します。 TCP ヘッダーには ACK フィールドが必要ですが、これらの 32 ビットが空の場合は、最初のメッセージ セグメントを除くすべてのメッセージ セグメントの ACK フィールドを有効にするだけです。
要約する
TCP 接続は 4 つのウェーブのプロセスを経て切断される必要があります。双方とも積極的に切断することができ、切断後はさまざまなリソースが解放されます。 4 回手を振るプロセスには、FIN および ACK メッセージを送信する双方の対話が含まれ、データの信頼性の高い送信と接続の正しい終了が保証されます。このうち、アクティブに閉じる側は TIME_WAIT 状態に入り、相手が最終 ACK メッセージを受信したことを確認するために一定時間待機します。 TIME_WAIT 状態は、古い接続からのパケットが新しい接続に干渉するのを防ぎ、受動的に閉じる側が接続を正常に閉じることができるようにするために存在します。ウェーブが 4 回必要な理由は、データの完全な転送と確実な接続の終了を保証するためです。 TIME_WAIT 状態は、ネットワーク内のすべてのデータ パケットが確実に消えるように MSL の 2 倍待機します。