コンピュータネットワークのTCPプロトコルのコーミング

序文

この記事では、TCPプロトコル
TCP：Transmission Control Protocol、Transmission ControlProtocolを組み合わせています。

TCPの主な機能

コネクション型伝送プロトコル
は、アプリケーションプログラムがTCPを使用する前に最初にTCP伝送接続を確立する必要があることを意味します。データ伝送が完了した後、確立されたTCP伝送接続を解放する必要があります。
ユニキャスト送信のみをサポートします。
各TCP送信接続は、2つのエンドポイント（ソケット）のみを持つことができ、ポイントツーポイントデータ送信のみを実行でき、マルチキャストおよびブロードキャスト送信方法をサポートしません。
信頼性の高い配信サービスを提供する
TCPは、エラーがなく、損失がなく、繰り返しがなく、時系列に従って反対側に到達できます。
伝送ユニットはデータセグメントです
TCPは依然としてデータ伝送ユニットとして従来の「データセグメント」を使用しています。
データセグメントとは、アプリケーション層から受信したデータをTCPセグメント化して取得したデータブロックのことです。
1つのTPDUフォーマットのみ
TCPデータセグメントヘッダーには、さまざまなTPDUに必要な特性フィールドが含まれているため、主にそれらの間の複数の制御アクションによって実現されます。
全二重通信
をサポートするTCP接続の両端には、双方向通信用のデータを一時的に保存するための送信とバッファリングが装備されています。
TCP接続は、メッセージストリームではなく、バイトストリームに基づいています
。TCPは、UDPのように個々のメッセージを個別に送信するのではなく、メッセージの境界を維持せずにバイトストリームで送信します。
TCPデータセグメントのサイズと毎回送信されるデータセグメントの数は可変です
。TCP送信のデータセグメントサイズは、相手から指定されたウィンドウサイズと現在使用可能な送信ウィンドウ（現在のネットワーク輻輳）に応じて決定されます。また、アプリケーション層によって送信されるメッセージのサイズは、
ルーティングされるネットワーク内のMTU値のサイズによって決定されます。このように、一度に送信できるTCPデータセグメントの数も影響を受けません。修正済み。現在利用可能な发送窗口大小制限内である限り、一度に1つのTCPデータセグメントのみを送信することも、一度に複数のTCPデータを送信することもできます。
さらに、アプリケーションプロセスによってTCPバッファーに送信されるデータが長すぎる場合、TCPはそれをセグメント化できます。逆に、TCPバッファーに送信されるデータが小さすぎる場合、TCPはバッファー内の十分なデータがアセンブルされるのを待ちます。データセグメントにまとめて送信されます（ディッピングとアンパック）。

TCPセグメント

メッセージ

ACK、SYN、およびFINの大文字はフラグビットを表し、それらの値は1または0のいずれか
です。ackおよびseqの小文字はシーケンス番号を表します。

