コンピュータネットワークに関する注意事項 - トランスポート層

トランスポート層

通信と情報処理の観点から見ると、トランスポート層は 5 層の参照モデルの 4 番目の層です。上位のアプリケーション層に通信サービスを提供します。これは通信指向部分の最上位に属し、ユーザー機能の最下位レベルでもあります。

5.1 トランスポート層が提供するサービス

5.1.1 トランスポート層の機能

トランスポート層は、エンドツーエンド通信とも呼ばれる、2 つのホスト間のアプリケーション プロセス間の通信を提供しますネットワーク層プロトコルは信頼性が低く、パケット損失、順序の乱れ、重複を引き起こす可能性があるため、データ送信に信頼性の高いサービスを提供するためにトランスポート層が導入されています。

ここに画像の説明を挿入します

トランスポート層の UDP は信頼できないのに、なぜトランスポート層が信頼できるサービスを提供するといわれるのでしょうか?

UDP を使用すると、データグラムが宛先に正しく到着することを保証できないため、トランスポート層の UDP が信頼できないのは事実です。UDP はエラーを検出した後、それを破棄することを選択することも、エラーをシステムに報告することも選択できます。アプリケーション層。しかしキーはまだユーザー自身が選択する必要があります、ユーザーが TCP (FTP ソフトウェアなど) を選択した場合、自然なトランスポート層は信頼できます。ただし、ユーザーが UDP (QQ ソフトウェア、ビデオ会議ソフトウェアなど) を使用している場合、トランスポート層は信頼できません。したがって、トランスポート層が信頼できるかどうかは、トランスポート層で使用されるプロトコルに大きく関係しますが、一般に、トランスポート層はデフォルトで信頼できます。

トランスポート層の機能:

ここに画像の説明を挿入します

  • アプリケーション プロセス間の論理通信を提供します(ネットワーク層はホスト間の論理通信を提供します)。「論理的な通信」とは、トランスポート層間の通信は、図5-2に示すように、一見横方向にデータを送信することを意味しますが、実際、2 つのトランスポート層の間には水平方向の物理接続はありません。
  • エラー検出:受信時メッセージのヘッダー部分とデータ部分エラー検出が実行されます (ネットワーク層は IP データグラム ヘッダーのみをチェックし、データ部分はチェックしません)。
  • コネクションレス型またはコネクション型のサービスを提供します。たとえば、アプリケーションによっては、一部のデータ送信ではリアルタイムのパフォーマンスが必要となるため (リアルタイムのビデオ会議など)、トランスポート層には 2 つの異なる送信プロトコル、つまりコネクション型 TCP とコネクションレス型 UDP が必要になります。TCP は信頼性の高い伝送サービスを提供しますが、UDP は効率的ですが信頼性の低い伝送サービスを提供します。
  • 再利用と廃棄:多重化とは、送信側の異なるアプリケーション プロセスが同じトランスポート層プロトコルを使用してデータを送信できることを意味します。逆多重化とは、受信側のトランスポート層がメッセージのヘッダーを取り除いた後、データを宛先アプリケーション プロセスに正しく配信できることを意味します。

コネクション型サービスには、次の 2 つの機能もあります

  • 接続管理: 接続を定義して確立するプロセスは、通常、ハンドシェイクと呼ばれます。たとえば、TCP の「スリーウェイ ハンドシェイク」メカニズムです。
  • フロー制御と輻輳制御: ネットワークの輻輳によるデータ損失を防ぐために、相手先およびネットワークが一般的に許容する速度でデータを送信します。

トランスポート層でコネクション型サービスとコネクションレス型サービスのどちらを使用するかを決定するには、どのような原則を使用する必要がありますか?

上位層アプリケーションの性質に基づいて区別する必要があります。たとえば、ファイルを転送する場合はファイル転送プロトコル (FTP) を使用する必要があり、ファイル転送はエラーや損失がなく信頼性が高くなければならないため、トランスポート層では接続指向の TCP を使用する必要があります。ただし、アプリケーションがパケット化された音声またはビデオ オン デマンド情報を送信する場合、情報送信のリアルタイム性を確保するために、トランスポート層はコネクションレス UDP を使用する必要があります。

アプリケーション プロセスでは、2 つのトランスポート層エンティティ間にエンドツーエンドの論理通信チャネルがあるように見えますが、これをどのように理解していますか?

ここに画像の説明を挿入します

TCP はコネクション指向ですが、TCP で使用される IP はコネクションレスです。これら 2 つのプロトコルの主な違いは何ですか?

ここに画像の説明を挿入します

TCP はコネクション指向ですが、TCP で使用されるネットワークはコネクション指向 (X.25 ネットワークなど。これは廃止されており、ここでは例としてのみ使用されているため、理解する必要はありません) またはコネクションレス (たとえば、X.25 ネットワークなど) にすることができます。現在広く使用されている IP ネットワークとして)。コネクションレス型ネットワークを選択すると、システム全体が非常に柔軟になりますが、もちろん、いくつかの問題も生じます。

