【解説】TCP

TCP は、信頼性の高いバイト ストリーム サービスを提供するトランスポート層プロトコルであり、大きなデータ ブロックをメッセージ セグメントに分割して管理します。

1. TCPセグメント構造

写真は同じところから転載しました

現時点では、TCP セグメントに次の内容があることだけを知る必要があります。

送信元ポート番号と宛先ポート番号: 言うまでもなく、これは TCP メッセージがどこから来てどこへ行くのかを示します。

シーケンス番号と確認番号: これらはメッセージ セグメントのヘッダーの 2 つの最も重要なフィールドであり、TCP の信頼性の高いデータ送信の重要な部分でもあります。これについては後で詳しく説明します。

6 ビットのフラグ フィールド: ACK は受信の確認に使用され、RST、SYN、および FIN は接続の再開と切断に使用されます。PSH と URG については、当面は理解する必要はありません。

16 ビット ウィンドウ サイズ: このフィールドはフロー制御に使用され、受信側が受け入れ可能なバイト数を示し、送信側の送信レートを制御するために使用されます。

データ: 文字通り、送信される特定のデータ。

シリアル番号と確認番号

前述したように、TCP は信頼性の高いバイト ストリーム サービスを提供しており、データを順序付けられたバイト ストリームとして扱い、メッセージ セグメントのシーケンス番号はメッセージ セグメントの最初のバイトのバイト ストリーム番号になります。たとえば、A が 5000 バイトのデータを B に送信する場合、TCP が各バイトに番号を付けて 5 つのセグメントに分割すると仮定すると、最初のセグメントのシーケンス番号は 0、2 番目のセグメントのシリアル番号は 1000 になります。 3 番目の 2000 年など。これらのシーケンス番号は、TCP パケット ヘッダーのシーケンス番号フィールドに埋められます。

以下は確認番号ですTCP は全二重、つまり双方がデータを送受信できることがわかります。たとえば、A は 0 ～ 999 のデータを B に送信します。B はデータを受信した後、A に送信するデータもあります。その後、B が送信するメッセージ セグメントの確認番号には 1000 が埋められます。確認番号は次のとおりです。 A が次回データを送信するときに入力する必要があるシリアル番号 想像してください: A の 2 番目のセグメントのシリアル番号は 1000 ですか?

2. TCP 接続 (3 ウェイ ハンドシェイクおよび 4 ウェイ ウェーブ)

1. スリーウェイハンドシェイク

このうち、大文字のACKはフラグビット、小文字のackは確認番号、小文字のseqはシリアル番号です。

1.1 スリーウェイ ハンドシェイク(スリーウェイ ハンドシェイク) とは、TCP 接続が確立されるときに、クライアントとサーバーが合計 3 つのメッセージ セグメントを送信することを意味します。

最初はクライアントとサーバーの両方が CLOSED 状態にあり、サーバー アプリケーションがリッスン ソケットを作成すると、サーバーは LISTEN 状態になります。

1. 最初のハンドシェイク:クライアントはSYN メッセージ セグメントをサーバーに送信します。メッセージ セグメントのヘッダーのフラグ ビット SYN が 1 に設定され、また、独自の初期化シーケンス番号 seq=x を示します。このとき、クライアントはSYN_SENT 状態です。

2. 2 回目のハンドシェイク:サーバーはSYN セグメントを受信した後、独自の SYN-ACK メッセージで応答します。応答メッセージのヘッダーには 3 つの重要な情報があります: 最初に SYN が 1 に設定される; 2 番目に確認番号フィールド ack=x+1; 最後に、サーバーは独自の初期シーケンス番号 seq=y を選択します。メッセージ セグメントは次のことを示します。「接続を確立するリクエストを受け取りました。リクエスト メッセージの最初のシーケンス番号は x です (確認番号 ack=x+1 は、最初のシーケンス番号 seq= のメッセージを受信したことを示します) x)、この接続を確立することに同意します。初期シーケンス番号は y です。」 この時点で、サーバーは SYN_RCVD 状態にあります。

3. 3 回目のハンドシェイク: SYN-ACK メッセージを受信した後、クライアントはACK メッセージ セグメントを送信します。このメッセージ セグメントのシーケンス番号は seq=x+1、確認番号 ack=y+1 です。 SYN-ACK メッセージを受信しました。確認が届きます。この時点で、クライアントは ESTABLISHED 状態になります。