送信元ポートと宛先ポートは
それぞれ、発呼側と着呼側のTCPポート番号を表します。ポートとそのホストIPアドレスは、エンドポイント、つまりソケットを完全に識別できます。
ポートはトランスポート層の概念です。送信元IPと宛先IPは、ネットワーク層のIPヘッダーに追加されます。
シーケンス番号seq：
4バイトを占有し、データセグメントのシーケンスをマークするために使用され、TCPはシーケンス番号に関連して送信されるすべてのデータバイトをエンコードし、最初のバイトの番号はローカルでランダムに生成されます。シーケンス後のバイトをエンコードします。番号が追加され、シーケンス番号が各セグメントに割り当てられます。シーケンス番号seqは、このセグメントの最初のバイトのデータ番号です。
確認応答番号ack：
4バイトを占有し、次のメッセージセグメントの最初のデータバイトの
シーケンス番号を相手から受信することを期待します。シーケンス番号は、メッセージセグメントで伝送されるデータの最初のバイトの番号を表します。確認番号参照これは、受信が予想される次のバイトの番号です。したがって、現在のセグメント+1の最後のバイトの番号が確認番号です。
同期SYN：接続が確立されたときにシリアル番号を同期するために使用されます。
SYN = 1およびACK = 0の場合、これは次のことを意味します。これは接続要求セグメントです。接続が合意されると、応答セグメントでSYN = 1およびACK = 1になります。
したがって、SYN = 1は、これが接続要求または接続受け入れメッセージであることを意味します。
SYNフラグはTCP接続が確立されたときにのみ1に設定され、ハンドシェイクが完了した後にSYNフラグは0に設定されます。
確認ACK：
1ビットを占有します。ACK= 1の場合にのみ、確認番号フィールドが有効です。ACK = 0の場合、確認番号は無効です
FINの終了：
接続を解放するために使用されます。
FIN = 1は、このセグメントの送信者のデータが送信され、トランスポート接続を解放する必要があることを意味します
ウィンドウサイズ
このTCPデータセグメントを送信するホストに着信データセグメントを格納するために使用されるウィンドウサイズ、つまり、送信者が現在受信できる最大バイト数を示します。「ウィンドウサイズ」フィールドの値は、このデータセグメントを受信するホストに、このデータセグメントに設定された「確認番号」の値から開始して、ローカルエンドが現在相手側に送信を許可しているバイト数を通知します。送信する相手側の設定として使用されますウィンドウサイズの基準。

TCPが信頼できる接続である理由

チェック、シリアル番号、確認、再送。

バイト番号付けメカニズム
TCPデータセグメントは数据部分、各バイトのデータを順番に送受信できるように、データセグメント内でバイト単位で1つずつ番号が付けられます。
TCPによって送信されるデータセグメントの「データ」部分（TCPデータセグメントのヘッダーを除く）では、各バイトにシーケンス番号があり、各データセグメントの「シーケンス番号」フィールドは、の最初のバイトに基づいています。データセグメントシリアル番号が入力されます。
データセグメント確認メカニズム
TCPでは、データセグメントを受信するたびに、受信者が確認データセグメントACKを送信者に返す必要があります。確認番号は、受信者の正しいインターフェイスのデータセグメントシーケンス番号を示します（前のすべてのデータセグメント）。確認番号）。
ACKは、「確認番号」フィールドが有効かどうかを示すフラグです。ACKフィールドの値のみが1であり、データセグメントの「確認番号」は意味があります。それ以外の場合、データセグメントの「確認番号」は無意味です。つまり、「確認番号」の意味はありません。上記の通り。
- TCPは、一度に複数のデータセグメントを連続して送信できます。TCPは
  、相手から送信された確認データセグメント（「ACK」フィールドが1のデータセグメント）の受信を待たずに、一度に複数のデータセグメントを連続して送信できます。データ送信の効率を大幅に向上させます。ただし、一度に送信できるデータセグメントの数は、相手から返される「ウィンドウサイズ」フィールド値と現在使用可能な「送信ウィンドウ」サイズの両方によって制限されます。送信者は、確認をまだ受信していないデータセグメントをバッファリングする必要があるため、特定の「送信ウィンドウ」サイズを占有する必要があります。
- 連続して受信したデータセグメントのみを確認します。
  各データセグメントの長さを100バイトとすると、受信側はシーケンス番号1、101、201、401の4つのデータセグメントを受信しています。シーケンス番号301のデータセグメントは一時的に受信されていません。現時点では、受信側から返される確認データセグメントの「確認番号」は、501ではなく301のみです。つまり、最初の3つのデータセグメントのみが受信されます。中央の301データセグメントが受信されていないため、次の401データセグメントが確認されます。後で301データセグメントを受信すると、「確認番号」が501のデータセグメントが返される場合があります。これは、301データセグメントと401データセグメントの両方が正しく受信されたことを意味します。