明らかに、TCP は IP が提供できるよりも多くの機能とサービスを提供します。これは、TCP が確認応答、スライディング ウィンドウ、タイマーなどのメカニズムを使用するため、誤ったメッセージ、重複したメッセージ、および順序が正しくないメッセージを検出できるためです。

5.1.2 トランスポート層のアドレス指定とポート

ポートの基本概念

前述したように、データリンク層は MAC アドレスでアドレス指定され、ネットワーク層は IP アドレスでアドレス指定されます。トランスポート層はポート番号によってアドレス指定されます

ポート (ソフトウェア ポート) はトランスポート層サービス アクセス ポイントです。このポートを使用すると、アプリケーション層のさまざまなアプリケーション プロセスがポートを介してデータをトランスポート層に下位に配信できるようになり、メッセージ セグメント内のデータが必要であることをトランスポート層に知らせることができます。ポートを介して上向きに渡され、アプリケーション層の対応するプロセスに配信されますこの意味で、ポートはアプリケーション層のプロセスを識別するために使用されます。つまり、ポートは寮番号のようなもので、寮内に申請手続きが行われます。

ポート番号

ホスト上では多数のネットワーク アプリケーション プロセスが同時に実行されるため、さまざまなプロセスを識別するには多数のポート番号が必要になります。

ポートは 16 ビットのポート番号で識別され、合計 2 16 = 65536 個のポート番号が許可されます。ポート番号はローカルな意味のみを持ちます。つまり、ポート番号は、このコンピュータのアプリケーション層の各プロセスを識別するためにのみ使用されます。たとえば、ホスト A のポート 8080 とホスト B のポート 8080 の間には接続がありません。

ポートは、ポート番号の範囲に応じて 3 つのカテゴリに分類できます。

  • 既知のポート (予約済みポート):値は通常 0 ~ 1023 です。新しいアプリケーションが表示されると、他のアプリケーション プロセスがそのアプリケーションと対話できるように、ウェルノウン ポートを割り当てる必要があります。

ここに画像の説明を挿入します

  • 登録ポート:値は1024~49151です。既知のポート番号を持たないアプリケーションによって使用されるため、重複を防ぐためにそのようなポート番号を使用するには IANA に登録する必要があります。

  • クライアント ポートまたはエフェメラル ポート: 値は次のとおりです。49152~65535このタイプのポート番号は、クライアント プロセスの実行中にのみ動的に選択されるため、エフェメラル ポートまたはエフェメラル ポートと呼ばれます。通信が完了すると、このポートは他のクライアント プロセスで使用できるように自動的に解放されます。

  • ソケット: IP アドレスを持つホストは、Web サービス、FTP サービス、SMTP サービスなどの多くのサービスを提供できます。これらのサービスは、完全に IP アドレスを通じて実装できます。IP アドレスとポート番号を通じてのみ、接続のポートを一意に決定できます。これはソケットと呼ばれます。

    ソケット = (ホスト IP アドレス、ポート番号)それネットワーク内のホスト上のアプリケーション プロセスを一意に識別します

5.1.3 コネクションレス型サービスとコネクション型サービス

トランスポート層は、次の 2 種類のサービスを提供します。コネクションレス型サービスとコネクション型サービス、対応する実装は次のとおりです。ユーザー データグラム プロトコル (UDP) と伝送制御プロトコル (TCP)

採用されたときTCP、トランスポート層は上向きに全二重の信頼できる論理チャネル;

採用されたときUDP、トランスポート層は上向きに信頼性の低い論理チャネル

UDPの主な特徴

  • データ送信前に接続を確立する必要はなく、データ到着後の確認も必要ありません。
  • 信頼性の低い配送。
  • メッセージ ヘッダーは短く、送信オーバーヘッドは小さく、遅延も短いです。

TCPの主な特徴

  • 接続指向であり、ブロードキャスト サービスやマルチキャスト サービスは提供しません
  • 確実な配送。
  • メッセージ セグメント ヘッダーが長く、送信オーバーヘッドが高くなります。

ネットワーク トランスポート層には、TCP モジュールに TCB (Transmit ControlBlock) があります。TCP操作中に変数を記録するために使用されます複数の接続がある TCP の場合、接続ごとに TCB があります。TCB構造の定義この接続で使用される送信元ポート、宛先ポート、宛先 IP、シーケンス番号、応答シーケンス番号、相手のウィンドウ サイズ、自身のウィンドウ サイズ、TCP ステータスなどが含まれます。

5.2 UDP

5.2.1 UDP データグラム

UDP の基本概念

UDP と TCP の最大の違いは、コネクションレスであることです。UDP は実際には、IP データグラム サービスにポート機能 (プロセスを見つけるため) とエラー検出機能を追加するだけです。

