第5章 トランスポート層

1. トランスポート層の概要

• これまでのコースで紹介したコンピュータ ネットワーク アーキテクチャの物理層、データリンク層、およびネットワーク層は、異種ネットワークを介してホストを相互接続する際に直面する問題を共同で解決し、ホスト間通信を実現します。

• しかし、コンピュータ ネットワーク内で実際に通信を行う実体は、通信の両端にあるホスト内のプロセスです。

• 異なるホスト上で実行されているアプリケーション プロセスに直接通信サービスを提供する方法はトランスポート層のタスクであり、トランスポート層プロトコルはエンドツーエンド プロトコルとも呼ばれます。

トランスポート層は、アプリケーションプロセス間の論理通信のためのサービスを直接提供します。

トランスポート層は、基礎となるネットワーク コアの詳細 (ネットワーク トポロジ、採用されているルーティング プロトコルなど) から上位ユーザーを保護します。これにより、アプリケーション プロセスは、2 つの間にエンドツーエンドの論理通信があるかのように見えます。トランスポート層エンティティチャネル。

インターネットのトランスポート層では、さまざまなアプリケーション要件に応じて、アプリケーション層に 2 つの異なるトランスポート プロトコル (コネクション型 TCP とコネクションレス型 UDP) が提供されており、この 2 つのプロトコルがこの章で説明する主な内容です。

2. トランスポート層のポート番号、多重化、逆多重化の概念

• コンピューター上で実行されているプロセスは、プロセス識別子 PIDによって識別されます。

• インターネット上のコンピュータは統一されたオペレーティング システムを使用しておらず、異なるオペレーティング システム (Windows、Linux、Mac OS) ごとに異なる形式のプロセス識別子を使用しています。

• 異なるオペレーティング システムを実行しているコンピュータのアプリケーション プロセス間のネットワーク通信を可能にするには、統一された方法を使用して TCP/IP システムのアプリケーション プロセスを識別する必要があります。

• TCP/IP システムのトランスポート層は、ポート番号を使用して、アプリケーション層内のさまざまなアプリケーション プロセスを区別します。

  • ポート番号は16 ビットで表され、値の範囲は 0 ～ 65535 です。
  • 一般的なポート番号: 0 ～ 1023。IANA はこれらのポート番号を TCP/IP システムの最も重要なアプリケーション プロトコルのいくつかに割り当てます。たとえば、FTP は 21/20 を使用し、HTTP は 80 を使用し、DNS は 53 を使用します。
  • 登録ポート番号：1024～49151、ウェルノウンポート番号を持たないアプリケーションで使用されます。このようなポート番号を使用する場合は、重複を防ぐために所定の手順に従ってIANAに登録する必要があります。例: Microsoft RDP Microsoft リモート デスクトップはポート 3389 を使用します。
  • 一時ポート番号: 49152 ～ 65535、クライアント プロセスが一時的に使用することを選択するために予約されています。サーバー プロセスは、クライアント プロセスからメッセージを受信すると、クライアント プロセスが使用する動的ポート番号を認識します。通信が終了すると、このポート番号は他のクライアント プロセスで使用できるようになります。
  • ポート番号はローカルな意味のみを持ちます。つまり、ポート番号はコンピュータのアプリケーション層でプロセスを識別するためにのみ使用されます。インターネットでは、異なるコンピュータの同じポート番号は関係ありません。

送信側での多重化と受信側での逆多重化

• TCP/IP システムのアプリケーション層の共通プロトコルで使用されるトランスポート層のウェルノウン ポート番号

3. UDPとTCPの比較

UDP はユニキャスト、マルチキャスト、ブロードキャストをサポートします

TCP はユニキャストのみをサポートします

UDP はアプリケーション指向です

TCPはバイトストリーム指向です

UDP は、コネクションレスで信頼性の低い伝送サービスを上位層に提供します (IP 電話やビデオ会議などのリアルタイム アプリケーションに適しています)

TCP は、コネクション型の信頼性の高い伝送サービスを上位層に提供します (ファイル伝送など、信頼性の高い伝送が必要なアプリケーションに適しています)