- シリアル番号が連続していないデータが最初にキャッシュされます。たとえば
  、ホストは、シリアル番号1、101、201、301、601、401、801、および501のデータセグメントを反対側から連続して受信しました（データがセグメントのサイズはすべて100バイトです）、ホストは最初に4つのデータセグメント1、101、201、および301をアプリケーション層に送信し、「確認番号」が401の確認データセグメントを送信者に送信します。これは「受信ウィンドウ」から削除できます。4つのデータセグメント、「受信ウィンドウ」を解放します。次に、3つのデータセグメント601、401、および801は、データセグメント501が受信されるまで、最初に「受信ウィンドウ」にバッファリングされます。 401、501、601の順に再編成し、アプリケーション層に送信し、「確認番号」が701の確認データセグメントを送信して、「受信ウィンドウ」から削除できるようにします。そして、「受信ウィンドウ」が解放されるが、この時点で「受信ウィンドウ」には、データセグメント７０１がまだ確認されていないため、キャッシュにデータセグメント８０１がまだ残っている。
タイムアウト再送信メカニズム
TCPには再送信タイマーがあり、データセグメントの送信時にも開始されます。タイマーが切れる前にデータセグメントが相手によって確認されなかった場合、タイマーは停止し、シーケンス番号に対応するデータセグメントが再送信されます。
TCPは、適応アルゴリズムを使用して、タイムアウトの再送信時間を動的に変更します。
同時に、タイマーの期限が切れるのを待たずにすぐに送信できる高速再送信メカニズムもあります。
選択的ACK（SACK）メカニズムSACK
のサポートにより、データの欠落部分のみを再送信できますが、正しく受信されたデータは再送信されません。
受信側が5つのシーケンス番号1、101、201、401、501のデータセグメントを受信したとすると、確認番号301で確認データセグメントを送信するときに、SACK拡張オプションで401をマークします（開始シーケンス番号は401、終了シリアル番号は500）および501（開始シリアル番号は501、終了シリアル番号は600）これらの2つの不連続データセグメント。このとき、送信者は、2つのデータセグメント401と501を送信する必要はなく、データセグメント301を送信するだけであることがわかります。これにより、ネットワークリソースが大幅に節約され、データ転送効率も向上します。

フロー制御

流量控制これは、2つの通信当事者のデータ送信および受信レートマッチングの考慮事項に基づいています。最終的な目標は、受信側が時間内にデータを受信できるようにデータを送信する速度が速すぎないことです。これは、両方でポイントツーポイントの動作です。リンクの終わり。これは、送信者がデータを送信する速度が速すぎるのを防ぎ、受信者がデータを受信する時間を確保するためです。

フロー制御の目的：データの送信速度が速すぎないようにして、受信側が時間内にデータを受信できるようにします。
フロー制御スキーム：TCPは、スライディングウィンドウメカニズムを使用してフロー制御を実現します。
通信プロセスでは、受信者は受信バッファのサイズ、つまりインターフェイスウィンドウrwnd（受信者は確認セグメントのウィンドウフィールドを設定して送信者にrwndを通知する）に応じて送信者の送信ウィンドウサイズを動的に調整します。送信者の送信ウィンドウ取接收窗口rwnd合計の拥塞窗口cwnd最小値。
永続性タイマー
TCPは、接続ごとに永続性タイマーを設定します。TCP接続の一方の当事者が他方の当事者からゼロウィンドウ通知を受信している限り、永続性タイマーが開始されます。連続タイマーで設定された時間が経過すると、ウィンドウがゼロのプローブセグメントが送信され、レシーバーはプローブセグメントを受信したときに現在のウィンドウ値を提供します。ウィンドウがまだ0の場合、送信者は継続時間タイマーをリセットします。

輻輳制御

