TCPとUDPの違いと、フロー制御、輻輳制御、高速再送、高速回復アルゴリズムの詳細な説明

[[413351]]

UDPとTCPの違い

前回の記事では、TCP の接続を確立するための 3 ウェイハンドシェイクと、接続を解除するための 4 ウェイハンドシェイクについて詳しく説明しました。このチュートリアルでは、TCP のその他の内容について説明します。まず、トランスポート層プロトコルでもある UDP プロトコルですが、両者の違いと関連性は何でしょうか。

類似点は、UDP と TCP が TCP/IP アーキテクチャのトランスポート層における 2 つの重要なプロトコルであることです。次の図は、TCP/IP アーキテクチャの図です。

さらに付け加えると、TCP および UDP プロトコルの下にある IP プロトコルは、さまざまなネットワークアプリケーションにサービスを提供でき、IP 層プロトコルを使用して異なるネットワークインターフェイスを相互接続できるということです。次に構造図を示します。

画像-20210718234432031

TCP と UDP の使用頻度は、インターネット層では IP プロトコルに次いで 2 番目に高いです。

UDP はユーザーデータグラムプロトコルとも呼ばれ、TCP は伝送制御プロトコルとも呼ばれます。最も大きな違いは、UDP はコネクションレスであるのに対し、TCP はコネクション指向であることです。以下は、2 つの通信方法の概略図です。

上図に示すように、UDP は接続を確立せずにデータを送信できます。ただし、TCP はデータを送信する前に接続を確立するための「3 メッセージハンドシェイク」を実行する必要があります。データ送信が完了したら、接続を解放するために「4 メッセージハンドシェイク」が必要です。

UDP がユニキャスト、マルチキャスト、ブロードキャストをサポートしているのは、まさに UDP のコネクションレスな性質のためです。TCP の場合、3 ウェイハンドシェイクによって確立された接続のため、信頼性の高いチャネルがあり、ユニキャストのみをサポートします。以下は、2 つの通信方法の概略図です。

次に、UDP と TCP のデータ転送の詳細なプロセスを分析してみましょう。

UDP はアプリケーションメッセージ指向であることがわかります。送信者のアプリケーションプロセスは、アプリケーションメッセージをトランスポート層の UDP に配信します。UDP は、アプリケーション層メッセージに UDP ヘッダーを直接追加して、UDP ユーザーデータグラムにして送信します。受信側の UDP は、UDP ユーザーデータグラムを受信すると、UDP ヘッダーを削除し、アプリケーション層メッセージをアプリケーションプロセスに配信します。つまり、UDP は、アプリケーションプロセスによって渡されたメッセージを結合または分割せず、これらのメッセージの境界を保持します。つまり、UDP はアプリケーションメッセージ指向です。

次に、上図の右側は、TCP のデータ送信プロセスです。送信側の TCP は、アプリケーションプロセスによって配信されたデータブロックを、一連の非構造化バイトストリームと見なします。TCP は、送信されるこれらのバイトストリームの意味を認識しません。番号を付けて、独自の送信バッファーに格納するだけです。TCP は、送信戦略に従って送信バッファーから一定数のバイトを抽出し、TCP セグメントを構築して送信します。受信側の TCP は、一方では、受信した TCP メッセージからデータペイロード部分を取り出して受信バッファーに格納し、他方では、受信バッファー内の一部のバイトをアプリケーションプロセスに渡します。TCP は、受信したデータブロックが送信アプリケーションプロセスによって送信されたデータブロックと対応するサイズ関係にあることを保証しませんが、受信アプリケーションプロセスによって受信されたバイトストリームは、送信アプリケーションプロセスによって送信されたバイトストリームとまったく同じである必要があります。同時に、受信アプリケーションプロセスは、受信したバイトストリームを識別し、意味のあるアプリケーション層データに復元できる必要があります。言い換えれば、TCP はバイトストリーム指向であり、これが TCP が信頼性の高い伝送、フロー制御、輻輳制御を実現するための基礎となります。

