TCP スリーウェイ ハンドシェイク。
最初のハンドシェイク: 接続が確立されると、クライアントは syn パケット ( syn=j)をサーバーに 送信し 、 SYN_SENT 状態に入り、サーバーの確認を待ちます。
syn: シーケンス番号の同期 (シーケンス番号の同期)
2 番目のハンドシェイク:サーバーは 、クライアントによって 送信された syn パケットを受信し 、クライアントのACK (ack=j+1)を確認する必要があり、同時に SYNパケット ( seq=k ) も送信します。 SYN+ACKパケット この時点で、サーバーは SYN_RECV 状態に入ります。
seq: (シーケンス)
確認：確認します
3 番目のハンドシェイク:クライアントは サーバーから SYN+ACK パケットを受信し、 確認パケット ACK (ack=k+1)をサーバーに送信します。パケットが送信された後、クライアントとサーバーは ESTABLISHED状態になります(TCP 接続は成功します)。 ）の状態で3回握手を完了します。
確立されました: 正常に確立されました
************************************************* ************************************************* ***************************
なぜ2回ではなく3回なのでしょうか？
次に、一つ理解する必要があるのは、ハンドシェイクで解決すべき問題とは何かということです。
ハンドシェイクによって解決されるべき問題は、実際には次のとおりです。サーバーが、クライアントが使用する接続を 1 つだけ開くことを望みます。2 回のハンドシェイクが必ずしも失敗するとは限りません
a が b に手紙を送ったとします (初回)。
b はその手紙を受け取り、a に受け取ったことを伝えるためにもう一度手紙を書きます。（2回目）
このとき、a は b に再度書き込みませんでした (3 回目は書き込みません)。
表面上、a と b の間の通信は成功していますが、実際には 2 つの可能性があります。
1. A には b への文字がありません。
2. a は b から手紙を受け取ることができます。
ハンドシェイクが 2 回しかないと仮定すると 、ここに問題があります。
a は b に手紙を送り、b はその手紙を受け取った後に再び a に手紙を書きます（2 回のハンドシェイクが完了します）。
しかし、b の手紙が a に送られると、その手紙は失われてしまいます (b から a へのネットワークは利用できなくなります)。
このとき、aが手紙を受け取っていないと、bには手紙が送られていないと考えてしまいます。(双方向ハンドシェイクなので、この時点では b は a がパッケージを受け取ったものとみなします)
このときの b の状態は、チャネルがオープンされ、a が再び書き込むのを待っていることになります。
このときのaの状態は、返信がないためbに再送信するというものです。(実際、 がパケットを受信すると、2 つのハンドシェイクによって接続も正常に確立されます)
次に、b はレターを受信した後に新しいチャネルを開き、a がレターを送信するのを待つというサイクルを繰り返すため、ネットワーク リソースが無駄になります。！！
3ウェイハンドシェイク後はそのような問題はないのでしょうか？
3 ウェイ ハンドシェイクが成功しました。これは、a から b、b から a へのネットワークが接続されていることを証明します。a が b に情報を送信します。この時点ではタイムアウト期間があり、b の情報を a に送信できない場合 (この時点でタイムアウトになります)、b が情報を受信して返すまで、a は論理的に新しいリクエストを再送信します。に。
ハンドシェイク中にテキスト メッセージを直接送信しないのはなぜでしょうか。ネットワークが切断されてテキストがサーバーに送信されると、サーバーが簡単に輻輳してハングアップしてしまうからです。
概要: 3 ウェイ ハンドシェイクは、ネットワークまたはその他の理由によるリソースの不要な浪費を削減するためのものです (a が b のパケットを受信しない場合)