4. TCPフロー制御

• 一般に、私たちは常にデータがより速く転送されることを望んでいます。

  • ただし、送信者がデータを送信する速度が速すぎると、受信者がデータを受信する時間がなくなり、データ損失が発生する可能性があります。

• いわゆるフロー制御（フロー制御）は、受信者が受信する時間を確保できるように、送信者の送信速度を速すぎないようにすることです。

• 送信側のフロー制御は、スライディング ウィンドウ メカニズムを使用して TCP 接続に簡単に実装できます。

[[2010 問 39] ホスト A とホスト B の間に TCP 接続が確立され、最大 TCP セグメント長は 1000 バイトです。ホスト A の現在の輻輳ウィンドウが 4000 バイトの場合、ホスト A が最大 2 つのセグメントをホスト B に連続して送信した後、ホスト B が送信した最初のセグメントの確認応答セグメントを正常に受信し、確認応答セグメントで通知される受信ウィンドウ サイズは次のようになります。 2000 バイトの場合、現時点でホスト A がホスト B に送信できる最大バイト数は A
A.1000
B.2000
C.3000
D.4000になります。

【分析】

TCP 送信者の送信ウィンドウ = min[自己の輻輳ウィンドウ、TCP 受信者の受信ウィンドウ]

このトピックでは、TCP 送信者の送信ウィンドウの初期値を指定せず、輻輳ウィンドウの値を送信ウィンドウの値として取得します。

5. TCP輻輳制御

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

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

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

以下の条件を前提として、これら 4 つの輻輳制御アルゴリズムの基本原理を以下に紹介します。

1. データは一方向に送信され、確認応答のみが逆方向に送信されます。
2. 受信側には常に十分なバッファ スペースがあるため、送信側の送信ウィンドウのサイズはネットワークの輻輳レベルによって決まります。
3. 議論の単位は、バイトではなく、最大メッセージ セグメント MSS の数です。

5.1 スロースタートと混雑回避

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

  • 輻輳ウィンドウ cwnd の維持原則: ネットワークに輻輳がない限り、輻輳ウィンドウは増加しますが、ネットワークが輻輳している限り、輻輳ウィンドウは減少します。
  • ネットワーク輻輳発生の判断基準：到着するはずの確認応答メッセージが時間通りに受信されなかった（タイムアウト再送が発生した）。

• 送信側は、輻輳ウィンドウを送信ウィンドウ swnd、つまり swnd = cwnd として受け取ります。

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

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

再送信タイマーが期限切れになりました

ネットワークが混雑している可能性があると判断し、以下の作業を行ってください。

• 輻輳が発生した場合は、ssthresh 値を cwnd 値の半分に更新します。

• cwnd 値を 1 に減らし、スロー スタート アルゴリズムを再起動します。

「スロースタート」とは、最初にネットワークに注入されるセグメントがほとんどないことを意味し、輻輳ウィンドウ cwnd の増加が遅いことを意味するものではありません。

「輻輳回避」とは、輻輳を完全に回避できることを意味するのではなく、輻輳回避フェーズ中に輻輳ウィンドウが線形に拡大するように制御され、ネットワークが輻輳しにくくなるという意味です。

5.2 高速再送信と高速リカバリ

• スロースタートおよび輻輳回避アルゴリズムは、1988 年に提案された TCP 輻輳制御アルゴリズム (TCP Tahoe バージョン) です。

• 1990 年に、(TCP のパフォーマンスを向上させるために) 高速再送信と高速回復 (TCP Reno バージョン) という 2 つの新しい輻輳制御アルゴリズムが追加されました。

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

• 高速再送信アルゴリズムを使用すると、送信者は個々のメッセージ セグメントの損失をできるだけ早く知ることができます。

• いわゆる高速再送信は、再送信前にタイムアウト再送信タイマーの期限が切れるのを待つのではなく、送信者にできるだけ早く再送信させることです。

  • 受信者は、データを送信するときにピギーバック確認を待つのではなく、すぐに確認を送信する必要があります。
  • 順序どおりでないセグメントを受信した場合でも、受信したセグメントの重複した確認応答が直ちに発行される必要があります。
  • 送信者は、連続する 3 つの重複確認応答を受信すると、セグメントのタイムアウト再送信タイマーが期限切れになるのを待ってから再送信するのではなく、対応するセグメントをただちに再送信します。
  • 個々の失われたセグメントについては、送信者は時間外に再送信することはなく、輻輳が発生していると誤って認識することはありません（その後、輻輳ウィンドウ cwnd を 1 に削減します）。高速再送信を使用すると、ネットワーク全体のスループットが約 20% 向上します。

• 送信者が 3 回繰り返される確認応答を受信すると、個々のセグメントだけが失われたことがわかります。したがって、スロー スタート アルゴリズムは開始されませんが、高速リカバリ アルゴリズムが実行されます。
  • 送信側は、スロー スタートしきい値 ssthresh 値と輻輳ウィンドウ cwnd 値を現在のウィンドウの半分に調整し、輻輳回避アルゴリズムの実行を開始します。
  • 一部の高速リカバリ実装では、高速リカバリの開始時に輻輳ウィンドウ cwnd の値が増加します。これは new = ssthresh + 3 に等しくなります。
    • 送信者は 3 回繰り返し確認応答を受信したため、3 つのデータ セグメントがネットワークから出たことを意味します。
    • これら 3 つのメッセージ セグメントはネットワーク リソースを消費しなくなり、受信者の受信バッファーに残ります。
    • ネットワーク内にメッセージ セグメントが蓄積されるのではなく、3 つのメッセージ セグメントが削減されたことがわかります。したがって、輻輳ウィンドウを適切に拡大することができる。

[2009 Question 39] TCP 接続は常に最大セグメント長 1KB の TCP セグメントを送信します。送信側には送信するのに十分なデータがあります。輻輳ウィンドウが 16KB のときにタイムアウトが発生した場合、次の 4 RTT (往復時間) 以内の TCP セグメントの送信が成功し、4 番目の RTT 時間内に送信されたすべての TCP セグメントが肯定的な応答を取得すると、輻輳が発生します。ウィンドウ サイズは C
A.7KB
B.8KB
C.9KB
D.16KB

6. TCPタイムアウト再送時間の選択

• 特定の測定から得られた RTT サンプルを直接使用して、タイムアウト再送信時間 RTO を計算することはできません。

• 各測定から得られた RTT サンプルを使用して、加重平均往復時間 RTT (平滑化往復時間とも呼ばれる) が計算されます。

• この方法で得られた加重平均往復時間 RTT は、測定された RTT 値よりも滑らかです。

• 明らかに、超過再送信時間 RTO は加重平均往復時間 RTT よりわずかに大きくなければなりません。

7. TCPの確実な伝送の実現

• TCP はバイト単位のスライディング ウィンドウに基づいており、信頼性の高い送信を実現します。

• 送信者の送信ウィンドウは受信者の受信ウィンドウに応じて設定されますが、同時に、送信者の送信ウィンドウが受信者の受信ウィンドウと同じ大きさであるとは限りません。

  • ネットワーク送信ウィンドウの値には一定のタイムラグが必要ですが、この時間はまだ不確実です。
  • 送信者は、その時点のネットワークの混雑状況に応じて、送信ウィンドウのサイズを適切に縮小することもできます。

• TCP では、順序どおりに到着しないデータの処理方法を明確に規定していません。

  • 受信者が順序どおりに到着しないデータを破棄すると、受信ウィンドウの管理は比較的簡単になりますが、送信者はさらに多くのデータを繰り返し送信することになるため、ネットワーク リソースの利用には良くありません。

  • TCP は通常、順序が乱れて到着したデータを最初に受信ウィンドウに一時的に格納し、バイト ストリーム内の欠落バイトを受信した後、そのデータを上位層のアプリケーション プロセスに順番に渡します。

• TCP では、受信側に、送信オーバーヘッドを削減できる累積確認応答およびピギーバック確認応答メカニズムが必要です。受信者は、適切なタイミングで確認を送信したり、送信するデータがある場合に確認メッセージを一緒に送信したりできます。

  • 受信者は確認応答の送信を遅らせすぎないでください。そうしないと、送信者が不要なタイムアウトを再送信することになり、ネットワーク リソースが無駄になります。TCP 標準では、確認遅延が 0.5 秒を超えてはならないと規定されています。最大長のセグメントのシーケンスを受信した場合、他のセグメントごとに確認応答を送信しなければなりません[RFC 1122]。
  • ほとんどのアプリケーションは同時に両方向にデータを送信することはめったにないため、ピギーバックは実際にはそれほど頻繁には起こりません。

• TCP通信は全二重通信です。通信の各当事者はセグメントを送信および受信します。したがって、各側には独自の送信ウィンドウと受信ウィンドウがあります。これらの窓については、どちら側の窓であるかを必ず確認してください。

[2009 質問 38] ホスト A とホスト B の間に TCP 接続が確立されました。ホスト A は、それぞれ 300 バイトと 500 バイトのペイロードを含む 2 つの連続した TCP セグメントをホスト B に送信しました。最初のセグメントのシリアル番号は 200 です。ホスト以降B は 2 つのセグメントを正しく受信し、ホスト A に送信される確認シリアル番号は D
A.500
B.700
c.800
D.1000です。

[2011 質問 40] ホスト A とホスト B の間で TCP 接続が確立され、ホスト A は、それぞれ 300 バイト、400 バイト、500 バイトのペイロードを含む 3 つの連続する TCP セグメントをホスト B に送信しました。3 番目のセグメントのシーケンス番号は900です。ホスト B が最初と 3 番目のセグメントのみを正しく受信した場合、ホスト B からホスト A に送信される確認シーケンス番号は B
A.300
B.500
C.1200
D.1400になります。

8. TCPトランスポート接続管理

8.1 TCP接続の確立

• TCP はコネクション指向のプロトコルであり、トランスポート接続に基づいて TCP セグメントを送信します。

• TCP トランスポート接続の確立と解放は、あらゆるコネクション指向の通信において不可欠なプロセスです。

• TCP トランスポート接続には次の 3 つのフェーズがあります。

  1. TCP接続を確立する
  2. データ送信
  3. TCP接続を解放する

• TCP のトランスポート接続管理は、トランスポート接続の確立と解放が正常に進行できるようにすることです。

• TCP 接続を確立するには、次の 3 つの問題を解決する必要があります。

  1. 両方の TCP 当事者が互いの存在を認識できるようにします。
  2. 両方の TCP 当事者がいくつかのパラメータ (最大ウィンドウ値、ウィンドウ拡張オプションとタイムスタンプ オプションを使用するかどうか、サービス品質など) をネゴシエートできるようにします。
  3. 両方の TCP 当事者がトランスポート エンティティ リソース (バッファ サイズ、接続テーブル内のエントリなど) を割り当てることができるようにします。

TCP は「3 メッセージ ハンドシェイク」を使用して接続を確立します

[2011 Question 39] ホスト A は、ホスト B との TCP 接続を確立することを期待して、TCP セグメント (SYN=1、seq=11220) をホスト B に送信します。ホスト B が接続要求を受け入れると、ホスト B はホスト A に送信します。正しい TCP セグメントは C である可能性があります。
A.(SYN=0, ACK=0, seq=11221, ack=11221)
B.(SYN=1,ACK=1, seq=11220, ack=11220)
C.(SYN= 1 ) 、ACK=1、seq=11221、ack=11221)
D. (SYN=0、ACK=0、seq=11220、ack=11220)