次に、別の比較を見てみましょう。概略図は次のとおりです。

つまり、TCP/IP アーキテクチャの場合、インターネット層は上位層にコネクションレスで信頼性の低い伝送サービスを提供し、UDP の場合、トランスポート層は上位層にコネクションレスで信頼性の低い伝送サービスを提供します。このようなメカニズムはデータパケットの損失やビットエラーを引き起こしますが、UDP 伝送の場合、単にそれらを破棄するだけで、他には何も行いません。一方、TCP 伝送プロトコルの場合、インターネット層は上位層にコネクションレスで信頼性の低い伝送サービスを提供し、TCP が配置されているトランスポート層は上位層に接続指向の信頼性の高い伝送サービスを提供します。これにより、TCP 接続に基づく信頼性の高いチャネルが実現され、伝送エラー、ビットエラー、損失、無秩序、重複の問題は発生しません。

UDP と TCP メッセージのヘッダーを比較してみましょう。UDP ユーザーデータグラムは、ヘッダーとデータペイロードの 2 つの部分で構成されます。TCP セグメントも、ヘッダーとデータペイロードで構成されます。UDP ユーザーデータグラムヘッダーは 8 バイトのみで、送信元ポート、宛先ポート、長さ、およびチェックサムのみが含まれます。 TCP の場合、ヘッダーにはさらに多くの情報が含まれ、ヘッダーサイズは少なくとも 20 バイト、最大 60 バイトです。

まとめ

まとめると、TCP と UDP の特徴と違いは次のようにまとめられます。

ユーザーデータグラムプロトコル (UDP)

接続なし
1対1、1対多、多対1、多対多のインタラクティブな通信をサポート
アプリケーション層から配信されたメッセージを直接パッケージ化する
ベストエフォート型の配信、つまり信頼性が低く、フロー制御や輻輳制御がない
ヘッダーのオーバーヘッドはわずか8バイトと小さい

伝送制御層プロトコル TCP

コネクション指向
各TCP接続は2つのエンドポイントしか持てず、1対1の通信しかできない。
バイトストリーム指向
フロー制御と輻輳制御を使用した信頼性の高い伝送
最小ヘッダーサイズは 20 バイト、最大ヘッダーサイズは 60 バイトです。

TCPフロー制御

スライディングウィンドウの導入

前回の記事では、TCP の 3 ウェイハンドシェイクと 4 ウェイハンドシェイクのプロセスについて説明しました。TCP 通信では、送信されるデータごとに確認応答が必要であることがわかりました。前のデータパケットが応答を受信すると、次のデータパケットが送信されます。通信プロセスは次のとおりです。

上の図から、データパケットが送信されるたびに、次のデータパケットが送信される前に応答が返されると、効率が低すぎることがわかります。このとき、スライディングウィンドウの概念が導入されます。ウィンドウができたので、ウィンドウサイズを指定できます。ウィンドウサイズとは、応答を待たずに送信できるデータの最大値を指します。たとえば、現在のウィンドウが 3 の場合、送信者は 3 つの TCP セグメントを連続して送信できます。上の図に示すように、いずれかの ACK が失われた場合、次の ACK を通じて確認できます。たとえば、ACK 600 が失われた場合、ACK 700 で ACK 600 を置き換えることができます。

フロー制御

上記で紹介したスライディングウィンドウメカニズムによると、このメカニズムにより、送信速度を速くすることができますが、送信者の送信速度が速すぎると、受信側が処理する時間がなく、データが失われる可能性があります。ここで説明するフロー制御は、送信者の送信速度が速すぎないようにして、受信側が時間内に受信できるようにすることです。スライディングウィンドウメカニズムを使用すると、TCP 接続で送信者のフロー制御を簡単に実装できます。

