本記事は James Kurose, Keith Ross 著 Computer Networking: A Top-Down Approach (6th Edition) の教科書を基にまとめた内容です。

1. トランスポート層のサービス

1.1 トランスポート層の役割

トランスポート層は異なるホストで実行される**プロセス**間の論理的な通信を提供する。

ネットワーク層： ホスト間（host-to-host）通信

トランスポート層：プロセス間（process-to-process）通信

┌────────┐ ┌────────┐

│ App P1 │ │ App P3 │

│ App P2 │ │ App P4 │

├────────┤ ├────────┤

│トランス │ ←── 論理的通信 ──→ │トランス │

│ポート │ │ポート │

├────────┤ ├────────┤

│ネットワーク│ ←── 論理的通信 ──→│ネットワーク│

└────────┘ └────────┘

ホストA ホストB

1.2 トランスポート層とネットワーク層の関係

比喩：家と家の郵便システム

家（ホスト）A 家（ホスト）B

Ann（プロセス） Bob（プロセス）

Bill（プロセス） Carol（プロセス）

トランスポート層 = 家で手紙を仕分けしてくれる人

（どの家族に届けるかを決定）

ネットワーク層 = 郵便局

（家Aから家Bへ手紙を配達）

> トランスポート層はネットワーク層が提供しないサービスを独自に追加できる。例えば、信頼性のないIP上に信頼性のあるTCPを実装する。

1.3 インターネットトランスポート層の2つのプロトコル

TCP (Transmission Control Protocol):

├── コネクション指向（3ウェイハンドシェイク）

├── 信頼性のあるデータ転送

├── フロー制御（受信者保護）

├── 輻輳制御（ネットワーク保護）

└── 順序保証

UDP (User Datagram Protocol):

├── コネクションレス

├── 信頼性なし（ベストエフォート配信）

├── フロー/輻輳制御なし

└── 順序保証なし

2. 多重化と逆多重化（Multiplexing / Demultiplexing）

2.1 概念

1つのホストで複数のプロセスが同時にネットワークを使用する。トランスポート層はこれを管理しなければならない。

多重化（Multiplexing）：

送信側で複数のソケットのデータを収集し

トランスポート層ヘッダを付けてネットワーク層に渡す

逆多重化（Demultiplexing）：

受信側でトランスポート層セグメントを受け取り

正しいソケット（プロセス）に配信する

逆多重化の動作：

ネットワーク層からセグメント受信

│

↓

トランスポート層：セグメントヘッダのポート番号を確認

│

├──→ ポート80 → Webサーバープロセス

├──→ ポート25 → メールサーバープロセス

└──→ ポート53 → DNSサーバープロセス

2.2 ポート番号

トランスポート層がプロセスを識別するために使用する16ビットの数値である。

ポート番号範囲：0 〜 65535

0 〜 1023: ウェルノウンポート（Well-Known Ports）

HTTP(80)、HTTPS(443)、DNS(53)、SMTP(25)

1024 〜 49151: 登録ポート（Registered Ports）

49152 〜 65535: 動的/一時ポート（Dynamic/Ephemeral Ports）

クライアントが自動割り当てで使用

2.3 セグメントヘッダのポート番号フィールド

トランスポート層セグメント：

┌──────────────┬──────────────┐

│ 送信元ポート │ 宛先ポート │ ← 各16ビット

├──────────────┴──────────────┤

│ その他のヘッダフィールド │

├─────────────────────────────┤

│ アプリケーションデータ │

└─────────────────────────────┘

2.4 コネクションレス逆多重化（UDP）

UDPソケットは**（宛先IP、宛先ポート）**の2タプルで識別される。

サーバー：IP=10.0.0.1、ポート=46428

クライアントA（IP=10.0.0.2、送信元ポート=9157）

→ 宛先：10.0.0.1:46428

クライアントB（IP=10.0.0.3、送信元ポート=9157）

→ 宛先：10.0.0.1:46428

両データグラムとも同じソケットに配信される！

（送信元IPが異なっても宛先ポートが同じため）

2.5 コネクション指向逆多重化（TCP）

TCPソケットは**（送信元IP、送信元ポート、宛先IP、宛先ポート）**の4タプルで識別される。

サーバー：IP=10.0.0.1、ポート=80

クライアントA（IP=10.0.0.2、送信元ポート=9157）

→ 4タプル：(10.0.0.2, 9157, 10.0.0.1, 80)

→ 専用接続ソケット1

クライアントB（IP=10.0.0.3、送信元ポート=9157）

→ 4タプル：(10.0.0.3, 9157, 10.0.0.1, 80)

→ 専用接続ソケット2

同じ送信元ポートでもIPが異なれば別のソケット！

TCPサーバーのソケット構造：

ウェルカムソケット（ポート80）

│

├── 接続ソケット1：(10.0.0.2:9157, 10.0.0.1:80)

├── 接続ソケット2：(10.0.0.3:9157, 10.0.0.1:80)

└── 接続ソケット3：(10.0.0.2:5775, 10.0.0.1:80)

各接続が一意の4タプルで区別される

3. UDP（User Datagram Protocol）

3.1 UDPの特徴

UDPはトランスポート層ができる**最小限のこと**だけを行う。

UDPが行うこと：

✓ 多重化/逆多重化（ポート番号）

✓ 簡単なエラー検出（チェックサム）

UDPが行わないこと：

✗ 接続設定

✗ 信頼性のある配信

✗ フロー制御

✗ 輻輳制御

✗ 順序保証

3.2 なぜUDPを使用するのか

UDPの利点：

1. 接続設定なし → 遅延削減（DNSがUDPを使用する理由）

2. 接続状態なし → より多くのクライアントをサポート可能

3. 小さなヘッダオーバーヘッド → 効率的（UDP: 8バイト、TCP: 20バイト）