アドバンテージ:

  • データを送信する前に接続を確立する必要はありません。
  • UDP ホストは、複雑な接続状態テーブルを維持する必要がありません。
  • UDP ユーザー データグラムのヘッダー オーバーヘッドは 8 バイトのみです。
  • ネットワーク内の輻輳によって送信元ホストの送信速度が低下することはありません (輻輳制御はありません)。これは、一部のリアルタイム アプリケーション (IP 電話、リアルタイム ビデオ会議など) にとって重要です。
  • UDP は、1 対 1、1 対多、多対 1、および多対多の対話型通信をサポートします。

UDPデータグラムの構成

UDP データグラムには 2 つのフィールドがあります。データフィールドとヘッダーフィールドヘッダフィールドは 8B で 4 つのフィールドで構成されます。

ここに画像の説明を挿入します

  • 送信元ポート: 2B。前述したように、ポート番号を表すのに 16 ビットが使用されるため、2B の長さが必要です。
  • 宛先ポート: 2B。
  • 長さ:2B。
  • チェックサム: 2B を占め、送信中に UDP ユーザー データグラムにエラーがあるかどうかをテストするために使用されます (ヘッダー部分とデータ部分の両方がチェックされます)、エラーがある場合は、それを破棄してください。このフィールドがオプションの場合、ソース ホストがチェックサムを計算したくない場合は、このフィールドをすべて 0 に直接設定できます。検査範囲: 擬似ヘッダー、UDP データグラムヘッダーおよびデータこのうち擬似ヘッダはチェックサム計算時に一時的に生成されるヘッダです。

5.2.2 UDP 検証

UDP チェックサムはエラー検出のみを提供します。チェックサムを計算する際、UDP ユーザー データグラムの前に 12B 擬似ヘッダーが一時的に追加されます。

擬似ヘッダーには、送信元 IP アドレス フィールド、宛先 IP アドレス フィールド、オール 0 フィールド、プロトコル フィールド (UDP は 17 に固定)、および UDP 長さフィールドが含まれます (図 5-5 では、ユーザー データ長が 15B であると想定しています) )ヘッダーはチェックサムの計算と検証にのみ使用され、下方にも上方にも渡されないことに留意することが重要です

ここに画像の説明を挿入します

  • 検証中に、UDP データグラムのデータ部分の長さが偶数バイトでない場合は、すべて 0 のバイトを埋める必要があります。
  • UDP チェックサムによって UDP データグラムが正しくないことが確認された場合、そのデータグラムは破棄するか上位層に配信できますが、エラー レポートを添付する必要があります。つまり、上位層にこれが誤ったデータグラムであることが通知されます。
  • 擬似ヘッダーを通じて、UDP ユーザー データグラムの送信元ポート番号、宛先ポート番号、データ部分を確認できるだけでなく、IP データグラムの送信元 IP アドレスと宛先アドレスも確認できます。

2進数の1の補数コードに従って計算した後、エラーがない場合、結果はすべて 1 になるはずです;それ以外の場合は、エラーが発生したことを示しており、受信側は UDP メッセージを破棄する必要があります。

2 つの数値の 1 の補数和の演算規則は次のとおりです。

  • この操作は、下位ビットから上位ビットまで列ごとに実行されます。
  • 0+0-0、0+1=1、1+1=0 (1 を繰り上げて次の列に加算)。
  • 最上位ビットの加算によりキャリーが発生する場合は、最終結果に 1 を加算する必要があります。

5.3 TCP

5.3.1 TCPセグメント