輻輳の条件：リソース要件の合計>使用可能なリソース。
輻輳制御は、ネットワーク内の各リンクの帯域幅と中間デバイスのデータ処理機能に基づいています。ネットワーク内のデータ送信をブロックしないでください。つまり、送信しないでください。エンドによって送信されるデータは、エンドツーエンドの動作である受信エンドのデータ処理能力よりも大きくなります。
輻輳の原因は複雑になる可能性があります。たとえば、TCP接続のリンク全体で、ノードデバイスのバッファスペースが小さすぎる、データ転送能力が低すぎる、特定のリンクの帯域幅が小さすぎる、ピアデータ受信能力が低いなどです。など、ネットワークの輻輳を引き起こす可能性があります。
たとえば、ユーザーは中間ルーターノードのデータ転送容量を一方的に改善したいが、パスに沿った各リンクの帯域幅を無視します。その結果、ルーター転送のパフォーマンスは向上しますが、データ転送速度も向上します。しかし同時に、その結果、リンク上でキューに入れられるデータが増え続け、ネットワークの輻輳の問題を解決できないだけでなく、ネットワークの輻輳がより深刻になります。
別の例として、ユーザーはルーターのキャッシュ容量を一方的に改善したいが、ルーターのデータ転送容量とリンク帯域幅を同時に考慮していません。その結果、より多くのデータをルーターに一時的にキャッシュできますが、キャッシュにキューイングされます。。キューが以前より長くなるため、データの待機時間が長くなり、その結果、タイムアウトのためにデータが再送信されます。再送信されるデータが多いほど、ネットワークの負荷が大きくなり、最終的にはより深刻な輻輳が発生します。
輻輳制御の目的：過剰なデータがネットワークに注入されるのを防ぐため
輻輳制御スキームは次のとおりです。
スロースタート、輻輳回避、高速再送信、高速リカバリ
送信ウィンドウ=分（受信ウィンドウrwnd、輻輳ウィンドウcwnd）
受信ウィンドウ：受信者は、受信者の容量を反映して、受信バッファによって設定された値に従って送信者に通知します。
輻輳ウィンドウ：ネットワークの現在の容量を反映して、送信者が自身で推定したネットワーク輻輳の程度に応じて設定するウィンドウ値。

スロースタートと輻輳回避

スロースタートとは、ネットワークの輻輳を回避するための最初のTCP輻輳防止プログラムを指します。基本的な考え方は、TCP接続が正式にデータを送信するとき、毎回送信できるデータのサイズ拥塞窗口が徐々に大きくなる、つまり、いくつかの小さなバイトの仮データが最初に送信され、これらのデータセグメントの確認を受信した後に送信されるというものです。、最初に設定された特定の制限に達するまで、送信されるデータの量をゆっくりと増やし慢启动阈值SSTHRESHます。
とき拥塞窗口大小CWND、それはより大きいか、再度SSTHRESHに等しく、「輻輳回避」溶液が開始されます。基本的な考え方は、CWND値が2回目にSSDHRESHに達すると、「輻輳ウィンドウ」サイズは、各RTT（データセグメントがの間を行き来するのに必要な時間）の後に1（新しいCWND）だけ増加するということです。受信側と送信側）。元のCWNDの数倍ではなく1つのMSSのサイズのみを増やし、「スロースタート」スキームのように指数関数的に増加し続けるのではなく、直線的にゆっくりと増加させます。明らかに、このCWNDの成長率は、「スロースタート」スキームのCWNDの成長率よりも明らかに遅いです。データ損失が再び発生すると、SSTHRESHは現在のCWNDの半分に減少し、CWNDは1に設定され、「スロースタート」データ送信プロセスに再び入ります。

スロースタートは、到達するまで指数関数的に増加し慢启动阈值SSTHRESH、輻輳回避加法增大（線形）が実行されます。データ損失が発生すると、SSTHRESH乗算は元の値の半分に減少すると同時に、cwnd1に設定され、スロースタートが実行されます。開始フェーズに戻ります。