サーバーが ACK メッセージを受信すると、サーバーも ESTABLISHED 状態になり、この時点で、両者はリンクを確立します。

最初のハンドシェイクと 2 番目のハンドシェイクはシリアル番号を消費するだけで、データを運ぶことはできません。3 番目のハンドシェイクはデータを運ぶことができることに注意してください。

1.2 3 ウェイ ハンドシェイクの役割 (なぜ 3 ウェイ ハンドシェイクを行うのですか? 2 ウェイ ハンドシェイクは機能しないのですか?)

スリーウェイ ハンドシェイクの役割:

(1) 双方の送受信能力が正常か確認してください。
(2) 独自の初期化シーケンス番号を指定して、後続の信頼性の高い送信に備えます。

3ウェイハンドシェイクの目的は何ですか？

最初のハンドシェイク: クライアントはサーバーにメッセージを送信し、「クライアントがあなたとの接続を確立したいと考えています」と伝えます。

メッセージの最初のセグメントを受信した後、サーバーはクライアントの送信機能が正常であり、サーバーの受信機能も正常であると判断します。

2 回目のハンドシェイク: サーバーはクライアントにメッセージを返信し、「サーバーはあなたのリクエストを受け取り、あなたとの接続を確立することに同意しました。」と伝えます。

メッセージの 2 番目のセグメントを受信した後、クライアントは、クライアントの送受信機能は正常であり、サーバーの送受信機能も正常であるという結論を導き出します。（ただし、この時点ではサーバー側ではクライアントの受信機能や自身の送信機能が正常であるかどうかは確認できません）。

3 回目のハンドシェイク: クライアントはサーバーにメッセージを返信し、「クライアントはあなたの応答を受信し、あなたが接続に同意したことを知っています。それでは、接続を開始しましょう!」と伝えます。

メッセージの 3 番目のセグメントを受信した後、サーバーは、クライアントの受信機能とサーバーの送信機能も正常であるという結論を導き出します。

したがって、サーバーが 3 番目のメッセージを受信すると、双方が TCP 接続を確立します。

最初の 2 つのハンドシェイクだけが使用されると、サーバーは自身が応答したメッセージ セグメントがクライアントによって受信されたかどうかを確認できず、サーバーの送信機能と受信機能が機能しているかどうかもわかりません。クライアントの機能は正常です。

2. 4回手を振る

4 回手を振るということは、クライアントがサーバーから切断するときに、TCP 接続の切断を完了するために合計 4 つのセグメントを送信する必要があることを意味します。

最初は、クライアントとサーバーの両方が ESTABLISHED 状態にあります。クライアントが切断要求を開始すると (サーバーが開始することもできます)、4 波のプロセスは次のようになります。

1.最初のウェーブ: クライアントは FIN メッセージ セグメントを送信し、シーケンス番号 seq=u がメッセージ セグメント内に指定されます。この時点で、クライアントは FIN_WAIT_1 状態になります。

2. 2 番目のウェーブ: FIN メッセージを受信した後、サーバーはすぐに ACK メッセージ セグメントを送信し、そのシーケンス番号を seq=v に設定し、確認番号を ack=u+1 に設定します。クライアントからのメッセージを受信したことを示します。この時点で、サーバーは CLOSE_WAIT 状態になります。

第二波から第三波までの期間は、ハーフクローズ状態のため、サーバーからクライアントへのデータ送信は可能です。

3. 3 回目のウェーブ: データ送信が完了し、サーバーが切断したい場合は、FIN メッセージを送信し、シーケンス番号 seq=w を再指定します。確認番号は依然として ack=u+1 であり、これは、接続を切断できることを確認します。

4.第 4 波: クライアントはメッセージを受信した後、ACK メッセージ セグメントも送信して応答します 前回クライアントが送信したメッセージ セグメントのシーケンス番号は u なので、今回のシーケンス番号は seq=u+ となります1. 確認番号は ack=w+1 です。現時点では、クライアントは TIME_WAIT 状態にあり、サーバーが独自の応答メッセージを確実に受信できるようにするために、一定の時間が経過すると CLOSED 状態になります。