フロー制御の実装方法を紹介する前に、送信側と受信側のスライディングウィンドウをそれぞれ見てみましょう。まず、送信側のウィンドウを紹介します。送信側のウィンドウの大きさはどれくらいでしょうか。これは、受信側が処理できるデータの量によって異なります。つまり、データを送信する前に、受信側は送信側にウィンドウサイズを報告します。このウィンドウサイズは、アドバタイズウィンドウとも呼ばれます。具体的には何を意味するのでしょうか。次の図を参照してください。

LastByteAcked: 最初の部分と2番目の部分の境界線

LastByteSent: 2番目と3番目の部分の境界線

また、概略図から、アドバタイズされたウィンドウの場合、このウィンドウのサイズは 2 番目の部分 + 3 番目の部分と等しくなる必要があることがわかります。

受信側では、キャッシュに記録されるコンテンツは以下のように単純になります。

その中で、MaxRcvBuffer は文字通り、バッファの最大量を意味します。受信側のウィンドウサイズは青いボックスに表示されます。この時点で、受信ウィンドウと送信ウィンドウのサイズは同じですか? という疑問が生じます。

答えはまったく同じではありません。受信ウィンドウのサイズは、送信ウィンドウのサイズとほぼ同じです。

その理由は、スライディングウィンドウが静的ではないためです。たとえば、受信側のアプリケーションプロセスがデータをより速く読み取ると、受信側のウィンドウはすぐに空になります。ただし、このメッセージはネットワーク経由で送信側に送信される必要があるため、依存関係は不一致になります。したがって、ほぼ同等です。

送信側と受信側のウィンドウについては基本的にこれで終わりです。次はフロー制御に関する内容です。

まず、ウィンドウが 9 のままで変化がないと仮定します。4 の確認が来ると、ウィンドウは 1 つ右に移動します。この間に、シーケンス番号 13 のパケットも送信できます。

この時点で送信者が送信速度が速すぎると、3番目の部分の10、11、12、13をすべて送信し、その後送信を停止します。送信されなかった送信可能部分は0です。

このとき、パケット 5 の確認が届いたときのみ、クライアント側でウィンドウが 1 グリッド分スライドしたことに相当します。このとき、14 番目のパケットを送信できます。

受信側の処理が遅すぎる場合は、確認情報を通じてウィンドウサイズを調整できます。ここで、より極端なケース、つまり、受信側がデータを処理していないと仮定します。その場合、データパケット 6 の確認が到着したときに、ウィンドウサイズは 9 にできず、8 に縮小する必要があります。以下は、送信側が確認パケット 6 を受信した後、ウィンドウがどのように変化するかを示しています。ウィンドウは 1 グリッド右に移動しても変化しませんが、ウィンドウの左側が 1 グリッド縮小され、ウィンドウ全体のサイズは変化しないことがわかります。

受信側がデータを処理しない場合、確認されるパケットが増えるにつれて、ウィンドウは 0 に達するまでどんどん小さくなります。受信側のウィンドウの変化は次のとおりです。

上図の受信者に対応する送信ウィンドウは下図のようになります。14 の確認が送信者に届くと、送信者のウィンドウも 0 に調整され、送信が停止されます。

このような状況が発生した場合、送信者はウィンドウサイズを調整する機会があるかどうかを確認するために、定期的にウィンドウ検出パケットを送信します。受信側が遅い場合は、バイトが解放されたらすぐに送信側に通知せず、すぐに再び埋めることで、低エネルギーウィンドウシンドロームを防ぐ必要があります。ウィンドウが小さすぎる場合は、ウィンドウが特定のサイズに達するか、バッファーの半分が空になるまでウィンドウを更新できません。

上記はTCPにおけるフロー制御です。

TCP輻輳制御

ネットワーク内のリソースに対する需要が、一定期間内に提供できるリソースの使用可能部分を超えると、ネットワークのパフォーマンスが低下します。この状況を輻輳と呼びます。

コンピュータネットワークでは、リンク容量 (帯域幅)、キャッシュ、スイッチングノードのプロセッサはすべてネットワークリソースです。