ここに画像の説明を挿入します

  • 送信元ポートと宛先ポート: それぞれ 2B を占有します。UDP と同様に、TCP ヘッダーにも送信元ポートと宛先ポートがあります。
  • シリアルナンバー:4B。TCP セグメントはアプリケーション層から配信されますが、TCP はバイト ストリームであるため (つまり、TCP はバイトごとに送信されます)、順序どおりに配信されるように、TCP 接続で送信されるバイト ストリームには番号を付ける必要があります。 。
  • 確認番号:4B。TCPには確認メカニズムがありますしたがって、受信者は送信者に確認番号を送信する必要があります。この確認番号について覚えておく必要があるのは、次の 1 つだけです。確認番号が N であれば、シーケンス番号 N-1 までのデータがすべて正しく受信されたことを意味します。
  • データオフセット: 4 ビット。ここでのデータ オフセットは、データ内のフラグメントのデータ オフセットではありません。ヘッダーの長さを示します、混同しないでください。4 ビットで 001 から 1111 までの合計 15 個の状態を表すことができ、基本単位は 4B であるため、データ オフセットによりヘッダーの最大長は 60B になります。
  • 予約済みフィールド: 6 ビット。将来の使用のために予約されていますが、現在は 0 に設定する必要があり、このフィールドは無視できます。
  • 緊急 URG:URG=1 の場合、緊急ポインタフィールドは有効です。このセグメントに緊急データがあり、できるだけ早く送信する必要があることをシステムに伝えます (高優先度データに相当)赤信号を待っている長い車列のようなものです。このとき救急車が来ます。緊急事態です。救急車は赤信号を待たずにすべての車を迂回できます。しかし緊急 URG は緊急ポインターと組み合わせて使用​​する必要がありますたとえば、多くの救急車が来ており、最後の救急車を指す緊急ポインターが必要です。最後の救急車が通過すると、TCP はアプリケーションに通常の動作を再開するように指示します。つまり、データは最初のバイトから始まり、緊急ポインタが指すバイトが緊急データです。
  • 確認応答ビット ACK:ACK=1 の場合のみ確認番号フィールドが有効、ACK=0 の場合、確認番号は無効な TCP 規定接続が確立されると、送信されるすべてのセグメントの ACK ビットが 1 に設定されている必要があります
  • プッシュビットPSH:TCP は、プッシュ ビットが 1 に設定されたセグメントを受信すると、キャッシュ全体がいっぱいになるまで待って上方に配信するのではなく、できるだけ早く受信アプリケーション プロセスに配信します。
  • リセットビット RST:RST=1 の場合、TCP 接続で重大なエラーが発生したことを示します (ホストのクラッシュまたはその他の理由による)。接続を解放し、送信接続を再確立する必要があります。
  • 同期ビット SYN:同期ビット SYN は 1 に設定され、これが接続要求メッセージまたは接続受信メッセージであることを示します。
  • 終端ビット FIN:接続を解放します。FIN=1 の場合、このメッセージセグメントの送信側のデータが送信され、伝送接続を解放する必要があることを示します。
  • 窓枠:2B。ウィンドウ フィールドは、相手が送信するデータ量をバイト単位で制御するために使用されます (B)一文を覚えておいてください。ウィンドウ フィールドは、相手が現在送信できるデータ量を明確に示していますたとえば、確認番号が 701 で、ウィンドウ フィールドが 1000 であるとします。これは、701 番以降、このセグメントの送信側にはまだ 1000B のデータを受信するための受信バッファ スペースがあることがわかります。
  • チェックサムフィールド: 2B。チェックサムフィールド検証の範囲には、ヘッダー部分とデータ部分が含まれます。UDP のようにチェックサムを計算する場合、12B 疑似ヘッダー (UDP 疑似ヘッダーの 4 番目のフィールドの 17 を 6 に変更するだけで、残りは UDP と同じです)。
  • 緊急ポインターフィールド: 2B。
  • オプションフィールド: 可変長。TCP は当初、最大セグメント長 MSS というオプションを 1 つだけ指定していました。MSS は相手側 TCP に「キャッシュが受信できるメッセージ セグメントのデータ フィールドの最大長は MSS バイトです」と伝えます。
  • フィールドに値を入力します。ヘッダー全体の長さを4Bの整数倍にするため

5.3.2 TCP 接続管理

TCP 送信接続は 3 つの段階に分かれています。接続の確立、データ転送、接続の解放TCP トランスポート接続の管理は、トランスポート接続の確立と解放が正常に進行できることを保証することです。

TCP は接続を最も基本的な抽象概念とみなします。各 TCP 接続には 2 つのエンドポイントがあります、TCP 接続のエンドポイントは、ホストでも、ホストの IP アドレスでも、アプリケーション プロセスでも、トランスポート層のプロトコル ポートでもありません。TCP 接続のエンドポイントはソケットまたはソケットと呼ばれますポート番号は IP アドレスに結合されて形成されますソケット

各 TCP 接続は、通信の両端の 2 つのエンドポイント (2 つのソケット) によって一意に識別されます。たとえば、TCP 接続::={ソケット 1, ソケット 2}={(IP1:ポート 1), (IP1:ポート 2)} となります。

TCP 接続と確立はすべて次を使用して行われます。クライアント/サーバーアプローチ(C/S)。接続の確立を能動的に開始するアプリケーション プロセスはクライアントと呼ばれ、接続の確立を受動的に待機するアプリケーション プロセスはサーバーと呼ばれます。

TCP トランスポート接続は、「3回の握手「方法:

ここに画像の説明を挿入します

  • クライアント A の TCP は、接続要求セグメントをサーバー B に送信します。ヘッダー内の同期ビット SYN=1 (TCP では、SYN セグメントはデータを伝送できないと規定されていますが、シーケンス番号が消費されます)を選択し、シリアル番号を選択しますseq=x、データ送信時の最初のデータバイトのシーケンス番号が X であることを示します。
  • サーバーはデータグラムを受信し、SYN ビットからそれが接続を確立する要求であることを認識します。同意した場合は、確認書を返送してください。B は、確認メッセージセグメントに SYN=1、ACK=1、その確認番号 ack=x+1、および選択したシーケンス番号 seq=y を設定する必要があります。現時点では、このセグメントはデータを搬送できないことに注意してください (ニーモニック: SYN=1 であるため、データを搬送できません)。
  • このメッセージセグメントを受信した後、A は B に ACK=1 および確認番号 ack=y+1 で確認を返します。A の TCP は、接続が確立されたことを上位アプリケーション プロセスに通知します。B の TCP は、ホスト A からの確認を受信した後、上位層のアプリケーション プロセスにも通知します。この時点で、TCP 接続は確立されています。ACK メッセージは (SYN フィールドなしで) データを伝送できます。データを伝送しない場合は、 、シーケンス番号は消費されません。