サーバーは ACK メッセージを受信すると接続を閉じ、CLOSED 状態になります。

2.1 なぜ 4 回手を振る必要があるのですか?

この質問は、別の方法で尋ねることもできます。つまり、なぜ真ん中の 2 つのステップを組み合わせることができないのか?ということです。サーバーがクライアントから FIN メッセージを受信して​​いる限り、ACK メッセージと FIN メッセージを同時に送信できますか。3 回手を振ると切断できますか?

ACK と FIN のトリガー タイミングが異なるため、通常は答えは得られません。解決しなければならないことが 1 つあります。サーバーは、FIN メッセージを受信した直後に、サーバーがメッセージを受信したことを示す ACK メッセージを送信できますが、サーバーが FIN メッセージを送信したい場合は、データが受信されるまで待つ必要があります。受信バッファはその後にのみ処理されます。つまり手を振るのに4回かかります。

2.2 2MSL を待つ必要があるのはなぜですか? (TIME_WAIT 状態になるのはなぜですか?)

MSL (最大セグメント寿命)、これは、セグメントが破棄されるまでにネットワーク内に存在できる最大時間であり、この時間が経過すると、メッセージは破棄されます。2MSL を待機するのは、サーバーが最後の ACK メッセージを受信したことを確認するためです。

確認するにはどうすればよいですか?

サーバーが最後の ACK メッセージを受信しない場合、タイムアウト再送信がトリガーされ、サーバーは FIN ACK メッセージを再度送信します。その後、2MSL 内で、クライアントは FIN メッセージを再度受信し、送信したばかりの ACK が失われ、再送信する必要があることを認識します。

サーバーが最後の ACK メッセージを受信した場合、クライアントは 2MSL 以内にメッセージを受信せず、クライアントは送信したばかりの ACK メッセージが失われていないことがわかり、再送信する必要がなく、CLOSED 状態に入ることができます。状態は安心です。

3. 確実なデータ伝送

3.1. タイムアウト再送とタイムアウト倍増

ほとんどの TCP 実装では、タイムアウト イベントが発生すると、TCP は次のタイムアウト間隔を前の値の 2 倍に設定し、直前のデータを再送信します。

たとえば、A が B にデータを送信すると、タイマーが開始され、タイムアウト時間が 0.75 秒に設定されているため、A は 0.75 秒以内に確認応答を受信できません。このとき、A はデータを再送信します。ここで、タイムアウト期間を 1.5 秒に設定します。そのため、再送信のたびにタイムアウト間隔が指数関数的に増加します。

3.2 高速再送信

タイムアウトによる再送信の問題の 1 つは、タイムアウト間隔が長すぎるため、エンドツーエンドの遅延が増加する可能性があることです。送信者が同じデータに対して 3 つの冗長 ACK を受信した場合、3 回確認されたメッセージ セグメントに続くメッセージが失われたとみなして、送信者は高速再送信を実行します。つまり、メッセージ セグメントの後に、失われたセグメントを再送信します。セグメントタイマーが期限切れになります。

冗長 ACK は、送信者が以前に確認応答を受信したセグメントを再確認する ACK です。

受信側が同じセグメントに対して確認応答を送信し続けるのはなぜですか? 受信機は 0 ～ 999 のセグメントを受信すると、次のセグメントのシーケンス番号が 1000 であることを期待しますが、この時点ではシーケンス番号 2000 のセグメントを受信すると、すぐに冗長 ACK、確認メッセージを送信します。 ACK の番号は 1000 で、受信側がシーケンス番号 1000 のセグメントの受信を望んでいることを示します。しかし、その後、シーケンス番号 3000 のメッセージ セグメントを受信すると、受信者は再度冗長 ACK を送信し、同様に送信者が 3 つの連続した冗長 ACK を受信すると、高速再送信を実行します。

3.3 再送信の選択

再送信を選択するということは、受信者が順序どおりでないセグメントを受信した後、そのセグメントが失われる可能性があることを意味し、送信者が失われたセグメントを再度送信できるようにするために冗長 ACK を送信します。その理由は、すべてを送信しないためです。失われたセグメントの後のセグメントは、TCP が受信したシーケンス外のセグメントを直接破棄するのではなくキャッシュするためです。そのため、失われたセグメントを受信した後で、失われたセグメントを並べ替えて受信するだけで十分です。