高速再送信と高速リカバリ

高速再送信
受信側が順番に到着しないデータセグメントを受信すると、TCPエンティティは、データの送信を待つのではなく、繰り返しACKデータセグメントをすばやく送信し、確認応答を送信します。3つの繰り返しACKデータセグメントが後で繰り返し受信した場合、「確認番号」フィールドに対応するデータセグメントが失われたと見なされ、TCPは、失われたと思われるデータセグメントを再送信する前に、再送信タイマーの期限が切れるのを待ちません。
高速リカバリ
高速リカバリアルゴリズムの基本的な考え方：3回目の繰り返しACKを受信すると、現在のCWND値が現在のSSTHRESH値の半分に設定されてネットワーク負荷が軽減され、次に上記で紹介した「輻輳回避」アルゴリズムが使用されます。ネットワークの輻輳を再び回避するために、CWND値をゆっくりと増加させるために実行されます。

参照：
TCPフロー制御、輻輳制御

TCPスリーウェイハンドシェイク

3つのハンドシェイク

接続を確立するとき：
クライアントはsynパケット（seq = x、SYN = 1）をサーバーに送信し、SYN_SENT状態に入り、サーバーが確認するのを待ちます。
サーバーはsynパッケージを受信します。
クライアントのSYNを確認すると同時に、SYNパッケージ、つまりSYN + ACKパッケージ（seq = y、ack = x + 1、SYN = 1、ACK = 1）を送信する必要があります。サーバーはSYN_RECV状態になります;
クライアントは
サーバーからSYN + ACKパケットを受信します：確認応答パケットACK（seq = x + 1、ack = y + 1、ACK = 1）をサーバーに送信し、このパケットが送信され、クライアントとサーバーはESTABLISHEDに入ります（TCP接続は成功しました）状態、3ウェイハンドシェイクを完了します。

4回振る

クライアントプロセスは接続解放メッセージ（seq = u、FIN = 1）を送信し、データの送信を停止します。
このとき、クライアントはFIN-WAIT-1（終了待機1）状態になります。
TCPは、FINセグメントがデータを伝送しない場合でも、シーケンス番号を消費することを規定しています。
サーバーは接続解放メッセージを受信し、確認メッセージを送信します（seq = v、ack = u + 1、ACK = 1）。
このとき、サーバーはCLOSE-WAIT状態になります。
TCPサーバーは、クライアントがサーバーの方向に解放されたことを高レベルのアプリケーションプロセスに通知します。この時点では、クライアントはハーフクローズ状態です。つまり、クライアントには送信するデータがありませんが、サーバーがデータを送信しても、クライアントはそれを受け入れる必要があります。この状態はしばらく続きます。つまり、CLOSE-WAIT状態全体が持続します。
クライアントがサーバーの確認要求を受信した後、クライアントはFIN-WAIT-2（終了待機2）状態
に入り、サーバーが接続解放メッセージを送信するのを待ちます（その前に、サーバーから送信された最後のデータを受け入れる必要があります）。
サーバーは最終データを送信した後、接続解放メッセージをクライアントに送信します（seq = v + 1、ack = u + 1、FIN = 1、ACK = 1）。サーバーはセミクローズ状態であるため、サーバーは、この時点でのシリアル番号がseq = wであると仮定して、一部のデータが送信される可能性があります。この時点で、サーバーはLAST-ACK（最終確認）状態に入り、クライアントの確認を待ちます。
クライアントはサーバーから接続解放メッセージを受信した後、確認応答（seq = u + 1、ack = w + 1、ACK = 1）を送信し、TIME-WAIT状態に入る必要があります。この時点ではTCP接続は解放されていないことに注意してください。2* MSL（メッセージセグメントの最長寿命）時間を経過する必要があり、クライアントは対応するメッセージをキャンセルした後にCLOSED状態に入ることができます。
サーバーがクライアントから確認を受信している限り、サーバーはすぐにCLOSED状態になります。同様に、TCBが取り消された後、TCP接続は終了します。ご覧のとおり、サーバーはクライアントよりも早くTCP接続を終了します。