「スリーウェイハンドシェイク」方式を採用し、目的は、送信接続の確立中のメッセージ セグメントのエラーを防ぐことです。メッセージ セグメントが 3 回交換された後、両方の通信当事者のプロセス間で送信接続が確立され、全二重モードを使用するデータ セグメントはトランスポート接続上で通常どおり送信されます。

ここに画像の説明を挿入します

ここに画像の説明を挿入します

ここに画像の説明を挿入します

TCP が接続を解放するプロセス:

  • データ送信が完了すると、通信を行う双方の当事者が接続を解放できます。ここで、A のアプリケーション プロセスは、まず接続解放セグメントを TCP に送信し、データの送信を停止し、TCP 接続をアクティブに閉じます。A は、接続解放メッセージ セグメントのヘッダーの FIN を 1 (シーケンス番号 seq=u) に設定し、B の確認を待ちます。ここで注意しなければならないのは、TCP は二重であるため、つまり、1 対の TCP 接続上に 2 つのデータ パスがあると考えることができます。FIN メッセージを送信する場合、FIN の送信側はデータを送信できません。つまり、データ パスの 1 つが閉じられていますが、もう一方の側は引き続きデータを送信できます。

    ここに画像の説明を挿入します

  • B は確認を送信します。確認番号 ack=u+1、このセグメントのシーケンス番号は seg=v です。TCP サーバー プロセスは、上位レベルのアプリケーション プロセスに通知します。A から B へのこの方向の接続は解放され、TCP 接続はセミクローズ状態になります。B がデータを送信した場合でも、A はデータを受信する必要があります

ここに画像の説明を挿入します

  • B に A に送信するデータがなくなった場合、そのアプリケーション プロセスは TCP に接続を解放するように通知します。

ここに画像の説明を挿入します

  • A は接続解放セグメントを受信した後、確認応答を送信する必要があります。確認メッセージセグメントでは、ACK=1、確認番号ack=w+1、自身のシーケンス番号seq=u+1である。

ここに画像の説明を挿入します

TCP 接続は、実際に解放される前に 2MSL 経過する必要があります。

ここに画像の説明を挿入します

要約:

  • 接続が確立されました
    • SYN=1、シーケンス=x。
    • SYN=1、ACK=1、seq=y、ack=x+1。
    • ACK=1、seq=x+1、ack=y+1。
  • 接続解除
    • FIN=1、seq=u。
    • ACK=1、seq=v、ack=u+1。
    • FIN=1、ACK=1、seq=w、ack=u+1。
    • ACK=1、seq=u+1、ack=w+1。

遅い TCP セグメントのシーケンス番号が、新しい接続で使用されるシーケンス番号の範囲内にないことを確認する必要があります。新しい接続を確立するときに TCP によって選択される最初のシーケンス番号は、以前の接続で使用されたシーケンス番号とは異なる必要があります。したがって、異なる TCP 接続で同じ初期シーケンス番号を使用することはできません。

5.3.3 TCP の信頼性の高い送信

TCP データの番号付けと確認

TCPはバイト指向ですTCP は、送信されるメッセージを次のようにみなします。バイトで構成されるデータストリーム、各バイトをシーケンス番号に対応させます。接続が確立されると、双方が最初のシーケンス番号に同意する必要があります。TCP によって送信される各メッセージ セグメントのヘッダー内のシーケンス番号フィールドの値は、メッセージ セグメント内のデータ部分の最初のバイトのシーケンス番号を表します。

TCP の確認応答は、受信データの最大シーケンス番号の確認応答です。受信側から返される確認番号は、受信データの最大のシーケンス番号に 1 を加えたものです。したがって、確認応答番号は、受信側が次に受信すると予想されるデータの最初のデータ バイトのシーケンス番号を示します。

TCP再送信メカニズム

TCP はセグメントを送信するたびに、このセグメントにタイマーを設定します。タイマーによって設定された再送信時間が指定された時間に達し、確認が受信されない限り、セグメントは再送信されます。

TCP の適応アルゴリズム

  • 各セグメントが送信された時刻と、対応する確認応答セグメントが受信された時刻を記録します。これ2 つの時間の差は、メッセージ セグメントの往復遅延です。

  • 各メッセージセグメントの往復遅延サンプルの加重平均は次のようになります。メッセージセグメントの平均往復遅延(RTT)を取得します。

  • 新しい往復遅延サンプルが測定されるたびに、次の式に従って平均往復遅延が再計算されます。

    RTT=(1-α)×(古いRTT)+α×(新しい往復遅延サンプル)

