1. 概要

このチュートリアルでは、 TCPで一般的な2つのトラフィック制御方法、フローと輻輳制御について説明します。 最初に、TCPでフローと輻輳制御がどのように機能するかを詳しく説明します。

最後に、それらのコアの違いについて説明します。

2. TCPのフロー制御

フロー制御は、確認応答を受信せずに受信側に送信されるデータの量を処理します。 受信者がデータに圧倒されないようにします。これは、送信者と受信者の間の一種の速度同期プロセスです。 OSIモデルのデータリンク層は、フロー制御を容易にする役割を果たします。

フロー制御を理解するための実際的な例を見てみましょう。 ジャックはトレーニングセッションに参加しています。 彼が先生によって教えられた概念を理解するのが遅いと仮定しましょう。 一方、教師は生徒からの承認を得ることなく、非常に速く教えています。

しばらくすると、彼の先生から出てくるすべての言葉がジャックの頭の上に溢れています。 したがって、彼は何も理解していません。 ここで、教師は、生徒が一度に処理できる概念の数に関する情報を持っている必要があります。

しばらくして、ジャックはデータに圧倒されたので、ペースを落とすように先生に要求しました。 先生は最初にいくつかの概念を教え、次に生徒からの承認を待ってから次の概念に進むことにしました。

例と同様に、フロー制御メカニズムは、データを受信側デバイスに送信できる最大速度を送信側に通知します。送信側は、受信側の容量に応じて速度を調整し、フレームを削減します。受信機側からの損失

TCP のフロー制御により、レシーバーバッファがすでに完全にいっぱいになっている場合に、レシーバーにそれ以上のデータが送信されないことが保証されます。 レシーバーバッファは、レシーバーの容量を示します。 レシーバーバッファがいっぱいになると、レシーバーはデータを処理できなくなります。

3. スライディングウィンドウプロトコルの概要

TCPで人気のあるフロー制御メカニズムの1つは、スライディングウィンドウプロトコルです。これは、可変サイズのバイト指向のプロセスです。

この方法では、送信者と受信者の間に接続を確立すると、受信者は受信者ウィンドウを送信者に送信します。 レシーバーウィンドウは、レシーバーのバッファーで現在使用可能なサイズです。

使用可能なレシーバーウィンドウから、TCPは確認応答なしでさらに送信できるデータ量を計算します。ただし、レシーバーウィンドウのサイズがゼロの場合、TCPはゼロ以外の値になるまでデータ送信を停止します。

レシーバーウィンドウサイズは、TCPセグメントのフレームの一部です。 ウィンドウサイズの長さは16ビットです。つまり、ウィンドウの最大サイズは65,535バイトです。

受信者がウィンドウのサイズを決定します。 受信者は、現在利用可能な受信者ウィンドウサイズをすべての確認メッセージとともに送信します。

3.1. スライディングウィンドウプロトコルのプロセス

スライディングウィンドウプロトコルには、ウィンドウを開く、ウィンドウを閉じる、ウィンドウを縮小するという3つのプロセスがあります。

ウィンドウを開くプロセスにより、送信可能なバッファーにさらに多くのデータを含めることができます。

ウィンドウを閉じるプロセスは、送信されたデータバイトの一部が確認されたことを示し、送信者はそれらについてもう心配する必要はありません。

ウィンドウの縮小プロセスは、ウィンドウサイズの減少を示します。 これは、一部のバイトが送信に適格であることを意味します。 ウィンドウサイズが減少するため、送信者はそれらのバイトを転送しません。 受信機はウィンドウを開いたり閉じたりできますが、ウィンドウを縮小することはお勧めしません。

3.2. 例

デバイスAとデバイスBの2つのデバイスがあるとします。 デバイスAは300000バイトのデータをデバイスBに送信したいと考えています。最初に、TCPはデータをそれぞれ1500バイトのサイズの小さなフレームに分割します。 したがって、合計200個のパケットがあります。最初に、Device-Bが使用可能なレシーバーウィンドウをDevice-Aに通知するとします。これは60000バイトです。 これは、Device-AがDevice-Bから確認応答を受信せずに、60000バイトをDevice-Bに送信できることを意味します。

これで、Device-Aは、確認応答を待たずに最大40パケット(1500 * 40 = 60000)を送信できます。 したがって、デバイスAは、送信全体を完了するために5つの確認応答メッセージを待機する必要があります。必要な確認応答メッセージの数は、デバイスBの受信バッファの容量を考慮して計算されます。

ここで、TCPは、データパケットを配置し、ウィンドウサイズを60000バイトにする役割を果たします。 さらに、TCPは、Device-AからDevice-Bまでのウィンドウ範囲に含まれるパケットの送信に役立ちます。 パケットを送信した後、確認応答を待ちます。 確認応答が受信されると、ウィンドウが次の60000バイトにスライドし、パケットが送信されます。

受信者がゼロサイズのウィンドウを送信すると、TCPは送信を停止します。 ただし、受信者が確認応答を送信したものの、送信者が見逃した可能性があります。