8.2 TCP接続の解放

9. TCPセグメントのヘッダー形式

• 信頼性の高い送信を実現するために、TCP はバイト ストリーム指向のアプローチを採用しています。

• ただし、TCP がデータを送信するときは、送信バッファから一部またはすべてのバイトを取得し、ヘッダーを追加して TCP セグメントにしてから送信します。

  • TCP セグメントは、ヘッダーとデータ ペイロードの 2 つの部分で構成されます。
  • TCP のすべての機能は、ヘッダー内の各フィールドの役割に反映されます。

送信元ポート: 16 ビットを占有し、送信元ポート番号を書き込み、TCP セグメントを送信するアプリケーション プロセスを識別するために使用されます。

宛先ポート: 16 ビットを占有し、宛先ポート番号を書き込み、TCP セグメントを受信するアプリケーション プロセスを識別するために使用されます。

シリアル番号: 32 ビットを占め、値の範囲は [0,232-1] で、シリアル番号が最後の番号まで増加すると、次のシリアル番号は 0 に戻ります。この TCP セグメントのデータ ペイロードの最初のバイトのシーケンス番号を示します。

確認番号: 32 ビットを占有し、値の範囲は [0,22-1] で、確認番号が最後まで増加すると、次の確認番号は 0 に戻ります。相手の次の TCP セグメントによって受信されることが予想されるデータ ロードの最初のバイトのシーケンス番号を示します。これは、以前に受信したすべてのデータの確認応答でもあります。確認番号＝ｎの場合は、シーケンス番号ｎ－１までのデータが全て正しく受信されたことを意味し、シーケンス番号ｎのデータを受信することが期待される。