輻輳が発生し、制御されない場合、入力負荷が増加するにつれてネットワーク全体のスループットが低下します。

次の図は、理想的な輻輳制御、実際の輻輳制御、輻輳制御なしのグラフです。曲線は次のとおりです。

TCP の輻輳制御アルゴリズムには、主に次の 4 つの側面が含まれます。

スロースタートアルゴリズム
輻輳回避アルゴリズム
高速再送アルゴリズム
高速回復アルゴリズム

これら 4 つの輻輳制御アルゴリズムを説明する前に、次の条件を想定します。

データは一方向に送信され、確認のみが反対方向に送信されます。
受信側には常に十分なバッファスペースがあるため、送信側が送信するウィンドウのサイズはネットワークの輻輳の程度によって決まります。
議論の単位はバイトではなく、最大セグメントサイズ (MSS) です。

つまり、送信者と受信者の間の通信は次のようになります。具体的なプロセスは次の図に示されています。

送信者は TCP データセグメントを受信者に送信し、受信者はセグメント全体を受信すると、送信者に TCP 確認応答セグメントを返します。

つまり、送信者は輻輳ウィンドウ cwnd と呼ばれる状態変数を維持し、その値はネットワークの輻輳の度合いに応じて動的に変化します。

輻輳ウィンドウ cwnd の維持原則は、ネットワークに輻輳がない限り輻輳ウィンドウの値が増加し、ネットワークに輻輳がある限り輻輳ウィンドウは減少するというものです。
ネットワーク輻輳の発生を判断する基準は、受信されるべき確認メッセージが時間どおりに受信されなかった（つまり、タイムアウト再送が発生した）ことです。

送信者は輻輳ウィンドウを送信ウィンドウとして使用します。つまり、swnd = cwdnです。

スロースタートしきい値 ssthresh 状態変数を維持します。

cwnd < ssthreshの場合、スロースタートアルゴリズムの使用を開始する
cwnd > ssthreshの場合、スロースタートアルゴリズムの使用を停止し、代わりに輻輳回避アルゴリズムを使用します。
cwnd = ssthresh の場合、スロースタートアルゴリズムまたは輻輳回避アルゴリズムのいずれかを使用できます。

スロースタートと輻輳回避アルゴリズム

スロースタートアルゴリズムを説明するために、次の折れ線グラフを示します。折れ線グラフの横軸は送信ラウンドを表し、送信ラウンドとは、送信者がデータセグメントを受信者に送信した後、受信者が対応する確認セグメントを送信者に送信することを意味します。送信ラウンドで発生する時間は実際にはラウンドトリップ時間であり、縦軸は動的に変化する値である輻輳ウィンドウです。

2 つの TCP パーティが論理接続関係を確立すると、輻輳ウィンドウ値が 1 に設定されます。また、スロースタートしきい値の初期値は 16 に設定する必要があります。スロースタートアルゴリズムが実行されると、送信側は受信側から確認セグメントを受信するたびに輻輳ウィンドウ値を 1 ずつ増加し、次の送信ラウンドを開始します。輻輳ウィンドウ値がスロースタートしきい値まで増加すると、代わりに輻輳回避アルゴリズムが実行されます。

上記の折れ線グラフをどのように説明すればよいでしょうか。つまり、最初に送信者の輻輳ウィンドウ値が 1 の場合、送信者は TCP セグメントを受信者に送信し、受信者がそれを受信した後に TCP 確認セグメントを送信者に送信します。送信者が確認セグメントを受信すると、輻輳ウィンドウ値に 1 を追加します。これは、輻輳ウィンドウ値が送信ウィンドウ値と等しいためです。したがって、この時点で送信ウィンドウ値は 2 であり、送信者は 2 つのセグメントを受信者に送信できます。送信者がこれら 2 つのセグメントの確認セグメントを受信すると、輻輳ウィンドウを 4 に設定します。この時点で、送信者は 4 つの TCP セグメントを受信者に送信できます。この原理によれば、図のデータパケットの各追加ラウンドで、輻輳ウィンドウ値はスロースタートしきい値である 16 まで増加するまで指数関数的に増加します。この時点で、輻輳回避アルゴリズムが使用されます。