TCP FastOpenの概要

ユーザーが初めてSYNパケットをサーバーに送信してTFOCookieを要求すると、
サーバーはユーザーのIP暗号化に従ってCookieを生成し、SYN-ACKとともにユーザーに送信します。
ユーザーはTFOCookieを保存します。
3番目：
ユーザーはSYNパケット（TCP Cookieを運ぶ）を要求とともにサーバーに送信します。
サーバーはCookieをチェックします（Cookieを復号化してIPアドレスを比較するか、IPアドレスを再暗号化して受信したCookieと比較します）。
検証が成功した場合、ユーザーがACKに応答する前に、SYN + ACKをユーザーに送信します。（1RTT）
検証が失敗した場合は、TFO要求で伝送されたデータを破棄し、SYN-ACKに応答して確認します。 SYNシーケンス、および完了は通常の3つのハンドシェイクです。
TFOの2つの主な利点：
ネットワーク使用率の向上（アプリケーションデータはスリーウェイハンドシェイク、1RTT中に送信できます）と
ネットワークセキュリティの向上（SYNフラッド攻撃を防ぐことができます）。

愚かな窓症候群

TCPで使用されるようなウィンドウベースのフロー制御スキームは、「愚かなウィンドウ症候群（SWS）」として知られる状況につながる可能性があります。これが発生した場合、フルレングスのメッセージではなく、接続を介して少量のデータが交換されます。
この現象はどちらの端でも発生する可能性があります。受信者は（大きなウィンドウができるまで待つのではなく）小さなウィンドウをアドバタイズでき、送信者は（他のデータを待つのではなく）少量のデータを送信して送信することもできます。大きなセグメント）。混乱したウィンドウ症候群の現象を回避するために、どちらの端でも対策を講じることができます。

この問題は、送信側と受信側の処理の不一致が原因で、ネットワーク上に多数の小さなパケットが発生する小さなパケットの問題に起因する可能性があります。ネットワーク上の小さなパケットが多すぎないようにするための対策があります。 Nagleアルゴリズムなど、以前に導入されました。スライディングウィンドウメカニズムでは、送信者と受信者のレートが非常に一貫していない場合、この種のばかげた状態も発生します。送信者によって送信されるデータは、大きなヘッダーのみを必要とし、データをほとんど伝達しません。
受信側の場合、受信側が非常に遅く、一度に1バイトまたは数バイトを受信すると、この時点で受信側のバッファがすぐにいっぱいになり、ウィンドウが0バイトとしてアナウンスされます。送信はこの時点で停止します。送信は、アプリケーションが1バイトを受信した後、ウィンドウ通知は1バイトです。送信者は、通知を受信した後、1バイトのデータを送信します。このため、送信効率は非常に低くなります。
同時に、送信側プログラムが一度に1バイトを送信する場合、ウィンドウは十分に大きいものの、送信はバイトごとであり、非常に非効率的です。

参照：
速読オリジナル-TCP / IP（混乱したウィンドウ症候群）
詳細なTCP-IP：混乱したウィンドウ症候群

Q＆A

1.接続時に3方向のハンドシェイクがあり、閉じるときに4方向のハンドシェイクがあるのはなぜですか。

サーバー側がクライアント側からSYN接続要求メッセージを受信すると、SYN + ACKメッセージを直接送信できるためです。
ただし、接続が閉じられたとき、サーバーがFINメッセージを受信しても、すぐにSOCKETを閉じることができない場合があるため、サーバーはACKメッセージで応答し、クライアントに「送信したFINメッセージを受信しました」と伝えることしかできません。サーバー側のすべてのメッセージが送信された後でのみ、 FINメッセージを送信できるため、それらを一緒に送信することはできません。したがって、4ステップのハンドシェイクが必要です。