上式において、0≦α<1です。α が 1 に非常に近い場合は、新たに計算された平均往復遅延 RTT が元の値に比べて大きく変化した、つまり RTT の値が急速に更新されたことを意味します。α が 0 に近い値を選択した場合、重み付けされて計算された RTT が新しい往復遅延サンプルの影響をあまり受けないこと、つまり、RTT の値がゆっくりと更新されることを意味します。一般的に α は 0.125 であることが推奨されます

タイマーの再送信タイムアウト (RTO) は次のとおりです。よりわずかに大きい上記で得られたRTTは、

RTO=β×RTT(β>1)

Karn アルゴリズム: メッセージ セグメントが再送信されるたびに、RTO が増加します。

新 RTO = γ × (旧 RTO)、γ 係数の標準値は 2 です。メッセージ セグメントの再送信が発生しなくなると、重み付けされた RTT 値と RTO 値がメッセージ セグメントの往復遅延に基づいて更新されます。

TCPの信頼性の高いメカニズムの具体化

  • 各 IP データグラムは独立してルーティングされるため、順番どおりに宛先ホストに到着する可能性があります。
  • IP データグラムは、ルーティング計算のエラーにより、ネットワーク上を循環して移動します。最終的に、データグラム ヘッダーの有効期間 TTL の値がゼロになり、データグラムは途中で破棄されました。
  • 特定のルータ上で突然大量のトラフィックが発生し、ルータは到着したデータグラムを処理する時間がなくなり、一部のデータグラムが破棄されます。

5.3.4 TCP フロー制御

一般的に言えば、人々は常にデータがより速く転送されることを望んでいます。ただし、送信者がデータを送信する速度が速すぎると、受信者がデータを受信する時間がなくなり、データ損失が発生する可能性があります。

フロー制御は、送信側の送信が速すぎるのを防ぎ、受信側がネットワークの輻輳を引き起こすことなく時間内に受信できるようにすることです。スライディング ウィンドウ メカニズムを使用すると、TCP 接続のフロー制御を簡単に実装できます。

ここに画像の説明を挿入します

  • TCP には接続ごとに継続時間タイマーがあります。TCP 接続の一方の当事者が他方の当事者からゼロ ウィンドウ通知を受信して​​いる限り、連続タイマーが開始されます。連続タイマーで設定した時間が経過すると、ゼロウィンドウ検出セグメント (1B のデータのみを伝送) が送信され、相手は検出セグメントを確認するときに現在のウィンドウ値を返します。ウィンドウがまだゼロの場合、このセグメントを受信する側は継続時間タイマーをリセットします。ウィンドウがゼロでない場合、デッドロックのデッドロックを突破できます。
  • さまざまなメカニズムを使用して、TCP セグメントを送信するタイミングを制御できます。
    • TCP は、最大セグメント長 (MSS) に等しい変数を維持します。できればキャッシュに格納されたデータが MSS バイトに達すると、TCP セグメントに組み立てられて送信されます。
    • 送信側のアプリケーション プロセスは、メッセージ セグメントを送信する必要があることを示します。TCPでサポートされるプッシュ操作(以前に緊急ポインタと比較されているため、ここでは説明しません)。
    • 送信側のタイマーが期限切れになると、現在キャッシュされているデータがメッセージ セグメントにロードされ (ただし、長さは MSS を超えることはできません)、送信されます。

5.3.5 TCP 輻輳制御の基本概念

一定期間において、ネットワーク内の特定のリソースに対する需要が、そのリソースが提供できる利用可能な部分を超えると、ネットワークのパフォーマンスが低下し、輻輳が発生します。

リソースの輻輳が発生する条件は次のとおりです。リソース要件の合計 > 利用可能なリソース

ネットワーク内で輻輳が発生すると、ネットワークのパフォーマンスが大幅に低下し、入力負荷の増加によりネットワーク全体のスループットが低下します。

輻輳制御とフロー制御のプロパティの比較:

  • 輻輳制御の目的は 1 つだけです。ネットワークが既存のネットワーク負荷に耐えられるようにする
  • 輻輳制御というのは、すべてのホスト、すべてのルーター、およびネットワーク伝送パフォーマンスの低下に関連するすべての要素が関与するグローバル プロセス
  • フロー制御は、特定の送信者と受信者間のポイントツーポイント トラフィックの制御を指すことがよくあります。
  • フロー制御が行う必要があるのは、受信者がデータを受信する時間を確保できるように、送信者がデータを送信する速度を抑制することです。
  • 輻輳制御は (静的ではなく) 動的の問題であるため、設計が困難です。
  • 現在のネットワークは高速化が進んでおり、キャッシュサイズ不足によるパケットロスが発生しやすくなっています。しかしパケット損失はネットワーク輻輳の原因ではなく症状です
  • 多くの場合、まさに、輻輳制御自体がネットワークのパフォーマンス低下やデッドロックの原因となる場合があります。、この点は特に注意する必要があります。

