3ウェイハンドシェイクが必要な理由 なぜ2ウェイだけではないのですか？

TCP 3ウェイハンドシェイクは次のように機能します。

Client ------SYN-----> Server
Client <---ACK/SYN---- Server
Client ------ACK-----> Server

なぜこれだけではないのですか？

Client ------SYN-----> Server
Client <-----ACK------ Server

ハンドシェイクを実際に実行していることに分解します。

TCPでは、2つのパーティは、シーケンス番号を使用して送信したものを追跡します。事実上、送信されたすべての実行バイト数になります。受信側は、反対側のスピーカーのシーケンス番号を使用して、受信したものを確認できます。

ただし、シーケンス番号は0からは始まりません。ISN（初期シーケンス番号）から始まります。これはランダムに選択された値です。また、TCPは双方向通信であるため、両当事者は「話す」ことができ、したがって両方が開始シーケンス番号としてISNをランダムに生成する必要があります。つまり、両当事者は、開始ISNを相手方に通知する必要があります。

したがって、アリスとボブの間のTCP会話を開始するための次の一連のイベントになります。

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

4つのイベントが発生していることに注意してください。

1. アリスはISNを選択し、それをボブと同期します。
2. ボブは認め ISNを。
3. ボブはISNを選択し、アリスと同期します。
4. アリスは認め ISNを。

しかし実際には、中央の2つのイベント（＃2と＃3）は同じパケットで発生します。パケットをa SYNまたはにするのACKは、単に各TCPヘッダー内でオンまたはオフにされるバイナリフラグなので、これらのフラグの両方が同じパケットで有効になるのを妨げるものは何もありません。したがって、3方向ハンドシェイクは次のようになります。

Bob <--- Alice         SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK     

双方向の「SYN」と「ACK」の2つのインスタンスに注意してください。

それでは、質問に戻って、双方向のハンドシェイクを使用しないでください。簡単な答えは、双方向ハンドシェイクでは、一方の当事者のみがISNを確立し、他方の当事者はそれを確認することしかできないためです。つまり、データを送信できるのは1者のみです。

ただし、TCPは双方向通信プロトコルであるため、どちらの側もデータを確実に送信できる必要があります。両当事者はISNを確立する必要があり、両当事者は相手のISNを確認する必要があります。

したがって、実際には、双方向ハンドシェイクの正確な説明が、各方向にあります。したがって、4つのイベントが発生します。繰り返しますが、中央の2つのフラグは同じパケットで発生します。そのため、3つのパケットが完全なTCP接続開始プロセスに関与しています。

3方向のハンドシェイクが必要なのは、両当事者が送信中に使用されるセグメントシーケンス番号を同期する必要があるためです。このため、それらの各々は、（順番に）ランダム値に設定されたシーケンス番号とSYNセグメント送信Nその後され、ACKに設定されたシーケンス番号を有するACKセグメントを介して他の当事者によってnowledged N + 1。

接続が機能するためには、両側がパケットを相手側に送信できることを確認する必要があります。相手側にパケットを確実に取得する唯一の方法は、パケットを取得することです。これは、定義により、送信したパケットが通過しない限り送信されないはずです。TCPは基本的に 2種類のメッセージを使用します：SYN（このパケットが通過したことの証明を要求する）とACK（SYNが通過したことを証明するためにSYNが通過した後にのみ送信される）。実際には3番目の種類のメッセージがありますが、すぐにそれについて説明します。

接続が開始される前に、どちらの側も実際には相手について何も知りません。クライアントは、SYNパケットをサーバーに送信して、メッセージが通過できることの証明を要求します。それはどちらの人にも何も伝えませんが、それは握手の最初のステップです。

SYNが通過すると、サーバーはクライアントがパケットを送信できることを認識します。しかし、それはサーバーがパケットを送り返すことができることを証明しません：クライアントは多くの理由でSYNを送ることができます。そのため、サーバーは、ACK（SYNが通過したことを証明するため）とSYN（独自のACKを要求するため）の2つのメッセージをクライアントに送り返す必要があります。TCPは、ネットワークトラフィックを削減するために、これら2つのメッセージを1つ（SYN-ACKメッセージ（必要な場合））に結合します。これは、ハンドシェイクの2番目のステップです。

SYN-ACKはACKであるため、クライアントはサーバーにパケットを送信できることを確信しています。また、SYN-ACKはSYNであるため、サーバーがこのメッセージが通過したことの証明を必要としていることも知っています。そのため、ACKを送り返します。今回は単なるACKです。これは、パケットが通過できることを証明する必要がなくなったためです。これがハンドシェイクの最後のステップです。クライアントはパケットが双方向に送信できること、そしてサーバーがこれを理解しようとしていることを認識します（ACKが送信されることを知っているため）。

