Network Systems Foundations: Transport Layer
本記事は、Coursera の Network Systems Foundations モジュール「Transport Layer」で学んだ内容を個人の学習記録としてまとめたものです。
トランスポート層の概要
トランスポート層は、ホスト間通信を担うネットワーク層の上に位置し、プロセス間通信を実現する層です。
| 層 | 目的 | 代表的プロトコル |
|---|---|---|
| リンク層 | ネットワーク内通信 | Ethernet |
| ネットワーク層 | ホスト間通信 | IP |
| トランスポート層 | プロセス間通信 | TCP / UDP |
1️⃣ Multiplexing（多重化）
■ 問題設定
複数のアプリケーションが同時に通信を行う場合、
「どのアプリケーション宛のパケットか？」を識別する必要があります。
→ これを識別するのが ポート番号 (Port Number) です。
■ トランスポートアドレス (ポート)
- 各アプリケーションはポート番号で識別される
- HTTP → ポート 80
- SSH → ポート 22
IPヘッダ
├─ Source IP
├─ Destination IP
TCPヘッダ
├─ Source Port
├─ Destination Port
この 4 つ（Src IP, Dest IP, Src Port, Dest Port）の組が
1 つの通信（コネクション）を一意に識別します。
■ UDP と TCP の違い
| プロトコル | 特徴 | 用途 |
|---|---|---|
| UDP | コネクションレス・シンプル・再送なし | DNS, ストリーミング |
| TCP | コネクション指向・信頼性あり | Web 通信 |
■ 各層でのメッセージ名
| 層 | 名称 |
|---|---|
| リンク層 | Frame |
| ネットワーク層 | Packet |
| トランスポート層 | Datagram |
| アプリケーション層 | Message |
2️⃣ Reliable Transfer（信頼できる転送）
■ 目的
アプリケーションが送信したデータが「欠損なく・順序通りに届く」ことを保証する。
送信側 → Pkt1: ABC, Pkt2: DEF, Pkt3: GHI
受信側 → Pkt1: ABC, Pkt2: DEF, Pkt3: GHI ✅
■ 伝送中に発生しうる問題
| 問題 | 原因 | 対応 |
|---|---|---|
| フレーム誤り | 電磁ノイズ等でビット反転 | CRC で検出、破棄 |
| 輻輳によるドロップ | ルータバッファ溢れ | 再送制御 |
| パケット順序の乱れ | 経路変更など | シーケンス番号で順序復元 |
■ TCP の仕組み
1. シーケンス番号 (Sequence Number)
ストリーム中の「どのバイトからどの範囲か」を表す。
例：
Seq=0〜99, Seq=100〜199, Seq=200〜299
2. ACK 番号 (Acknowledgement Number)
受信側が「次に期待するバイト番号」を返す。
ACK=200 → 0〜199までは受信済み
3. 再送制御
ACK が一定時間内に返らない、または重複 ACK を受け取った場合に再送。
4. フロー制御 (Flow Control)
受信側は自分のバッファ残容量を rwnd として広告し、送信側は「未 ACK データ ≤ rwnd」を維持。
■ TCP ヘッダ内の主な制御フィールド
| フィールド | 意味 |
|---|---|
| Sequence Number | データの順序 |
| ACK Number | 次に期待するデータ |
| Window Size | 受信可能なバイト数（rwnd） |
| Flags | SYN, ACK, FIN など |
3️⃣ TCP Connection Establishment（コネクション確立）
■ 三者間ハンドシェイク（3-Way Handshake）
| ステップ | 内容 | TCP フラグ |
|---|---|---|
| ① | クライアント → サーバ: 接続要求 | SYN |
| ② | サーバ → クライアント: 受諾＋自身の SYN | SYN + ACK |
| ③ | クライアント → サーバ: 確認応答 | ACK |
A → B : SYN(seq=1000)
B → A : SYN(seq=600), ACK(ack=1001)
A → B : ACK(ack=601)
■ 再送ケース
どのパケットが欠損しても再送が発生し、通信確立が保証される。
4️⃣ Congestion Control（輻輳制御）
■ 問題設定
ネットワークの帯域が飽和するとルータのバッファが溢れ、
パケット損失と再送が増加 → 輻輳崩壊 (congestion collapse) が発生。
■ 目的
- ネットワークを「崩壊直前の効率的な状態」で安定動作させる
- 各送信元が公平 (fair) かつ効率的 (efficient) に帯域を利用
■ TCP の戦略: Detect & Adjust
- フィードバック: 暗黙的（Timeout, Duplicate ACK, Delay など）
-
調整: ウィンドウベース (cwnd)
lastByteSent – lastByteAck ≤ cwnd
■ AIMD（Additive Increase, Multiplicative Decrease）
| フェーズ | 内容 |
|---|---|
| AI | 輻輳がない間、RTT ごとに cwnd を 1 MSS ずつ増加 |
| MD | 輻輳検知時に cwnd を 乗算的に（例えば半分に） に減少 |
→ グラフ上では「鋸歯状（sawtooth pattern）」の増減を描く。
■ Slow Start（スロースタート）
AIMD の「加法増加」は遅すぎるため、接続開始時は 指数的に cwnd を増加。
| 段階 | cwnd の変化 |
|---|---|
| 初期 | 1 MSS |
| 1 RTT 後 | 2 MSS |
| 2 RTT 後 | 4 MSS |
| 3 RTT 後 | 8 MSS |
→ 一定値（閾値）に達すると Additive Increase に切り替え。
🧠 まとめ
| 機能 | キー概念 | 役割 |
|---|---|---|
| Multiplexing | Port 番号 | アプリ間の識別 |
| Reliable Transfer | Seq / ACK / 再送 / Flow Control | 順序と完全性の保証 |
| Connection | 3-Way Handshake | 通信前の同意形成 |
| Congestion Control | AIMD / cwnd / Slow Start | ネットワーク効率と公平性 |
🧾 参考資料
- Coursera:Network Systems Foundations