その場合、受信者は次のパケットを待ちます。 しかし一方で、送信者はゼロ以外のウィンドウサイズを待っています。 したがって、この状況ではデッドロックが発生します。このケースを処理するために、TCPはウィンドウサイズがゼロになると永続タイマーを開始します。 また、定期的にパケットを受信者に送信します。

4. 輻輳制御

輻輳制御は、ネットワークの各ノードでのパケットの流れを制限するメカニズムです。したがって、ノードが過剰なパケットで過負荷になるのを防ぎます。 輻輳は、任意のノードへのパケットのフロー速度がその処理能力を超える場合に発生します。

輻輳が発生すると、ネットワーク応答時間が遅くなります。 その結果、ネットワークのパフォーマンスが低下します。 ルーターとスイッチにはキューバッファーがあり、処理のためにパケットを保持しているため、輻輳が発生します。 保留プロセスが完了すると、パケットは次のノードに渡され、ネットワークで輻輳が発生します。

TCPが輻輳制御に使用する3つのフェーズがあります:スロースタート、輻輳回避、および輻輳検出:

4.1. スロースタート

輻輳制御の最初のフェーズでは、送信者がパケットを送信し、しきい値に達するまでパケット数を徐々に増やします。フロー制御の説明から、ウィンドウサイズは受信者によって決定されます。

同様に、輻輳制御メカニズムにはウィンドウサイズがあります。 徐々に増加します。 フロー制御では、ウィンドウサイズ(RWND)がTCPヘッダーとともに送信されます。 輻輳制御ではありますが、送信側ノードまたはエンドデバイスがそれを保存します。

送信者は、ウィンドウサイズ(CWND)が1 MSS(最大セグメントサイズ)のパケットの送信を開始します。 MSSは、送信者が1つのセグメントで送信できるデータの最大量を示します。 最初に、送信者は1つのセグメントのみを送信し、セグメント1の確認応答を待ちます。 その後、送信者はウィンドウサイズ(CWND)を毎回1MSSずつ増やします。

スロースタートプロセスは、無期限に続行することはできません。 したがって、は通常、スロースタートしきい値(SSTHRESH)と呼ばれるしきい値を使用して、スロースタートプロセスを終了します。ウィンドウサイズ(CWND)がスロースタートしきい値に達すると、スロースタートプロセスは停止します。 、および輻輳制御の次のフェーズが開始されます。 ほとんどの実装では、スロースタートしきい値の値は65,535バイトです。

4.2. 輻輳回避

輻輳制御の次のフェーズは、輻輳回避です。 スロースタートフェーズでは、ウィンドウサイズ(CWND)が指数関数的に増加します。 さて、ウィンドウサイズを指数関数的に増やし続けると、ネットワークで輻輳が発生する場合があります。

これを回避するために、輻輳回避アルゴリズムを使用します。 輻輳回避アルゴリズムは、ウィンドウサイズ(CWND)の計算方法を定義します。

   

各確認応答の後、 TCPは、ウィンドウサイズ(CWND)の線形増分を保証し、スロースタートフェーズよりも遅くなります。

4.3. 輻輳検出

3番目のフェーズは輻輳検出です。 現在、輻輳回避フェーズでは、ネットワークの輻輳の可能性を減らすために、ウィンドウサイズの増分率(CWND)を減らしました。 ネットワークにまだ輻輳が残っている場合は、輻輳検出メカニズムを適用します。

TCPが輻輳を検出する場合は2つの条件があります。最初に、推定時間内に送信者によって送信されたパケットの確認応答が受信されない場合。 2番目の条件は、受信者が3つの重複した確認応答を受け取ったときに発生します。

タイムアウトの場合、新しいスロースタートフェーズを開始します。 2番目の状況に対処するために、新しい輻輳回避フェーズを開始します。

5. 実用例

TCPのフローと輻輳制御を要約するために、実際の例を見てみましょう。

ジャックは朝起きてオフィスの準備をします。 途中、彼は複数の道路のジャンクションを横断する必要があり、各ジャンクションには信号機があります。 オフィスには、彼をオフィスの床に落とすリフトがあります。

この例では、すべての信号機が1つのジャンクションから別のジャンクションへの混雑を制御しようとします。 これは、ネットワーク内のあるノードから別のノードへのセグメントのフローを維持するのと同じように機能します。 最後に、ジャックがオフィスビルに到着すると、フロー制御が開始されます。 警備員は、リフトの容量に応じて、リフトの人々のアクセスを制御します。 これは、レシーバーバッファの概念の流入制御に似ています。

6. 違い

TCPのフロー制御と輻輳制御の主な違いについて話しましょう。

7. 結論

このチュートリアルでは、TCPのフローおよび輻輳制御メカニズムについて説明しました。 これらのメカニズムに関連する概念とプロトコルを例とともに示しました。

最後に、それらのコアの違いを調査しました。