タイトル: データの単位 PDU(プロトコルデータユニット)
SEOタイトル: PDU (Protocol Data Unit) 完全ガイド — OSI 各層の単位
| この記事の要点 |
|
PDU とは
PDU (Protocol Data Unit) は、OSI 参照モデルにおいて「各層で扱うデータの 1 単位」を表す抽象的な総称です。各層に独自の名前があり、データはネットワーク上で層を移動するたびに「皮を着る」「皮を脱ぐ」を繰り返します。
| 層 | 名称 | PDU 呼称 | 主なヘッダ情報 |
|---|---|---|---|
| 7 | アプリケーション層 | データ (Data) / メッセージ | アプリ固有 (HTTP リクエスト等) |
| 6 | プレゼンテーション層 | データ | 暗号化 / 圧縮 メタ |
| 5 | セッション層 | データ | セッション ID |
| 4 | トランスポート層 | セグメント (TCP) / データグラム (UDP) | 送信元ポート / 宛先ポート / シーケンス番号 |
| 3 | ネットワーク層 | パケット (Packet) ※IPv4 では Datagram とも | 送信元 IP / 宛先 IP / TTL |
| 2 | データリンク層 | フレーム (Frame) | 送信元 MAC / 宛先 MAC / FCS |
| 1 | 物理層 | ビット (Bit) / シンボル | — |
カプセル化と非カプセル化
データが送信側で下の層へ降りるときに各層がヘッダ (一部はトレーラ) を付与し、受信側で上の層へ上るときに各層が自分のヘッダを剥がします。これが OSI 参照モデルの中核概念です。
送信側 (上から下へ) 受信側 (下から上へ)
───────────────── ─────────────────
アプリ層: HTTP リクエスト アプリ層: HTTP リクエスト
↓ ↑
L4: + TCP ヘッダ → セグメント L4: TCP ヘッダ剥がす
↓ ↑
L3: + IP ヘッダ → パケット L3: IP ヘッダ剥がす
↓ ↑
L2: + Ether ヘッダ → フレーム L2: Ether ヘッダ剥がす
↓ ↑
L1: ビット列 L1: ビット列受信
カプセル化: 各層で自分のヘッダを「皮」のように追加
上位の PDU は下位から見ると "ペイロード"SDU と PDU の関係
SDU (Service Data Unit) は「上位層が下位層に渡したデータ本体」のこと。下位層では SDU にヘッダを付けて自層の PDU になります。つまり:
上位層の PDU == 下位層の SDU
例: TCP セグメント (L4 PDU) は IP 層から見ると SDU
IP は SDU に IP ヘッダを付けて IP パケット (L3 PDU) を作る
PDU = ヘッダ + SDUイーサネットフレームの構造
| フィールド | サイズ | 説明 |
|---|---|---|
| プリアンブル + SFD | 8B | 同期信号 |
| 宛先 MAC | 6B | 受信先 MAC アドレス |
| 送信元 MAC | 6B | 送信元 MAC アドレス |
| タイプ (or 長さ) | 2B | 0x0800=IPv4, 0x86DD=IPv6, 0x0806=ARP |
| ペイロード | 46-1500B | IP パケット等 |
| FCS | 4B | 誤り検出 (CRC32) |
ペイロードの上限が MTU = 1500 バイト（標準 Ethernet）。これを超える IP パケットはフラグメンテーションされます。
MTU と MSS
| 用語 | 値の例 | 意味 |
|---|---|---|
| MTU (Maximum Transmission Unit) | 1500B (Ethernet) | L2 で送れるペイロード最大長 |
| MSS (Maximum Segment Size) | 1460B | TCP のペイロード最大長 = MTU - IP(20) - TCP(20) |
| Jumbo Frame | 9000B | データセンタ用の大型 MTU |
| PPPoE | 1492B | PPPoE ヘッダ 8B 分小さい |
| IPSec VPN | 1400B 前後 | 暗号化オーバーヘッド分 |
フラグメンテーション
送信したい IP パケットが経路上の MTU を超える場合:
- IPv4 では送信元 or 経路上のルーターが分割 (fragment)、終端で再構築 (reassemble)
- IPv6 では経路途中での分割は行わない。送信元のみが分割可能
- DF (Don't Fragment) ビットが立った IP パケットは分割できず、超えると ICMP "Fragmentation Needed" が返る
- これを利用して経路 MTU を自動検出するのが PMTUD (Path MTU Discovery)
PMTUD: 経路 MTU を調べる
# Linux: DF つき ping で MTU 探索
ping -M do -s 1472 8.8.8.8 # 1472 + IP(20) + ICMP(8) = 1500
# 通れば MTU >= 1500
# Frag needed が返れば縮める
# Windows
ping -f -l 1472 8.8.8.8
# tracepath で自動探索 (Linux)
tracepath 8.8.8.8
# インターフェースの MTU 確認
ip link show eth0 # Linux
ifconfig en0 | grep mtu # macOS
netsh interface ipv4 show subinterfaces # WindowsTCP セグメントの構造
| フィールド | サイズ | 説明 |
|---|---|---|
| 送信元ポート / 宛先ポート | 各 2B | アプリケーション識別 |
| シーケンス番号 | 4B | 順序制御 |
| 確認応答番号 | 4B | ACK の対象バイト |
| データオフセット | 4bit | ヘッダ長 |
| フラグ | 6bit | SYN / ACK / FIN / RST / PSH / URG |
| ウィンドウサイズ | 2B | 受信可能バイト数 (フロー制御) |
| チェックサム | 2B | 誤り検出 |
| オプション | 可変 | MSS, SACK, タイムスタンプ等 |
| データ | 可変 | ペイロード |
UDP データグラムの構造
UDP は極めてシンプル: 8B のヘッダのみ。
| フィールド | サイズ |
|---|---|
| 送信元ポート | 2B |
| 宛先ポート | 2B |
| 長さ | 2B |
| チェックサム | 2B |
| データ | 可変 |
パケットキャプチャでの観察
# tcpdump で実際の PDU を見る
sudo tcpdump -i eth0 -nn -X port 80
# Wireshark フィルタ例
ip.addr == 192.168.1.1 # 特定 IP
tcp.port == 443 # 特定ポート
eth.src == aa:bb:cc:dd:ee:ff # 送信元 MAC
http.request # HTTP リクエストだけ
# Wireshark 上で 1 パケットを開くと
# 物理層 → イーサネット → IP → TCP → HTTP の各層が階層展開される
# これがまさに PDU の入れ子構造の可視化FAQ
Q: パケットとフレームの違いは？
A: パケットは L3 (IP) の単位、フレームは L2 (Ethernet) の単位。日常会話では「パケット」が広い意味でも使われるが、厳密には別。
Q: MTU を 9000 (Jumbo) にすると速くなる？
A: データセンタ内の高速ストレージ通信などでは有効。ただし経路上の全機器が Jumbo 対応である必要があり、家庭やインターネット越えでは事故の元。
Q: フラグメンテーションは悪？
A: パフォーマンス低下と再構築失敗リスクがあるので避けるのが定石。PMTUD で適切な MSS にするのが正解。VPN で MTU 不一致だと「Web は見えるがファイルダウンロードで止まる」典型症状。