確認フラグビット ACK: 確認番号フィールドは値が 1 の場合のみ有効で、値が 0 の場合は確認番号フィールドは無効です。TCP では、接続が確立された後、送信されるすべての TCP セグメントで ACK を 1 に設定する必要があると規定しています。

データオフセット：4ビットを占有し、4バイトを単位とします。これは、TCP セグメントのデータ ペイロード部分の先頭が TCP セグメントの先頭からどのくらい離れているかを示すために使用されます。このフィールドは実際には、TCP セグメントのヘッダー長を示します。
ヘッダーの固定長は 20 バイトであるため、データ オフセット フィールドの最小値は (0101)2 です。 ヘッダーの最大長は 60 バイトであるため、データ オフセット フィールドの最大値は (1111)2 です。

予約済み: 6 ビットを占有し、将来の使用のために予約されていますが、現時点では 0 に設定する必要があります。

ウィンドウ: バイト単位で 16 ビットを占有します。このセグメントを送信する側の受信ウィンドウを示します。ウィンドウ値は、受信者が送信者に送信ウィンドウを設定させるための基礎として機能します。これは、受信者の受信能力によって送信者の送信能力を制御するものであり、フロー制御と呼ばれる。

同期フラグ SYN: TCP 接続確立時にシリアル番号を同期するために使用されます。

