前に書く
シックス・フラッグス
TCP の urg、ack、psh、rst、syn、および fin は、TCP プロトコルの 6 つのフラグ ビットであり、TCP 接続の確立、維持、および終了を制御するために使用されます。
| フラグビット | ロゴの説明 |
|---|---|
| URG（緊急） | 緊急データを表します。このフラグが設定されている場合、TCP パケット内の緊急データをできるだけ早く送信する必要があることを示します。 |
| ACK（確認） | 受信したデータ パケットのシーケンス番号を確認するために使用される確認を示し、受信側が受信を予期している次のバイトのシーケンス番号を示します。 |
| PSH（プッシュ） | プッシュを示します。このフラグが設定されている場合、送信側はバッファがいっぱいになるのを待たずにできるだけ早くデータを受信側に送信する必要があることを示します。 |
| RST（リセット） | リセットを示します。このフラグが設定されている場合、TCP 接続でエラーが発生し、リセットする必要があること、つまり接続が強制的に閉じられることを示します。 |
| SYN（シンクロ） | 接続を確立するときに同期シーケンス番号を交換するために使用される同期を示します。つまり、送信者と受信者が初期シーケンス番号をネゴシエートします。 |
| FIN（フィニッシュ） | このフラグが設定されている場合、送信者がすべてのデータの送信を終了し、接続を閉じるように要求したことを示します。 |
これらのフラグ ビットのさまざまな組み合わせと設定状態により、さまざまな TCP 接続状態と制御動作を実現できます。
ISN (初期化シリアル番号)
初期化シーケンス番号 (英語: Initial Sequence Number、ISN と呼ばれます)。
3回の握手
基本的なプロセス
3 ウェイ ハンドシェイクは TCP 接続を確立するプロセスであり、これによりクライアントとサーバー間の通信が正常に進行できることが保証されます。スリーウェイ ハンドシェイクの詳細なプロセスは次のとおりです。
1. クライアントは SYN セグメントを送信します: (SYN=1、ACK=0、ISNx)
クライアントは TCP セグメントをサーバーに送信します。このセグメントでは SYN フラグが 1 に設定され、クライアントが接続の確立を要求していることを示します。また、クライアントは、ランダムな初期シーケンス番号 (ISN、ISNx として記録できる) を開始シーケンス番号として選択し、この ISNx をメッセージ セグメントのシーケンス番号フィールドに配置します。
2. サーバーは SYN-ACK メッセージ セグメントを送信します: (SYN=1,ACK=1、イズニー、ISNx+1)
サーバーはクライアントの SYN セグメントを受信すると、応答として TCP セグメントを送信します。SYN フラグは 1 に設定され、サーバーが接続の確立に同意したことを示します。また、サーバーはランダムな初期シーケンス番号 (ISN、ISNy として記録できる) を選択し、この ISNy をメッセージ セグメントのシーケンス番号フィールドに配置します。同時に、サーバーは確認番号フィールドをクライアントの ISNx プラス 1 に設定し、クライアントの最初のシーケンス番号の受信を確認することを示します。このようにして、サーバーとクライアントの両方がお互いの初期シーケンス番号を認識します。
3. クライアントは ACK メッセージ セグメントを送信します: (SYN=0、ACK=1、ISNY+1、ISNx+1)
クライアントはサーバーの SYN-ACK セグメントを受信した後、確認として TCP セグメントを送信します。ACK フラグは 1 に設定され、確認サーバーの最初のシーケンス番号を示します。クライアントは確認番号フィールドをサーバーの ISN プラス 1 に設定し、サーバーの最初のシーケンス番号の受信の確認を示します。同時に、クライアントはシリアル番号フィールドに独自の初期シリアル番号も入力します。
これら 3 回のハンドシェイクの後、クライアントとサーバーの両方が相手の最初のシーケンス番号を知り、相手の最初のシーケンス番号を確認します。この時点で、TCP 接続が正常に確立され、双方がデータ送信を開始できるようになります。
3 ウェイ ハンドシェイク中、送信される各メッセージ セグメントは、次のステップに進む前に相手からの確認を待つ必要があることに注意してください。これにより、双方が互いのパケットを正しく受信し、信頼性の高い接続を確立することができます。
異常事態
スリーウェイ ハンドシェイク中に、タイムアウト、パケット損失、繰り返し送信などの異常な状況が発生する可能性があります。考えられる例外とその処理方法をいくつか示します。
1. タイムアウト: ある段階のメッセージセグメントが一定時間内に相手からの応答を受信しない場合、タイムアウトが発生します。これは、ネットワークの遅延または混雑が原因である可能性があります。タイムアウトを処理する方法は、相手からの応答を受信するか、再送信の最大回数に達するまで、対応するメッセージ セグメントを再送信することです。
2. パケット損失: ネットワーク送信中に、メッセージ セグメントが失われる可能性があります。これは、ネットワークの混雑、リンク障害などが原因である可能性があります。パケットロスへの対処方法としては、一定時間待機し、一定時間内に相手からの応答が無い場合には、該当するメッセージセグメントを再送する。
3. 繰り返し送信: ネットワーク送信中に、メッセージセグメントが繰り返し送信される場合があります。これは、ネットワーク遅延、パケット損失後の再送信などが原因である可能性があります。繰り返しの送信を処理する方法は、受信側が重複セグメントを受信すると、その重複セグメントを無視し、最初に受信したセグメントのみを処理することです。
4. 間違ったシーケンス番号: 3 ウェイ ハンドシェイク中に、受信側が受信したシーケンス番号が間違っている場合、接続の確立が失敗する可能性があります。間違ったシーケンス番号を処理する方法は、受信者が正しいシーケンス番号を受信するまで、対応するセグメントを再送信することです。
5. 接続の拒否: スリーウェイ ハンドシェイク中に、サーバーはクライアントの接続要求を拒否する場合があります。サーバーリソースの不足やアクセス制限などが原因で発生する可能性があります。拒否された接続の処理方法は、クライアントが別の利用可能なサーバーへの接続を試行するか、一定時間待機してから接続要求を再送信することです。
上記は考えられる異常事態とその対処方法の例であり、具体的な対処方法はネットワーク環境やアプリケーションのシナリオによって異なります。実際のアプリケーションでは、接続の信頼性と安定性を確保するために、ネットワーク セキュリティやパフォーマンスの最適化などの要素も考慮する必要があります。
異常なダウンタイム状況
スリーウェイ ハンドシェイク中にサーバーまたはクライアントがダウンすると、さまざまな状況が発生します。
サーバーダウン:
クライアントが SYN セグメントを送信した後にサーバーがダウンすると、クライアントはサーバーの応答を受信できなくなります。クライアントは一定時間待機し、タイムアウト期間内にサーバーからの応答を受信しない場合、クライアントは SYN セグメントを再送信します。このプロセスは、クライアントが最大再送信回数に達するまで複数回繰り返されます。
クライアントが最大再送信回数に達する前にサーバーが回復した場合、クライアントはサーバーから応答を受け取り、接続の確立を続行できます。ただし、クライアントが最大再送信回数に達した後にサーバーが回復すると、接続の確立は失敗します。
クライアントのダウン:
サーバーがクライアントの SYN セグメントを受信した後にクライアントがダウンした場合、サーバーはクライアントの確認を受信できなくなります。サーバーは一定時間待機します。タイムアウト期間内にクライアントから確認が受信されない場合、サーバーは SYN-ACK セグメントを再送信します。このプロセスは、サーバーが再送信の最大回数に達するまで複数回繰り返されます。
サーバーが最大再送信回数に達する前にクライアントが回復した場合、サーバーはクライアントから確認応答を受け取り、接続の確立を続行できます。ただし、サーバーが再送信の最大回数に達した後にクライアントが再開すると、接続の確立は失敗します。
要約すると、3 ウェイ ハンドシェイク中に、一方の当事者がダウンすると、接続の確立は失敗します。この状況を回避するには、適切なタイムアウトと再送信回数を設定することで接続の信頼性を向上させることができます。さらに、ハートビート メカニズムを使用して、接続の生存ステータスを検出し、ダウンタイムを適時に検出して処理することもできます。
心拍の仕組み
ハートビートメカニズムは、接続の生存を検出する方法であり、ハートビートメッセージを定期的に送信することで接続の可用性を確認します。
ネットワーク通信では、送信者は定期的にハートビート メッセージを受信者に送信し、ハートビート メッセージを受信した受信者は、接続がまだ生きていることを示す確認メッセージを送信者に送信できます。
ハートビートのメカニズムは次のように機能します。
1. 送信者はハートビート メッセージを定期的に送信します。
送信者はハートビート メッセージを定期的に (通常は一定の時間間隔で) 受信者に送信します。ハートビート メッセージは、接続の存続ステータスを受信者に通知するために使用される特定のメッセージまたは単純な PING メッセージにすることができます。
2. 受信者はハートビート メッセージを受信します。
受信者は、指定されたポートでハートビート メッセージをリッスンし、ハートビート メッセージの到着を待ちます。ハートビート メッセージを受信すると、受信者は送信者がまだアクティブであることを認識します。
3. 受信者は確認メッセージを送信します。
ハートビート メッセージを受信した後、受信者は接続がまだ生きていることを示す確認メッセージを送信者に送信することを選択できます。確認メッセージは、特定のメッセージまたは単純な PONG メッセージにすることができます。
4. 送信者は確認メッセージを受信します。
ハートビート メッセージを送信した後、送信者は受信者から確認メッセージを受信するまで一定時間待機します。送信者がタイムアウト期間内に確認応答を受信すると、接続がまだ生きていることがわかります。タイムアウト期間を過ぎても確認メッセージが受信されない場合、送信者は接続が切断されたとみなすことができます。
ハートビート メカニズムを通じて、送信者と受信者は定期的にハートビート メッセージを交換し、接続の生存ステータスを確認できます。一定時間内にハートビートメッセージや確認メッセージが受信されない場合は、接続が切断されたものとみなし、接続の再確立やエラー処理などの対応を行うことができます。
ハートビート メカニズムは、接続の安定性と信頼性を維持するために、ネットワーク通信、特に TCP、WebSocket、その他のプロトコルなどの長時間接続のシナリオで広く使用されています。
4回手を振る
基本的なプロセス
4 つのウェーブは、TCP 接続を閉じるために使用されるプロセスであり、次の手順が含まれます。
1. 送信者は接続終了要求を送信します: (FIN=1)
送信者はまず FIN (終了) メッセージ セグメントを受信者に送信します。これは、送信者に送信するデータがなく、接続を終了することを望んでいることを示します。送信者が入力しますFIN_WAIT_1州。
2. 受信者は確認終了要求を送信します: (ACK=1)
送信者の FIN セグメントを受信した後、受信者は送信者に ACK (肯定応答) セグメントを送信して終了要求を確認します。受信者が入りますCLOSE_WAIT州。
3. 受信者は接続終了要求を送信します: (FIN=1,)
受信者はすべてのデータを送信した後、送信者に FIN セグメントも送信します。これは、受信者に送信するデータがなく、接続を閉じることを望んでいることを示します。接続です。受信者が入りますLAST_ACK州。
4. 送信者は確認終了要求を送信します: (ACK=1)
受信者の FIN セグメントを受信した後、送信者は終了要求を確認するために ACK セグメントを受信者に送信します。送信者が入力しますTIME_WAIT州。
TIME_WAIT 状態では、送信者は接続を閉じる前に一定時間 (通常は最大セグメント生存時間の 2 倍、つまり 2MSL) 待機します。
この待機時間は、受信者が送信者の確認を確実に受信し、受信者の確認が送信者にも確実に伝達されるようにするためのものです。
送信者が TIME_WAIT 状態で FIN セグメントを受信した場合、受信者は ACK セグメントを受信していないことを意味します (この時点で受信側は LAST_ACK 状態にあるため、送信側の ACK セグメントが次の状態に移行するのを待っており、ACK セグメントが受信されない場合は FIN セグメントを再送信します。)
その後、送信側は ACK セグメントの送信を続けて TIME_WAIT 状態に入り、時間の終わりまで FIN セグメントが受信されなくなるまで CLOSED 状態になって接続を閉じます。
待機時間が経過すると、送信者は接続を閉じて開始します。閉まっているステータスでは、接続は完全に閉じられています。
送信者から確認を受け取った後、受信者も接続を閉じて入力します。閉まっている州。
4 つのウェーブの間、各メッセージ セグメントは相手側からの確認を必要とすることに注意してください。これは、TCP が信頼性の高いプロトコルであり、確実なデータ送信が保証されるためです。
4 回手を振ることで、双方が交渉して接続の終了を確認し、データの整合性と信頼性を確保できます。