2. TIME_WAIT状態がCLOSE状態に戻る前に2MSL（最大セグメント生存時間）を通過する必要があるのはなぜですか？

4つのパケットが送信されたと言っても過言ではありませんが、直接CLOSE状態に入ることができますが、ネットワークの信頼性が低く、最後のACKが失われる可能性があると想定する必要があります。したがって、TIME_WAIT状態は、失われる可能性のあるACKパケットを再送信するために使用されます。
クライアントは最終的なACK応答を送信しますが、ACKが失われる可能性があります。**サーバーがACKを受信しない場合、サーバーはFINフラグメントを繰り返し送信し続けます。**したがって、クライアントをすぐに閉じることはできません。サーバーがACKを受信したことを確認する必要があります。
クライアントは、ACKを送信した後、TIME_WAIT状態に入ります。クライアントは、2MSL時間待機するようにタイマーを設定します。この時間内にFINが再度受信されると、クライアントはACKを再送信し、2MSLを再度待機します。
クライアントが2MSLまでFINを再度受信しない場合、クライアントはACKが正常に受信されたと判断し、TCP接続を終了します。
いわゆる2MSLは、MSL（最大セグメント寿命）の2倍です。MSLは、ネットワーク内のセグメントの最大存続時間を指し、2MSLは、送信と応答に必要な最大時間です。

3.接続が確立されたが、クライアントが突然失敗した場合はどうなりますか？

TCPにはキープアライブタイマーがあります。明らかに、クライアントに障害が発生した場合、サーバーは永久に待機できず、リソースが無駄になります。サーバーは、クライアントからの要求を受信するたびにこのタイマーをリセットします。時間は通常2時間に設定されます。クライアントからデータを2時間受信しなかった場合、サーバーはプローブセグメントを送信し、その後、 75毎秒送信されます。10個のプローブパケットを送信しても応答がない場合、サーバーはクライアントに障害があると見なし、接続を閉じます。

4. 2つのハンドシェイクで接続できないのはなぜですか？

まず、チャネルの信頼性が低いことを知る必要がありますが、信頼性の高いデータを送信するには、信頼性の高い接続を確立する必要があります。つまり、データ送信は信頼性が高い必要があります。現時点では、スリーウェイハンドシェイクは理論上の最小値であり、tcpプロトコルで必要とされることは言うまでもなく、信頼性の低いチャネルで信頼性の高いデータを送信するための要件を満たすためのものです。
「コンピュータネットワーク」の本には、スリーウェイハンドシェイクの目的は「無効な接続要求セグメントがサーバーに突然送信されてエラーが発生するのを防ぐことである」と記載されています。
この状況は次のとおりです。クライアントA最初の接続送信されたリクエストメッセージは失われませんでしたが、何らかの理由で特定のネットワークノードでスタックし、接続が解放されてから一定時間まで相手側（サーバー）Bに到達するのが遅れました。元々、これは無効でした。メッセージセグメントですが、Bが無効なメッセージを受信した後、Aから送信された新しい接続要求であると誤って判断したため、B側がAに確認メッセージを送信し、同意を表明しました。接続を確立します。「3ウェイハンドシェイクの場合「を使用しない場合、B側が確認メッセージを送信している限り、新しい接続が確立されたと見なされますが、A側は接続確立要求を送信していないため、B側にデータを送信しません。。エンドがデータを受信しない場合、それは永久に待機するため、エンドBは多くのリソースを浪費します。
「スリーウェイハンドシェイク」が使用されている場合、これは発生しません。エンドBが古いものを受信した後、無効なセグメントの場合、A側が確認を送信します。このとき、Aは接続の確立を要求しないため、B側に確認を送信しません。このとき、B側も接続を認識できます。確立されていません。

参考：
TCPのスリーウェイハンドシェイクと4つの手を振るハンドの理解とインタビューの質問