終了フラグ FIN: TCP 接続を解放するために使用されます。

リセットフラグ RST: TCP 接続をリセットするために使用されます。RST=1 の場合、TCP 接続が異常であることを示し、接続を解放してから再確立する必要があります。RST を 1 に設定すると、不正なセグメントを拒否したり、TCP 接続を開くことを拒否したりするためにも使用されます。

プッシュ フラグ ビット PSH: 受信側の TCP は、フラグ ビットが 1 に設定されたセグメントを受信した後、受信バッファがいっぱいになるまで待ってから配信するのではなく、できるだけ早くセグメントをアプリケーション プロセスに渡します。

緊急フラグビット URG: 値が 1 の場合、緊急ポインタフィールドは有効であり、値が 0 の場合、緊急ポインタフィールドは無効です。

緊急ポインタ: バイト単位で 16 ビットを占め、緊急データの長さを示すために使用されます。送信者に緊急データがある場合、緊急データは送信バッファの先頭にキューに入れられ、すぐに TCP セグメントにカプセル化されて送信されます。緊急ポインタは、このメッセージ セグメントのデータ ペイロードに緊急データがどのくらいの長さ含まれているかを示し、通常のデータが緊急データの後に続きます。

パディング: オプションの長さは可変であるため、メッセージ セグメントのヘッダーが 4 で割り切れるようにパディングが使用されます (データ オフセット フィールド、つまりヘッダー長フィールドが 4 バイト単位であるため)。 。

参考：

5.9 TCP セグメントのヘッダー形式_哔哩哔哩_bilibili