参考チュートリアル：5.6 TCPタイムアウト再送時間の選択 time_bilibili_bilibili
6. TCPタイムアウト再送時間の選択
1. RTT サンプルに基づいてタイムアウト再送信時間を計算します。
(1) 下図に示すように、インターネット上にホスト A とホスト B があり、両者の間に TCP コネクションが確立されているとします (縦軸は時間)。
(2) ホスト A はホスト B に TCP データ セグメント 0 を送信し、現在時刻を記録します。これを受信したホスト B は、対応する確認メッセージ セグメントをホスト A に送信します。確認メッセージセグメントを受信した後、ホスト A は現在時刻を記録します。ホスト A によって記録された 2 つの時間の差が、メッセージ セグメントの往復時間 RTT です。
(3) タイムアウト再送時間 RTO の値を RTT0 (セグメント 0 の往復時間) より小さい値に設定すると、セグメントの不要な再送が発生し、ネットワーク負荷が増加します。時間 RTO の値が RTT0 よりもはるかに大きいと、再送信が長時間遅延し、ネットワークのアイドル時間が増加し、送信効率が低下します。
(4) タイムアウト再送時間 RTO の値は、メッセージセグメントの往復時間 RTT よりも若干大きい値に設定する必要がありますが、TCP の下位層は複雑なインターネット環境であり、ホストが送信するメッセージセグメントAは高速LANのみを通過する場合もあれば、複数の低速ネットワークを通過する場合もあり、各IPデータグラムの転送経路が異なる場合もあります。
(5) 次の図に示すように、ホスト A は TCP データ セグメント 1 をホスト B に送信します。それを受信した後、ホスト B は対応する確認セグメントをホスト A に送信します。ホスト A が測定したセグメントの往復時間はこれです。時間は RTT1 です。明らかに、RTT1 は RTT0 よりもはるかに大きいです。前に決定したように、再送信タイムアウト RTO がまだ RTT0 よりわずかに大きい場合、これはデータ セグメント 1 には不適切であり、セグメントの不必要な再送信が発生します。
(6)特定の測定から取得した RTT サンプルを直接使用してタイムアウト再送信時間 RTO を計算することはできませんが、各測定から取得した RTT サンプルを使用して加重平均往復時間を計算することができることがわかります(また、平滑化往復時間として知られています)。
① 最初の RTT サンプルを測定したときは、の値がそのまま最初の RTT サンプルの値として取り込まれ、以降 RTT サンプルが測定されるたびに、
下図の計算式に従って新しい値が計算されます。
②この方法で得られる加重平均往復時間RTTSは、実測RTT値よりも滑らかです。
③明らかに、タイムアウト再送信時間 RTO は加重平均往復時間よりわずかに大きくなければなりません。
(7) RFC6298 では、次の式を使用してタイムアウト再送信時間 RTO を計算することを推奨しています。
2. 往復時間 RTT の測定は比較的複雑です。
(1) 下図のように、ホスト A がホスト B に TCP データセグメントを送信しましたが、送信中にセグメントが消失し、再送タイマがタイムアウトすると、ホスト A はセグメントを再送信します。データセグメントを受信した後、ホスト B はホスト A に確認セグメントを送信します。
① ホスト A は、確認セグメントを受信した後、それが元のセグメントの確認応答であるか、再送セグメントであるかを判断できません。
② このメッセージセグメントは実際には再送されたメッセージセグメントの確認ですが、ホスト A がこの確認を元のメッセージセグメントの確認と誤って認識すると、計算される RTTS と RTO が大きくなりすぎ、伝送効率が低下します。
(2) 下図に示すように、ホスト A はホスト B に TCP データセグメントを送信します。データセグメントを受信したホスト B は、ホスト A に確認メッセージセグメントを送信します。しかし、何らかの理由により、確認メッセージセグメントはホスト A に送信されません。通常の時間内にホスト A に到達すると、必然的にホスト A がタイムアウトになり、以前に送信されたデータ セグメントが再送信されます。
① ホスト A は、遅延確認セグメントを受信した後、そのセグメントが元のセグメントの確認応答であるか、再送セグメントであるかを判断できません。
② このメッセージセグメントは、実際には元のメッセージセグメントの確認ですが、ホスト A がこの確認を再送メッセージセグメントの確認と誤って認識すると、計算される RTTS と RTO が小さくなり、不要なメッセージセグメントの再送が発生します。そしてネットワーク負荷が増加します。
(3) 送信側がタイムアウトして再送した場合、確認セグメントを受信した際に、そのセグメントが元のセグメントの確認なのか、再送セグメントの確認なのかを判断することができず、正確に計測することができない。 RTT が長いため、タイムアウト再送時間 RTO を正しく計算できません。
(4)タイムアウト再送が発生した場合にラウンドトリップ時間 RTT を正確に測定できないという問題に対応して、 Karn は次のアルゴリズムを提案しました。加重平均ラウンドトリップ時間 RTT sを計算する際、メッセージセグメントが再送信される限り、往復時間の RTT サンプルは使用されません。つまり、再送信が発生した場合、RTT は再計算されず、タイムアウト再送信時間 RTO も再計算されません。
① しかし、Karn が提案したアルゴリズムは新たな問題を引き起こしました。メッセージセグメントの遅延が突然大幅に増加し、この遅延が長時間続くと、本来の再送時間内に確認メッセージセグメントが受信されなくなります。 , そのため、メッセージ セグメントは再送信されます。ただし、Karn アルゴリズムによれば、再送信されたメッセージ セグメントの往復時間サンプルは考慮されません。このようにして、タイムアウト再送信時間を更新することができず、メッセージ セグメントが再送信されます。繰り返し再送信されます。
② したがって、Karn アルゴリズムを変更する必要があります:メッセージ セグメントが再送信されるたびに、タイムアウト再送信時間 RTO が増加します。一般的なアプローチは、新しい RTO 値を古い RTO 値の 2 倍に設定することです。
3. TCPタイムアウト再送時間の計算例
7. TCPの信頼性のある伝送の実装
1. 確実な伝送を実現するTCPの例
(1) 下図はインターネット上に 2 つのホストがあり、その間に TCP 接続が確立されており、データ送信は一方向のみであり、ネットワークに輻輳の問題はないと仮定しています。
(2) TCP のスライディング ウィンドウはバイト単位で測定されます。下の図は、送信側が送信するデータ バイトのシーケンス番号を示しています。
(3) 送信者が受信者から確認セグメントを受信すると仮定します。
①メッセージセグメントのヘッダーのウィンドウフィールド rwnd の値は 20 で、受信側が受信ウィンドウのサイズが 20 バイトであることを示し、確認番号フィールド ack の値は 31 で、受信側が受信ウィンドウのサイズが 20 バイトであることを示します。次の受信を希望しています。 データのシーケンス番号は 31 で、シーケンス番号 30 までのデータはすべて正しく受信されています。
②送信者は、これら 2 つのフィールドの値に基づいて独自の送信ウィンドウを構築し、自身の送信ウィンドウ サイズを 20 に設定し、シーケンス番号 31 ～ 50 に移動します。
(4)送信者が受信者からの確認を受信しない場合、送信ウィンドウ内のすべてのデータを順番に送信できますが、タイムアウト後に処理できるように、送信されたすべてのデータは確認を受信する前に一時的に保持される必要があります。再送信時に使用します。
①送信ウィンドウの後端の後ろの部分は、送信および受信確認が行われたデータバイトのシーケンス番号であり、これらのデータバイトは送信バッファに格納する必要がなくなったことは明らかであり、削除することができます。送信ウィンドウの後縁の動きには 2 つの可能性があります。
[1] 新しい確認は受信されず、送信ウィンドウの後端は移動しません。
[2] 新しい確認を受信すると、送信ウィンドウの後端が前方に移動します。
②送信ウィンドウの先頭部分は、現在送信が許可されていないデータバイトのシーケンス番号です。送信ウィンドウの前端の動きには 4 つの可能性があります。
[1] 通常、送信ウィンドウの前端は常に前進しています。
[2] 新たな確認を受信しない場合、相手の通知のウィンドウサイズは変化せず、フロンティアは先に進みません。
[3] 新しい確認を受信しますが、送信ウィンドウの前端が動かないように、相手の通知ウィンドウが縮小されます。
[4] 相手からの通知ウィンドウが縮小し、送信ウィンドウの前端が後方に縮小する場合があります。(TCP 標準はこのケースを強くサポートしていません)
(5) ここで、送信者が送信ウィンドウに通し番号 31 ～ 41 のデータをカプセル化し、いくつかの異なるメッセージセグメントに分けて送信するとします。このとき、送信ウィンドウの位置は変更されず、通し番号のデータが送信されます。送信ウィンドウの 31 ～ 41 は送信済みですが確認が受信されません。シリアル番号 42 ～ 50 のデータは送信可能ですがまだ送信されていません。
(6) 送信ウィンドウのステータスをマークおよび維持するために、スライディング ウィンドウ メカニズムをプログラムする場合は、3 つのポインタ P1、P2、および P3 を使用して、それぞれ対応するバイト シリアル番号を指すことができます。
①P1以下の部分は送信確認済みの部分です。
②P3以上のものは送信できません。
③ P3-P1 は送信ウィンドウのサイズです。
④ P2-P1 は、送信されたがまだ確認を受信していないバイト数を決定できます。
⑤ P3-P2 は送信許可されているがまだ送信されていないバイト数を取得できます。
(7) 受信ウィンドウのサイズは現在 20 ですが、30 日までの受信ウィンドウの外側のデータは、確認に応じて送信され、申請プロセスに渡されたデータであるため、これらのデータを保持する必要はなく、受信キャッシュから削除可能、削除済み、受信窓内のデータNo.31～50は受信可能、受信窓外のデータNo.51以降は現在受信不可。
(8) 次に、送信側が先に送信したデータ No.32 と No.33 をカプセル化したメッセージセグメントが受信側に到着し、データ通番が受信窓内に収まるため、受信側はこれを受信し、受信バッファに格納します。ただし、データ No.31 がまだ到着していないため、順番がずれて到着したデータです（データ No.31 が失われたり、他のネットワークに滞留している可能性があります）。
(9)受信側は、順番に受信したデータの中で最も大きいシーケンス番号しか確認できないため、受信側が送信する確認メッセージセグメントの確認シーケンス番号は依然として 31 です、つまり、データ番号 31 の受信を希望します。フィールドの値は 20 のままで、受信側が受信ウィンドウのサイズを変更していないことを示します。
(10) 送信側は確認メッセージセグメントを受信し、それがデータ No.31 の重複確認であることを知ると、受信側が順序を間違えて到着したデータを受信したことがわかります。データNo.31については初めての重複確認であるため、送信者はすぐにデータを再送することはない。また、受信側から通知されたウィンドウ サイズは 20 のままであるため、送信側は送信ウィンドウ サイズを 20 のままにします。
(11) ここで、データ No.31 をカプセル化したメッセージセグメントが受信機に到着すると、受信機はメッセージセグメントを受信し、カプセル化されたデータ No.31 を受信キャッシュに格納することで、受信データ 31 ～ 33 を格納できるようになります。データはアプリケーション プロセスに配信され、受信ウィンドウが 3 つのシーケンス番号だけ前方に移動され、確認メッセージ セグメントが送信者に送信されます。
(12) 受信側は、確認シーケンス番号が 34 である確認メッセージ セグメントを送信します。これは、受信側がシーケンス番号 33 までのすべてのデータを受信し、現在データ番号 34 の受信を希望していることを示します。ウィンドウ フィールドの値は 20 のままで、受信側の受信ウィンドウのサイズが変更されていないことを示します。
(13) さらにいくつかのデータメッセージセグメントが受信機に到着するとします. これらはデータ No. 37, 38, 40 でカプセル化されています. これらのデータのシーケンス番号は受信ウィンドウ内にありますが、それらはすべて受信ウィンドウ外に到着したデータですシーケンスは、最初に受信キャッシュに一時的にのみ保存できます。
(14) 次に、受信側が先に送信した確認メッセージセグメント(ack=34)が送信側に到着し、それを受信した送信側は送信ウィンドウをシーケンス番号3つ分だけ前にスライドさせますが、送信ウィンドウのサイズは変化しません。新しいシーケンス番号があることを確認します。51 ～ 53 は送信ウィンドウに入り、シーケンス番号 31 ～ 33 は送信ウィンドウの外に移動します。これで、受信者の確認により、データ No. 31 ～ 33 は送信バッファから削除できます。彼らは受け入れられたからです。
(15) 送信者は送信ウィンドウ内のシーケンス番号 42 ～ 53 のデータをいくつかの異なるメッセージ セグメントにカプセル化して送信し続けますが、送信ウィンドウ内のシーケンス番号がすべて使い果たされ、送信者は確認を受信していません。この場合、新たなデータの送信はできず、送信ウィンドウ内にあるシーケンス番号の送信データを長時間受信しないとタイムアウトが発生し、再送が発生します。
2. TCPで確実な通信を実現する際の注意点
(1) 送信者の送信ウィンドウは受信者の受信ウィンドウに応じて設定されますが、同時に、送信者の送信ウィンドウが受信者の受信ウィンドウと同じ大きさであるとは限りません。
① これは、ネットワーク送信ウィンドウの値には一定のタイムラグが必要であり、この時間はまだ不確実であるためです。
② さらに、送信者は、現在のネットワークの混雑状況に応じて、送信ウィンドウのサイズを適切に縮小することもできます。
(2) TCP には、順序どおりに到着しないデータの処理方法に関する明確な規定がありません。
① 受信側が順序どおりに到着しないすべてのデータを破棄すると、受信ウィンドウの管理は簡単になりますが、送信側がさらに多くのデータを繰り返し送信するため、ネットワーク リソースの利用に悪影響を及ぼします。
②TCPは通常、順序が乱れて到着したデータを受信ウィンドウに一時的に格納し、バイトストリームの欠落バイトを受信した後、上位層のアプリケーションプロセスに順番に渡します。
(3) TCP では、受信側に累積確認応答メカニズムとピギーバック確認応答メカニズムが必要であり、これにより送信オーバーヘッドを削減できます。受信者は適切なタイミングで確認を送信したり、送信するデータがあるときに確認情報を送信したりできます。
①受信者は確認の送信を遅らせすぎないでください。そうしないと、送信者が不必要にタイムアウトして再送信し、ネットワーク リソースが無駄になります。TCP 標準では、確認応答の遅延が 0.5 秒を超えてはいけないと規定されており、最大長の一連のセグメントを受信した場合、1 セグメントおきに確認応答を送信する必要があります [RFC 11221]。
②ほとんどのアプリケーションは同時に両方向にデータを送信することはめったにないため、Piggy の確認応答は実際にはあまり頻繁に発生しません。
(4) TCP 通信は全二重通信であり、通信の各当事者はメッセージセグメントを送受信するため、各当事者には独自の送信ウィンドウと受信ウィンドウがあります。これらのウィンドウについて話すときは、必ず理解してください。窓ですよ。
8. TCPトランスポート接続管理
1. TCPトランスポート接続管理の概要
(1) TCP は、トランスポート接続に基づいて TCP セグメントを送信するコネクション指向のプロトコルです。
(2) TCP トランスポート接続の確立と解放は、あらゆるコネクション指向の通信において不可欠なプロセスです。
(3) TCP トランスポート接続には次の 3 つの段階があります。
① TCP 接続を確立します。つまり、「3 メッセージ ハンドシェイク」によって TCP 接続を確立します。(TCP 接続を確立するプロセスは「ハンドシェイク」に例えられます)
②データ送信、つまり確立されたTCPコネクションに基づく確実なデータ送信。
③コネクションを解放します。つまり、データ送信が完了した後、「4 つのメッセージを振る」ことによって TCP コネクションを解放します。(TCP が接続を解放するプロセスを「手を振る」ことと比較してください)
(4) TCP のトランスポート接続管理は、トランスポート接続の確立と解放が正常に進行できることを保証することです。
2. TCP接続の確立
(1) TCP コネクションの確立には、次の 3 つの問題を解決する必要があります。
①TCP双方が相手の存在を知ることができるようにする。
② TCP 当事者がいくつかのパラメータ (最大ウィンドウ値、ウィンドウ拡張オプションとタイムカットオフ オプションを使用するかどうか、サービス品質など) をネゴシエートできるようにします。
③TCP 当事者がトランスポートエンティティのリソース (キャッシュサイズ、接続テーブル内の項目など) を割り当てられるようにします。
(2) 「3 メッセージ ハンドシェイク」を使用して接続を確立する TCP の具体的なプロセス:
① 以下の図は、TCP に基づいて通信する必要がある 2 つのホストを示しています。一方のホストのアプリケーション プロセスは、積極的にTCP 接続の確立を開始します。このプロセスはTCP クライアントと呼ばれます。もう一方のホストは、受動的に TCP 接続の確立を待ちます。アプリケーション プロセスはTCP サーバーと呼ばれます。「ハンドシェイク」 (つまり、TCP 接続の確立) では、TCP クライアントと TCP サーバーの間で 3 つの TCP セグメントを交換する必要があります。
②最初は両端のTCPプロセスはクローズされています。最初に、TCP サーバー プロセスは、 TCP 接続テーブル、送信および受信バッファへのポインタ、再送信キューへのポインタ、現在の送受信シーケンスなどの重要な情報を TCP 接続に保存するための送信制御ブロックを作成します。数字など その後、TCP サーバー プロセスは待機状態になり、TCP クライアント プロセスからの接続要求を待ちます。TCP サーバー プロセスは、TCP クライアント プロセスからの接続要求を積極的に開始するのではなく、受動的に待機するため、受動的に接続を開くと呼ばれます。
③ TCP クライアントプロセスも、 TCP コネクションを確立する際、まず送信制御ブロックを作成し、TCP サーバプロセスに TCP コネクション要求セグメントを送信し、同期送信状態となります。TCP 接続要求セグメントのヘッダー内の同期ビット SYNは 1 に設定され、これが TCP 接続要求セグメントであることを示します。シーケンス番号フィールドseq は、TCP によって選択された初期シーケンス番号として初期値 xに設定されます。クライアントプロセス( TCP SYN が 1 に設定されたメッセージセグメントはデータを運ぶことができないと規定されていますが、シーケンス番号が消費されます)。TCP 接続の確立は TCP クライアントによって開始されるため、「接続をアクティブに開く」と呼ばれます。
④ TCP サーバプロセスは、TCP 接続要求セグメントを受信後、接続の確立に同意すると、TCP クライアントプロセスに TCP 接続要求確認セグメントを送信し、同期受信状態に入ります。TCP 接続要求確認メッセージ セグメントのヘッダー内の同期ビット SYN と確認ビット ACKは両方とも 1 に設定され、これが TCP 接続要求確認メッセージ セグメントであることを示します。シーケンス番号フィールドseqは初期値 yに設定されます。、TCP サーバー プロセスとして選択された初期シーケンス番号、確認番号フィールドackの値はx+1に設定され、これはTCP クライアント プロセスによって選択された初期シーケンス番号の確認です( SYN が 1 に設定されているため、このセグメントはデータを伝送できません。シリアル番号も同時に消費されます)。
⑤ TCP クライアントプロセスは、TCP 接続要求確認メッセージセグメントを受信した後、通常の TCP 確認メッセージセグメントを TCP サーバプロセスに送信し、接続確立状態に入ります。TCP 確認応答メッセージ セグメントのヘッダー内の確認応答ビット ACKは 1 に設定され、これが通常の TCP 確認応答メッセージ セグメントであることを示します。TCPクライアントによって最初に送信された TCPであるため、シーケンス番号フィールドseq はx+1に設定されます。 processメッセージ セグメントのシーケンス番号は xであり、データを伝送しないため、2 番目のメッセージ セグメントのシーケンス番号は x+1 です。確認番号フィールドack は、によって選択された初期シーケンス番号であるy+1に設定されます。TCP サーバー プロセスの確認応答( TCP では、通常の TCP 確認応答メッセージ セグメントでデータを搬送できると規定していますが、データを搬送しない場合、シーケンス番号は消費されません。この場合、次に送信されるデータ セグメントのシーケンス番号は依然として x+ です。 1）。
⑥ TCP サーバプロセスも、通常の TCP確認メッセージセグメントを受信した後、コネクション確立状態になります。これで、両方の TCP パーティが接続確立状態になり、確立された TCP 接続に基づいて信頼性の高いデータ送信を実行できるようになります。
(3) TCP クライアントプロセスが TCP 接続要求確認メッセージセグメントを受信した後に TCP サーバープロセスに送信される通常の TCP確認メッセージセグメントは冗長ではないため、次の例でこの点を示します。
① TCP クライアントプロセスは TCP 接続要求セグメントを送信しますが、セグメントは一部のネットワークノードに長時間滞留するため、時間の経過とともにセグメントの再送が避けられません。
② 再送されたメッセージセグメントが TCP サーバプロセスで正常に受信されたと仮定し、TCP サーバプロセスは TCP クライアントプロセスに TCP 接続要求確認メッセージセグメントを送信し、接続確立状態に移行します。
③「2メッセージハンドシェイク」が採用されている場合、つまりTCPクライアントプロセスが通常のTCP確認メッセージセグメントを送信する必要がない場合、TCPサーバープロセスはTCP接続要求確認メッセージを送信した後、接続確立状態に入ります。セグメント。
④TCP クライアントプロセスは、TCP 接続要求確認メッセージセグメントを受信後、TCP コネクション確立状態に移行しますが、このメッセージセグメントに対する通常の確認メッセージセグメントを TCP サーバプロセスに送信しません。
⑤ 現在、双方の TCP はコネクション確立状態にあり、相互にデータを送信することができますが、その後、「4 つのメッセージ ウェーブ」によってコネクションが解放され、双方の TCP はクローズ状態になります。
⑥一定時間が経過すると、以前にネットワーク上に留まっていた失敗した TCP 接続要求セグメントが TCP サーバー プロセスに到達すると、TCP サーバー プロセスはこれを TCP クライアント プロセスによって開始された新しい TCP 接続要求であると誤って認識し、送信します。 TCP サーバープロセスへの要求 クライアントプロセスは、TCP 接続要求確認メッセージセグメントを送信し、接続確立状態に入ります。
⑦メッセージセグメントが TCP クライアントプロセスに到達する TCP クライアントプロセスは新たな TCP 接続要求を開始しておらずクローズ状態であるため、メッセージセグメントを無視しますが、TCP サーバープロセスは接続確立状態に入っています。メッセージ セグメントが接続確立状態に入ったと考えられます。新しい TCP 接続が確立され、TCP クライアント プロセスがデータを送信するのを待っています。これにより、TCP サーバー プロセスが配置されているホストで大量のリソースが浪費されます。
3. TCPコネクションの解放
(1) TCP は「4 つのメッセージ ウェーブ」によって接続を解放します。データ送信が完了すると、TCP 通信の双方が接続を解放できます。
(2) 「4 つのメッセージ ウェーブ」を使用して接続を解放する TCP の具体的なプロセス:
① 現在、TCP クライアントプロセスと TCP サーバープロセスの両方がコネクション確立状態にあるとします。このとき、TCP クライアントプロセスを使用しているアプリケーションプロセスは、TCP コネクションを積極的に閉じるように通知します。TCP クライアントプロセスは、TCP コネクションを送信します。接続を解放し、メッセージセグメントを終了し、終了待ち 1 状態に入ります。このメッセージ セグメントのヘッダーにある終了ビット FIN と確認ビット ACK の値は両方とも 1 に設定され、これが TCP 接続解放メッセージ セグメントであることを示し、以前に受信したメッセージ セグメントも確認します。番号フィールドse q ack の値は、TCP クライアント プロセスによって以前に送信されたデータの最後のバイトのシーケンス番号に 1 を加えたものに等しいuに設定され、確認番号フィールドackの値は次のように設定されます。vは、以前に TCP クライアント プロセスによって受信されたデータと等しく、最後のバイトのシーケンス番号が 1 増加します。( TCP では、終了ビット PIN が 1 に等しいメッセージ セグメントは、データを運ばない場合でもシーケンス番号を消費することを規定しています)。
② TCP サーバプロセスは、TCP コネクション解放セグメントを受信後、通常の TCP 確認セグメントを送信し、シャットダウン待ち状態に移行します。セグメントのヘッダー内の確認応答ビット ACK の値は 1 に設定され、これが通常の TCP 確認応答セグメントであることを示します。シーケンス番号フィールドseqの値は、データの値と等しいvに設定されます。TCP サーバー プロセスによって以前に送信された最後のバイトのシーケンス番号は 1 増加します。これは、以前に受信した TCP 接続解放セグメント内の確認番号とも一致します。確認番号フィールドackの値はuに設定されます。+1、これはTCP 接続解放セグメントへの応答です。
③ TCP サーバー プロセスは、この時点で、TCP クライアント プロセスが自身の TCP 接続を切断する必要があることを上位アプリケーション プロセスに通知する必要があり、このとき、 TCP クライアント プロセスから TCP サーバー プロセスへの接続が解放されます。この時点の TCP 接続は半クローズ状態、つまり、TCP クライアント プロセスには送信するデータがありませんが、TCP サーバー プロセスにまだ送信するデータがある場合、TCP クライアント プロセスはそれを受信する必要があります。つまり、TCP サーバー プロセスから TCP クライアント プロセスへの接続が閉じられていないため、この状態はしばらく続く可能性があります。
④ TCP クライアントプロセスは、TCP 確認メッセージセグメントを受信後、終了待ち 2 状態に入り、TCP サーバプロセスから送信される TCP コネクション解放メッセージセグメントを待ちます。TCP サーバー プロセスを使用するアプリケーション プロセスに送信するデータがない場合、アプリケーション プロセスは TCP サーバー プロセスに接続を解放するように通知します。TCP 接続の解放は TCP クライアント プロセスによって能動的に開始されるため、TCP サーバー プロセスによる TCP 接続の解放は、接続の受動的終了と呼ばれます。
⑤ TCP サーバープロセスは TCP コネクション解放メッセージセグメントを送信し、最終確認状態に入る。このメッセージ セグメントのヘッダーにある終了ビット FIN と確認ビット ACK の値は両方とも 1 に設定され、これが TCP 接続解放メッセージ セグメントであることを示し、以前に受信したメッセージ セグメントも確認します。シーケンス番号フィールドseqの値はwです。これは、TCP 接続が半分閉じられているときに、TCP サーバー プロセスがさらにデータを送信した可能性があるためです (w は、以前のデータの最後のバイトのシーケンス番号に等しい) TCP サーバープロセスによって送信 + 1 ); confirm 数値フィールドackの値はu+1で、以前に受信した TCP 接続解放メッセージセグメントの繰り返しの確認です。
⑥ TCP クライアントプロセスは、TCP コネクション解放メッセージセグメントを受信した後、そのメッセージセグメントに対する通常の TCP 確認メッセージセグメントを送信し、時間待ち状態に入る必要があります。このセグメントのヘッダーの確認応答ビットACKの値は1に設定され、これが通常の TCP 確認応答セグメントであることを示します。TCPクライアント プロセスが以前に送信したため、シーケンス番号フィールドseqの値はu+1に設定されます。接続解放セグメントはデータを伝送しませんが、シーケンス番号を消費します。確認番号フィールドackの値は、受信した TCP 接続解放セグメントの確認であるw+1に設定されます。
⑦ TCP サーバープロセスは、通常の TCP 確認メッセージセグメントを受信した後クローズ状態に入りますが、TCP クライアントプロセスはクローズ状態に入る前に 2MSL を通過する必要があります。MSL は、最長のメッセージ セグメントの存続期間を意味します。RFC793 文書では 2 分を推奨しています (TCP では、特定の状況に応じて、さまざまな実装でより小さい MSL 値を使用できます)。これは、TCP クライアント プロセスが時間を入力した後 4 分間待機する必要があることを意味します。待機状態。シャットダウン状態に入るまでの時間。
(3) TCP クライアント プロセスは、最後の確認メッセージ セグメントを送信した後、直接シャットダウン状態に移行することはできません。最初に時間待機状態に移行する必要があります。次の例は、この点を示しています。
① TCP サーバプロセスは、TCP 接続解放メッセージセグメントを送信し、最終確認状態に入りますが、メッセージセグメントを受信した TCP クライアントプロセスは、通常の TCP 確認メッセージセグメントを送信し、時間待ち状態ではなくクローズ状態に入ります。 TCP クライアント プロセス TCP 確認メッセージ セグメントが失われるため、必然的に TCP サーバー プロセスがタイムアウトになり、以前に送信された TCP 接続解放メッセージ セグメントが再送信されます。TCP サーバー プロセスはまだ最終確認状態のままです。
②再送された TCP コネクション解放メッセージセグメントは TCP クライアントプロセスに到達しますが、TCP クライアントプロセスはクローズ状態にあるためメッセージセグメントを無視し、必然的に TCP サーバプロセスは TCP コネクション解放メッセージセグメントを繰り返し再送し、継続して送信することになります。最終確定状態となり、クローズ状態に移行できません。
③時間待機状態とこの状態の 2MSL 継続時間により、TCP サーバー プロセスが最後の TCP 確認メッセージ セグメントを受信し、クローズ状態に入ることが保証されることがわかります。さらに、TCP クライアント プロセスが最後の TCP 確認メッセージ セグメントを送信し、2MSL を通過した後、この接続中に生成されたすべてのメッセージ セグメントがネットワークから消えるため、古い接続からの次の新しいメッセージ セグメントは、 TCP 接続では表示されません。
(4) TCP のキープアライブ タイマー:
① TCP 双方が接続を確立した後、TCP クライアント プロセスが配置されているホストに突然障害が発生したとします。当然、今後、TCP サーバー プロセスは TCP クライアント プロセスからデータを受信できなくなります。 TCP サーバープロセスの無駄な時間を防ぐための対策、待機する場合の対策はキープアライブタイマーです。
②TCP サーバープロセスは、TCP クライアントプロセスからデータを受信するたびに、キープアライブタイマーをリセットして開始し、キープアライブタイマー期間内に TCP クライアントプロセスからデータを受信しなかった場合、キープアライブタイマーが満了すると、キープアライブタイマーがリセットされます。つまり、TCP サーバー プロセスは検出セグメントを TCP クライアント プロセスに送信し、その後 75 秒ごとに送信します。10 個のプローブ セグメントを続けて送信した後も TCP クライアント プロセスからの応答がない場合、TCP サーバー プロセスは、TCP クライアント プロセスが存在するホストに障害があると判断し、接続を閉じます。
9. TCPセグメントのヘッダフォーマット
1. アプリケーションメッセージの TCP 処理
(1) TCP は信頼性の高い伝送を実現するために、アプリケーションプロセスから配信されるアプリケーションメッセージをバイトストリームとみなし、TCP 送信バッファに格納するバイトストリーム指向のアプローチを採用しています。ただし、TCP がデータを送信するときは、送信バッファから一部またはすべてのバイトを取り出し、ヘッダーを追加してTCP セグメントにしてから送信します。
(2) TCP メッセージセグメントはヘッダーとデータペイロードの 2 つの部分で構成され、TCP のすべての機能はヘッダー内の各フィールドの役割に反映されます。
2. TCPセグメントヘッダーの各フィールドの役割
(1) TCP セグメントのヘッダ形式は、IP データグラムのヘッダ形式と同様で、20 バイトの固定ヘッダと最大 40 バイトの拡張ヘッダで構成されます。
(2)送信元ポートフィールドは16 ビットを占め、送信元ポート番号を書き込むために使用され、送信元ポート番号はTCP セグメントを送信したアプリケーション プロセスを識別するために使用されます。
(3)宛先ポートフィールドは16 ビットを占め、宛先ポート番号を書き込むために使用され、宛先ポート番号はTCP セグメントを受信するアプリケーション プロセスを識別するために使用されます。
(4)シーケンス番号フィールドは32 ビットを占め、TCP の信頼性の高い伝送の実装に関連しており、シーケンス番号が最後の番号まで増加すると、次のシーケンス番号は 0 から始まります。シーケンス番号フィールドの値は、この TCP セグメントのデータ ペイロードの最初のバイトのシーケンス番号を示すために使用されます。
(5)確認番号フィールドは、TCP の確実な伝送に関係する 32 ビットを占め、確認番号が最後まで増加すると、次の確認番号は 0 から始まります。確認番号フィールドの値は、相手の次の TCP セグメントから受信されることが予想されるデータ ペイロードの最初のバイトのシーケンス番号を示すために使用されます。これは、以前に受信したすべてのデータの確認でもあります(確認番号が = の場合) 。 n は、シーケンス番号 n-1 までのすべてのデータが正しく受信されており、シーケンス番号 n のデータが受信されることが期待されていることを示します。
(6)確認フラグビット ACK は1 ビットを占め、値が 1 の場合は確認番号フィールドが有効、値が 0 の場合は確認番号フィールドが無効となります。(TCP では、接続の確立後に送信されるすべての TCP セグメントの ACK が 1 に設定されている必要があると規定しています)
(7)データ オフセット フィールドは4 バイト単位で 4 ビットを占め、TCP メッセージ セグメントのデータ ペイロード部分の先頭が TCP メッセージ セグメントの先頭からどのくらい離れているかを示すために使用されます。TCPセグメントのヘッダ長を示します。ヘッダーの固定長は 20 バイトであるため、データ オフセット フィールドの最小値はバイナリで 0101 になります。これに最大拡張ヘッダーの 40 バイトを加えた場合、ヘッダーの最大長は 60 バイトであるため、データの最大値はオフセットフィールドはバイナリの 1111 です。
(8)予約フィールドは6 ビットを占め、将来の使用のために予約されていますが、現在は 0 に設定する必要があります。
(9)ウィンドウ フィールドはバイト単位で 16 ビットを占め、このメッセージ セグメントを送信する側の受信ウィンドウ サイズを示すために使用されます。ウィンドウ値は、受信者が送信者に送信ウィンドウを設定させるための基礎として機能します(送信ウィンドウのサイズも輻輳ウィンドウのサイズに依存します。つまり、受信ウィンドウと輻輳ウィンドウから小さい方を選択する必要があります)。
(10)チェックサム フィールドは16 ビットを占め、TCP メッセージ セグメント全体の送信中にビット エラーがあるかどうかをチェックするために使用されます。UDP と同様に、チェックサムを計算するときに、TCP セグメントの前に 12 バイトの疑似ヘッダーが追加されます。
(11)同期フラグビット SYN は1 ビットを占め、TCP コネクション確立時のシーケンス番号の同期に使用されます。
① TCP クライアントプロセスが送信する TCP 接続要求セグメントでは、ヘッダーの同期フラグビット SYN が 1 に設定され、これが TCP 接続要求セグメントであることを示します。
② TCP サーバプロセスが送信する TCP 接続要求確認セグメントは、ヘッダ内の同期フラグビット SYN が 1 に設定され、確認ビット ACK も 1 に設定され、TCP 接続要求確認セグメントであることを示します。
(12)終了フラグビット FIN は1 ビットを占め、TCP コネクションを解放するために使用されます。TCP クライアントプロセスか TCP サーバープロセスかに関係なく、それらが送信する TCP コネクション解放セグメントのヘッダーの終了フラグビット FIN が 1 に設定され、これが TCP コネクション解放セグメントであることを示します。
(13)リセットフラグビット RST は1 ビットを占め、TCP コネクションをリセットするために使用され、RST=1 のときは TCP コネクションが異常であり、コネクションを解放して再確立する必要があることを示します。RST を 1 に設定すると、不正なセグメントを拒否したり、TCP 接続を開くことを拒否したりすることもできます。
(14)プッシュ フラグ ビット PSH は1 ビットを占め、プッシュ操作の実装に使用されます。受信側の TCP は、フラグ ビット 1 を持つメッセージ セグメントを受信した後、できるだけ早くセグメントをアプリケーション プロセスに渡します。上向きに配信する前に、受信バッファがいっぱいになるまで待つ必要があります。
(15)緊急ポインタフィールドはバイト単位で 16 ビットを占め、緊急データの長さを示すために使用されます。
①緊急ポインタは、このセグメントのデータロード部に緊急データがどのくらいの期間含まれているかを示し、緊急データ以降は通常データとなります。
② 送信者に緊急データがある場合、緊急データを送信バッファの先頭にキューイングし、すぐに TCP セグメントにカプセル化して送信できます。
③ 受信機は、緊急フラグが 1 のメッセージセグメントを受信すると、緊急ポインタフィールドの値に応じて、メッセージセグメントのデータペイロード部から緊急データを取り出し、アプリケーションプロセスにそのまま引き渡します。受信バッファでキューイングします。
(16)緊急フラグビット URG は1 ビットを占め、値が 1 の場合は緊急ポインタフィールドが有効、値が 0 の場合は緊急ポインタフィールドが無効となります。
(17) TCP セグメントヘッダーには、20 バイトの固定部分に加えて、最大 40 バイトのオプション部分があり、オプションを追加することで TCP の機能を拡張できます。
①最大セグメント長 MSS オプション: TCP セグメントのデータペイロード部分の最大長を示すために使用されます。
②ウィンドウ拡張オプション：ウィンドウを拡張し、スループットを向上させるために使用します。
③タイムスタンプオプション：
[1] は往復時間 RTT を計算するために使用されます。
[2] シリアル番号が範囲外である状況を処理するために使用されます。これは、シリアル番号が PAWS に回り込むのを防ぐこととも呼ばれます。
④選択確認オプション：選択確認機能を実装するために使用します。
(18) オプションの長さは可変であるため、セグメントヘッダーが 4 で割り切れるようにパディングフィールドが使用されます(データオフセットフィールド、つまりヘッダー長フィールドが 4 バイト単位であるため)。