4. 転送率制限なし → アプリケーションが望む速度で送信

UDPを使用するアプリケーション

| アプリケーション | プロトコル | 理由 |

| ---------------------- | ---------- | --------------------------------------- |

| DNS | UDP | 単純な問い合わせ-応答、高速な応答が必要 |

| SNMP | UDP | ネットワーク管理、シンプルなリクエスト |

| ストリーミングメディア | UDP/TCP | 若干の損失許容、リアルタイム性重要 |

| インターネット電話 | UDP | リアルタイム性が信頼性より重要 |

| オンラインゲーム | UDP | 低遅延が必須 |

3.3 UDPセグメント構造

┌──────────────────┬──────────────────┐

│ 送信元ポート(16) │ 宛先ポート(16) │

├──────────────────┼──────────────────┤

│ 長さ(16) │ チェックサム(16) │

├──────────────────┴──────────────────┤

│ │

│ アプリケーションデータ（ペイロード） │

│ │

└──────────────────────────────────────┘

ヘッダサイズ：8バイト（4フィールド x 2バイト）

| フィールド | サイズ | 説明 |

| ------------ | -------- | ---------------------------------------- |

| 送信元ポート | 16ビット | 送信プロセスのポート |

| 宛先ポート | 16ビット | 受信プロセスのポート |

| 長さ | 16ビット | UDPセグメント全体の長さ（ヘッダ+データ） |

| チェックサム | 16ビット | エラー検出用 |

4. UDPチェックサム（Checksum）

4.1 目的

セグメントが転送中に変更（ビットエラー）されたかどうかを検出する。

4.2 計算方法

セグメントのすべての16ビットワードを加算し、1の補数を取る。

例：3つの16ビットワード

0110 0110 0110 0000

0101 0101 0101 0101

1000 1111 0000 1100

ステップ1：最初の2つのワードを加算

0110 0110 0110 0000

+ 0101 0101 0101 0101

─────────────────────

1011 1011 1011 0101

ステップ2：結果に3番目のワードを加算

1011 1011 1011 0101

+ 1000 1111 0000 1100

─────────────────────

0100 1010 1100 0001（桁上がり時wraparound）

ステップ3：1の補数を取る

0100 1010 1100 0001

→ 1011 0101 0011 1110 ← これがチェックサム

4.3 エラー検出プロセス

送信側：

1. チェックサムフィールドを0に設定

2. セグメントのすべての16ビットワードを加算

3. 1の補数を取りチェックサムフィールドに格納

受信側：

1. セグメントのすべての16ビットワードを加算（チェックサム含む）

2. 結果がすべて1であれば → エラーなし（高確率）

3. 1つでも0があれば → エラー発生！

検証例（エラーなしの場合）：

データワードの合計 + チェックサム = 1111 1111 1111 1111

→ すべてのビットが1 → 正常

検証例（エラーありの場合）：

ビットエラーにより合計が 1111 1011 1111 1111

→ 0が含まれている → エラー検出！

4.4 チェックサムの限界

チェックサムの限界：

1. エラー検出は可能だがエラー訂正（correction）は不可

2. 一部のエラーを見逃す可能性（例：2ビットが相補的に変化）

3. UDPはエラーを検出しても何も対処しない

- 破損したセグメントを破棄するか、警告付きでアプリケーションに渡す

> UDPがチェックサムを提供する理由：すべてのリンク層プロトコルがエラー検出を提供するわけではなく、メモリ内でビットエラーが発生する可能性もあるためである。**エンドツーエンド原則（end-to-end principle）**に従い、トランスポート層でもエラー検出を行う。

5. UDP上の信頼性のある転送

UDP自体は信頼性のある転送を提供しないが、**アプリケーション層**で信頼性を実装できる。

アプリケーションレベルの信頼性実装：

├── 確認応答（ACK）メカニズム

├── 再送タイマー

└── シーケンス番号

例：QUICプロトコル（HTTP/3で使用）

- UDP上に信頼性のある転送を実装

- TCPより高速な接続設定

- マルチプレキシングサポート

6. まとめ

トランスポート層の要約：

多重化/逆多重化：

├── UDP：（宛先IP、宛先ポート）の2タプルでソケット識別

└── TCP：（送信元IP、送信元ポート、宛先IP、宛先ポート）の4タプル

UDP：

├── コネクションレス、信頼性なし

├── 8バイトヘッダ（送信元ポート、宛先ポート、長さ、チェックサム）

├── チェックサムでエラー検出

└── リアルタイムアプリケーションに適合

7. 確認問題

- **UDP**：宛先IPと宛先ポートのみでソケットを識別する（2タプル）。したがって、送信元が異なる2つのデータグラムも同じ宛先ポートであれば同じソケットに配信される。

- **TCP**：送信元IP、送信元ポート、宛先IP、宛先ポートすべてを使用してソケットを識別する（4タプル）。送信元が異なるセグメントは異なるソケットに配信される。

**計算原理**：セグメントのすべての16ビットワードを加算した後、1の補数を取る。受信側でチェックサムを含むすべてのワードを加算した結果がすべて1であればエラーなしと判断する。

**限界**：2ビットが同時に相補的にエラーが発生した場合（1ビットは0から1へ、もう1ビットは1から0へ）検出できない可能性がある。またエラーを検出しても訂正（correction）は不可である。

DNS問い合わせはほとんどが1つのリクエストと1つの応答で構成される短いトランザクションである。TCPの3ウェイハンドシェイク接続設定は実際のデータより多くのオーバーヘッドを発生させる。UDPを使用すれば接続設定なしですぐに問い合わせを送り応答を受け取れるため、**遅延が大幅に減少する**。応答がなければアプリケーションが再送すればよい。