ACKが通過すると、サーバーはクライアントにパケットを送信できることを認識します。また、クライアントがこれを知っていることも知っているので、すぐにデータの送信を開始できます。ハンドシェイクが完了しました。良いチャンネルがあります。

まあ、厳密に言えば、良いチャネルがあるかどうかはわかりません。この一連のパケットが通過したからといって、他のパケットが通過することを厳密に保証するわけではありません。無限の数のSYNとACKを送信しないと、他に何も実行されないことを証明することはできません。したがって、これは実際的な選択肢ではありません。しかし実際には、3つのステップでほとんどの目的に十分であることがわかります。

実際、3ウェイハンドシェイクだけがTCP接続を確立する手段ではありません。同時SYN交換も許可されています：http : //www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-4.htm

それは一種の二重の双方向ハンドシェイクと見ることができます。

TCP接続は双方向です。これが意味することは、実際には一方向の接続のペアであることです。イニシエーターはSYNを送信し、レスポンダーはACKを送信します。1つのシンプレックス接続が開始されます。「その後」レスポンダーがSYNを送信し、イニシエーターがACKを送信します。別のシンプレックス接続が開始されます。2つのシンプレックス接続が1つのデュプレックスTCPセッションを形成します、同意しますか？したがって、論理的には4つのステップが含まれます。ただし、SYNフラグとACKフラグはTCPヘッダーの異なる「フィールド」であるため、同時に設定できます-（4つのうちの）2番目と3番目のステップが組み合わされ、技術的には3つのパケット交換が行われます。あなたが提案したように、各シンプレックス（ハーフ）接続は双方向の交換を使用します。

サーバーとクライアントが接続を作成する場合、4つのことを確認する必要があります。

1. サーバーは、クライアントからパケットを受信できることを確認する必要があります

2. クライアントは、サーバーからパケットを受信できることを確認する必要があります

3. クライアントは事を確認する必要があります：サーバーはクライアントからパケットを受信できます

4. サーバーは事を確認する必要があります：クライアントはサーバーからパケットを受信できます

後にClient ------SYN-----> Server、ルール1が確認されます。

後Client <---ACK/SYN---- Server、ルール2および3が確認されます。

そのため、ルール4を確認するために3番目のパケットが必要です。

まったく必要ありません。短いメッセージが必要なのは、開始+メッセージを含むサーバーへの1つのパケットと、それを確認するための1つのパケットだけである必要があることは明らかです。

前の回答では、最初にランダムシーケンス番号などの必要性については説明せずに、システムについて説明しました。元々の質問はTCP自体の設計に関するものでした。明らかにTCPプロトコルを使用する場合、それがプロトコルであるため3つのメッセージが必要です。しかし、そもそもTCPがそのように設計されたのはなぜですか？

元々のアイデアは、クライアントとサーバーの間に区別がないということでした。どちらも双方向で相手のポートを認識しており、どちらも会話を開始できます。それにはSynsなどが必要でした。

しかし、これはもちろん、今日の使用方法ではありません。サーバーは、既知のポートでリッスンし、「受け入れ」ます。クライアントのポート番号は一時的です。「受け入れ」を待っているサーバーが、通常のオペレーティングシステムの同じクライアントポート番号で別のサーバーに要求を送信することは不可能だとさえ思います。

（これは接続の双方向の開始に関するものであり、今日では決して行われないことに注意してください。これは、確立された接続に双方向メッセージを送信することとはまったく異なります。）

TCPの非効率性を回避するために、HTTP 1.1などのプロトコルを使用して、複数の要求に同じ接続を再利用できるため、そもそも必要ではなかったTCPハンドシェイクを回避できます。

しかし、Http 1.1は比較的新しいものです。また、SSL / TLSでは、PKIアルゴリズムのコストのために、セッションを最初から再利用する方法が必要でした。そのため、そのプロトコルには、TCP上で実行されるHttp 1.1上で実行される独自のセッション再利用メカニズムが含まれています。

これがソフトウェアの方法です。組み合わされたときに許容できる結果をもたらすクラッジのファッジ。

Eddieの回答（正しいと認められた）を読んだ後、なぜ1番目のホストがISNに乱数を割り当てられず、2番目のホストがそれを受け入れることができないのかという疑問が残っています。3ウェイハンドシェイクを使用する本当の理由は、ハーフコネクションを避けるためです。双方向ハンドシェイクの半分の接続シナリオ：
1）クライアント--- SYN- >サーバー
2）クライアントは気が変わり、もう接続したくない
3）クライアント<-X-ACK--サーバー// ACKが失われた
サーバーはSYNの再送信を認識しないため、クライアントはACKを取得して接続が確立されたと考えています。その結果、サーバーには閉じられない接続があります