渋滞制御は閉ループ制御と開ループ制御に分けられます

  • オープンループ制御方式は、ネットワークを設計する際には、混雑に関連する要因を事前に考慮し、ネットワーク動作中に混雑を回避するように努めてください。
  • クローズドループ制御は、フィードバックループの概念に基づいて次の対策は閉ループ制御に属します。
    • ネットワーク システムを監視して、いつどこで輻輳が発生するかを検出します。
    • 対策を講じることができる混雑の発生に関する情報を取得します。
    • ネットワーク システムの動作を調整して、発生した問題を解決します。

5.3.6 輻輳制御のための 4 つのアルゴリズム

送信側のホストがメッセージ セグメントの送信速度を決定するときは、受信側の受信能力を考慮するだけでなく、ネットワークの輻輳を引き起こさないように全体的な状況も考慮する必要があります。

TCP では、送信者は次の 2 つのウィンドウを維持する必要があります。

  • 受信機ウィンドウ rwnd: 現在の受信バッファ サイズに基づいて受信機によって約束された最新のウィンドウ値。受信側の容量を反映します受信側は、TCP メッセージのヘッダーのウィンドウ フィールドにそれを配置することで、送信側に通知します。
  • 輻輳ウィンドウ cwnd:ネットワーク輻輳の独自の推定に基づいて送信者によって設定されたウィンドウ値は、ネットワークの現在の容量を反映します。

送信側の送信ウィンドウの上限は、2 つの変数、受信ウィンドウ rwnd と輻輳ウィンドウ cwndの小さい方を取得します。、rwnd と cwnd の小さい方が、送信側がデータを送信する速度を制御します。

送信ウィンドウの上限=Min[rwnd,cwnd]

ここに画像の説明を挿入します

受信ウィンドウのサイズは、TCP メッセージ ヘッダーのウィンドウ フィールドに従って送信側に通知できますが、送信側では輻輳ウィンドウをどのように維持するのでしょうか?

スロースタートアルゴリズムの原理

  • ホストがメッセージ セグメントの送信を開始するとき、最初に輻輳ウィンドウ cwnd=1 を設定します。つまり、最大セグメント長 MSS の値に設定します。
  • 新しいセグメントの確認応答を受信すると、輻輳ウィンドウが 1 ずつ増加します。つまり、MSS の値を 1 つ増やします。
  • この方法を使用して送信者の輻輳ウィンドウ cwnd を徐々に増加させると、ネットワークへのパケット注入速度をより適切なものにすることができます。

スロー スタート アルゴリズムを使用した後、輻輳ウィンドウ cwnd は各送信ラウンド後に 2 倍になります。つまり、cwnd のサイズは指数関数的に増加します。このように、スロー スタートでは常に、輻輳ウィンドウ cwnd が指定されたスロー スタートしきい値 ssthresh (しきい値) まで増加し、その後、輻輳回避アルゴリズムに切り替わります (送信ラウンドにかかる時間は実際には往復時間 RTT です。たとえば、 、輻輳ウィンドウ cwnd= 4。このときの往復時間 RTT は、送信者が 4 つの連続するメッセージ セグメントを送信し、これら 4 つのメッセージ セグメントの確認を受信するのにかかる合計時間です)。

混雑回避アルゴリズムの原理

輻輳ウィンドウ cwnd の拡大がネットワーク輻輳を引き起こすのを防ぐために、状態変数、つまりスロー スタートしきい値 ssthresh も必要です。

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

輻輳回避アルゴリズムは次のように機能します。送信側の輻輳ウィンドウ cwnd は、往復遅延 RTT が経過するたびに 1 MSS サイズずつ増加し、通常は直線的に増加します。

スロースタートフェーズであっても輻輳回避フェーズであっても、送信側がネットワークが輻輳していると判断する限り(確認応答が時間通りに受信されないことが根拠)、送信側は、スロー スタートしきい値 ssthresh は、輻輳が発生した場合に送信ウィンドウ値の半分 (ただし 2 以上) に設定され、その後、輻輳ウィンドウ cwnd が 1 にリセットされ、スロー スタート アルゴリズムが実行されます。この目的は、ホストからネットワークに送信されるパケットの数を迅速に減らし、輻輳が発生しているルータがキュー内のパケットのバックログを処理するのに十分な時間を確保できるようにすることです。

  • TCP 接続が初期化されると、輻輳ウィンドウを 1 に設定します図 5-16 に示すように。図のウィンドウ単位はバイトではなくセグメントを使用します。スロースタートしきい値の初期値は 16 セグメントに設定されています。ssthresh=16送信側の送信ウィンドウは、輻輳ウィンドウ cwnd と受信ウィンドウ rwnd の最小値を超えることはできません。受信ウィンドウが十分に大きいと想定されます。したがって、送信ウィンドウの値は輻輳ウィンドウの値と等しくなります