4. フロー制御

まず、TCP で接続されているホストには受信キャッシュがあることを知っておく必要があります。データが到着すると、データはキャッシュ内に留まり、アプリケーション プロセスがそれを読み取るのを待ちます。ただし、キャッシュ スペースには限りがあります。プロセスが受信するとき、データの読み取りが比較的遅く、送信側の送信が多すぎる場合、送信が速すぎる場合は、フロー制御が機能する必要があります。

TCP セグメントの受信ウィンドウ フィールドについてもう一度考えてみましょう。このフィールドの値は受信者の空きバッファ スペースのサイズであり、送信者はこのフィールドを通じて独自の送信レートを制御します。

しかし、次の状況を想像してみてください: 送信者が受信者のメッセージ セグメントを受信すると、受信ウィンドウ フィールドの値が 0 であることがわかります! その後、送信者はそこで停止し、データを送信しませんか? もちろんそうではありません。データが 1 バイトだけのメッセージ セグメントを送信し続けます。受信側のキャッシュが読み取られると、空き領域が生じます。この時点で、このメッセージ セグメントが受信され、送信側は受信確認を受け取ります。その後、セグメントが送信されます。

5. 輻輳制御

5.1 送信者はネットワークの輻輳をどのように認識しますか?

まず、名詞、パケット損失イベント: タイムアウト、または送信者が 3 つの冗長 ACK を受信することを明確にします。

ネットワークが過度に輻輳すると、データ パケットの一部がルーターによって破棄され、送信側でパケット損失イベントがトリガーされます。送信側がパケット損失を発見すると、ネットワークで輻輳が発生したと見なされます。


以下では、輻輳制御アルゴリズムの 3 つの部分 (スロー スタート、輻輳回避、および高速回復)を紹介します。

開始する前に、輻輳ウィンドウとスロー スタートしきい値という 2 つの用語を明確にしてください。

輻輳ウィンドウ(cwnd): 送信者がネットワークに送信できるデータの量を指します。

スロー スタートしきい値: 実際には、これは cwnd のしきい値であり、cwnd がこの値に達すると、cwnd の指数関数的な増加が終了します。

5.2 スロースタート

TCP 接続開始時は cwnd=1 で、セグメントが 1 つだけ送信されることを示します。応答 ACK が指定時間内に到着すると、送信側は輻輳ウィンドウを cwnd=2 に設定し、2 つのセグメントを送信します。ACK が確認されたら、設定します。輻輳ウィンドウを cwnd=4 に設定し、終了するまで同様に続けます。

輻輳ウィンドウの指数関数的な増加率は、次の 3 つの状況で終了します。

(1)タイムアウト: タイムアウトが発生した後、送信側はしきい値を輻輳ウィンドウの半分である cwnd/2 に設定し、同時に cwnd を 1 に設定して最初からゆっくりと開始します。

(2)ウィンドウ サイズ >= しきい値、スロー スタートを終了し、輻輳回避モードに入ります。

(3) 3 つの冗長 ACK が検出された場合、送信側は高速再送を実行し、高速リカバリ状態に入ります。

5.3 渋滞の回避

先ほど述べたように、ウィンドウ サイズ >= しきい値の場合、輻輳回避状態に入ります。この状態に入ると、cwnd の値は元の値の半分になり、このとき輻輳ウィンドウは直線的に増加します。つまり、送信ラウンドごとに cwnd は 1 だけ増加します。

渋滞回避は次の場合に終了します。

(1)タイムアウト。スロー スタートの場合と同様、タイムアウトが発生した後、送信側はしきい値を輻輳ウィンドウの半分である cwnd/2 に設定し、同時に cwnd を 1 に設定します。

(2) 3 つの冗長 ACK が検出され、送信側はしきい値を cwnd/2 に設定しますが、輻輳ウィンドウ サイズも 1 ではなく cwnd/2 に変更し、高速回復状態に入ります。

5.3 迅速な回復

パケット損失イベントが発生すると (タイムアウトまたは 3 つの冗長 ACK が受信された場合)、送信側は、threshold=cwnd/2 および window size=threshold を設定し、輻輳回避状態に入り、cwnd は直線的に増加します。

以上が私の要約の全内容ですが、間違いがあればご指摘ください。