輻輳回避アルゴリズムとは何でしょうか。つまり、現在、各送信ラウンドの後に、輻輳ウィンドウの値は、スロースタートアルゴリズムのような指数関数的な増加ではなく、線形プラス 1 に変更されます。たとえば、送信者はこの時点でデータセグメント 15 から 30 を送信できます。送信者がデータ確認セグメント 15 から 30 を受信すると、輻輳ウィンドウの値は 1 増加して 17 になります。この原理に基づいて、送信者と受信者は数ラウンドのデータ送信を実行し、以下に示すような折れ線グラフに到達します。

このとき、輻輳ウィンドウ値が 24 に達すると、送信側は一連のデータパケットを再度受信側に送信する。送信中にこれらのセグメントのいくつかが失われたと仮定すると、送信側は必然的にタイムアウトになり、これらの失われたセグメントを再送信することになります。送信側は、これに基づいてネットワークが輻輳している可能性が高いと判断します。このとき、輻輳が発生したときにスロースタートしきい値を輻輳ウィンドウ値の半分に更新し、輻輳ウィンドウ値を 1 に調整して、スロースタートアルゴリズムを再実行するという作業を行う必要があります。輻輳ウィンドウがスロースタートしきい値に達すると、輻輳回避アルゴリズムが実行されます。具体的なプロセスを図に示します。

最後に、プロセス全体に注釈が付けられ、注釈後の折れ線グラフが図に示されます。

高速再送アルゴリズム

場合によっては、ネットワーク内で個々のセグメントが失われることがあります。ただし、実際のネットワークでは輻輳は発生していません。これにより、送信側はタイムアウトして再送信し、輻輳が発生したと誤って認識します。このとき、送信側は輻輳ウィンドウを最小値の 1 に設定し、誤ってスロースタートアルゴリズムを開始し、伝送効率が低下します。

高速再送信アルゴリズムにより、送信者は個々のセグメントが失われたことをできるだけ早く知ることができます。言い換えると、高速再送信により、送信者はタイムアウト再送信タイマーが期限切れになるまで待ってから再送信するのではなく、できるだけ早く再送信することができます。

具体的にはどのようなものでしょうか。つまり、受信側は、ピギーバック確認を送信するのにデータを送信するまで待つのではなく、すぐに確認を送信する必要があります。順序が乱れたセグメントを受信した場合でも、受信したセグメントの繰り返し確認をすぐに送信する必要があります。送信側は、3 回連続して繰り返し確認を受信すると、セグメントタイムアウト再送信タイマーがタイムアウトするまで待ってから再送信するのではなく、対応するセグメントをすぐに再送信します。

具体的なプロセスはどのようなものでしょうか? 次の図をご覧ください。

上図から、M2を送信するときに、M1の確認セグメントが到着するのを待ってから送信するのではなく、確認セグメントが到着する前にM2セグメントを送信することがわかります。M3を送信すると、データグラムが失われます。M4を送信すると、受信側はセグメントM2を受信後、確認を返し続けます。M6を送信するまで、送り返されるのはM2の確認パケットです。この時点で、M2の確認パケットが3つ累積的に受信されているため、M3セグメントがすぐに再送されます。このようにして、M3セグメントのタイムアウト再送は発生せず、輻輳ウィンドウが1に調整されることもなく、ネットワークの伝送効率を大幅に向上させることができます。

高速回復アルゴリズム

送信者が重複した確認応答を 3 回受信すると、個々のセグメントのみが失われたことがわかります。したがって、スロースタートアルゴリズムは開始されませんが、高速回復アルゴリズムが実行され、送信者はスロースタートしきい値と輻輳ウィンドウ値を現在のウィンドウの半分に調整し、輻輳回避アルゴリズムの実行を開始します。