ここに画像の説明を挿入します

  • スロー スタート アルゴリズムを実行する場合、輻輳ウィンドウ cwnd の初期値は 1 で、最初のメッセージ セグメント M0 が送信されます。

ここに画像の説明を挿入します

  • 送信者は確認応答を受信するたびに cwnd を 1 ずつインクリメントするため、送信者は2 つのメッセージ セグメントM 1および M 2を送信できるようになります。

    ここに画像の説明を挿入します

  • 受信側は合計 2 つの確認応答を送り返します。送信者が新しいセグメントの確認応答を受信するたびに、送信者の cwnd が 1 ずつ増加します。これで cwnd が 2 から 4 に増加し、次の 4 セグメントを送信できるようになります。

    ここに画像の説明を挿入します

  • 送信側が新しいセグメントの確認応答を受信するたびに、送信側の輻輳ウィンドウが 1 ずつ増加します。したがって、輻輳ウィンドウ cwnd は送信回数に応じて指数関数的に増加します。

ここに画像の説明を挿入します

  • 輻輳ウィンドウ cwnd が開始しきい値 ssthresh まで増大すると (cwnd=16 の場合)、代わりに輻輳回避アルゴリズムが実行され、輻輳ウィンドウは線形法則に従って増大します。

    ここに画像の説明を挿入します

  • 輻輳ウィンドウの値が 24 に増加すると、ネットワークがタイムアウトになり、ネットワークが輻輳していることを示しているとします。

ここに画像の説明を挿入します

  • 更新された ssthresh 値は 12 (送信ウィンドウ値 24 の半分) になり、輻輳ウィンドウは 1 にリセットされ、スロー スタート アルゴリズムが実行されます。

ここに画像の説明を挿入します

  • cwnd=12 の場合、代わりに輻輳回避アルゴリズムが実装され、輻輳ウィンドウは直線的に増加し、往復遅延ごとに MSS のサイズが 1 ずつ増加します。

ここに画像の説明を挿入します

要約:

  • 乗算的に減少します。つまり、スロースタートフェーズでも輻輳回避フェーズでも、タイムアウト(ネットワーク輻輳が発生)している限り、スロー スタートしきい値 ssthresh は、現在の輻輳ウィンドウ値の半分に設定されます。ネットワークが頻繁に輻輳する場合、ネットワークに注入されるパケットの数を減らすために、ssthresh 値が急速に減少します。
  • 加算が増えます。その意味は輻輳回避アルゴリズムを実行する場合、すべてのメッセージ セグメントに対する確認応答を受信した後 (往復時間後)、輻輳ウィンドウ cwnd は MSS サイズだけ増加します。、早期のネットワーク輻輳を防ぐために輻輳ウィンドウを徐々に増やします。
  • 渋滞回避といっても、完全に渋滞を回避できるわけではありません上記の対策を行っても、ネットワークの混雑を完全に回避することはまだ不可能です。輻輳回避とは、輻輳回避フェーズ中に線形に拡大するように輻輳ウィンドウを制御し、ネットワークが輻輳しにくくすることを意味します。

ここに画像の説明を挿入します

高速再送信アルゴリズム

まず、受信者は、順序が乱れたメッセージ セグメントを受信した直後に、重複した確認応答を送信する必要があります。これにより、送信者は、受信者に到達していないセグメントがあることを早期に知ることができます。送信者は、連続して 3 回の重複確認応答を受信する限り、相手方がまだ受信していないメッセージ セグメントを直ちに再送信する必要があります。
ここに画像の説明を挿入します

クイックリカバリアルゴリズム

  • 送信側が 3 回連続して繰り返される確認応答フレームを受信すると、「乗算リダクション」アルゴリズムを実行し、スロー スタートしきい値 ssthresh を現在の輻輳ウィンドウの半分に設定します。ただし、スロースタートアルゴリズムは実行されません。

  • 送信側は、ネットワークが混雑していないと考えているため、スロー スタート アルゴリズムを実行しません。つまり、混雑ウィンドウ cwnd は 1 に設定されません。代わりに、スロー スタートしきい値 ssthresh が 1/2 に設定されます。現在の輻輳ウィンドウが増加し、その後輻輳回避アルゴリズム (「相加的成長」) が開始され、輻輳ウィンドウが直線的にゆっくりと増加します。

ここに画像の説明を挿入します

迅速な回復アルゴリズムは次のとおりです。

  • 送信者が受信したときACKを3回連続で繰り返した場合、スロー スタートしきい値 ssthresh (輻輳ウィンドウの半分) をリセットします。
  • 最初との違いは、輻輳ウィンドウ cwnd が 1 に設定されず、新しい ssthresh に設定されることです。
  • 送信ウィンドウ値がまだメッセージ セグメントの送信を許可している場合、セグメントは輻輳回避アルゴリズムに従って引き続き送信されます。

おすすめ

転載: blog.csdn.net/pipihan21/article/details/129572306