ネットワークプロトコルスタックの階層と封入

カプセル化は「逆順に剥がせる」ことが本質

カプセル化（encapsulation）とは、ある層のPDU（Protocol Data Unit）全体を、すぐ下の層が自分のヘッダで包み、下層から見れば中身を解釈しない不透明なデータ（ペイロード）として扱う操作です。送信側はアプリのデータに L4 → L3 → L2 の順でヘッダを前置していき、受信側はワイヤから届いたバイト列を L2 → L3 → L4 の順で1枚ずつ剥がします。この対称性が成立する条件は、各層のヘッダが 「自分のペイロードがどの上位プロトコルか」を明示している ことです。これが無ければ受信側は次にどのヘッダ解析器へ渡すかを決められません。層の全体像は /network/osi/ と /network/tcp-ip/ を前提とします。

層を下るごとに付く封筒

HTTPリクエストを例に、上から下へPDUがどう成長するかを追います。

ここで重要なのは、各層が付けるのは「ヘッダ（前置）」が基本で、L2 だけはフレーム末尾にも FCS（4バイトのCRC-32） という後置（トレーラ）を付ける点です。つまり最終的なワイヤ上のバイト列は、ヘッダが外側から内側へ入れ子になり、末尾にL2のトレーラが付く構造になります。

[Ethernetヘッダ 14B][IPv4ヘッダ 20B][TCPヘッダ 20B][アプリデータ][FCS 4B]
└── L2 ──┘└──────── L2 ペイロード ────────┘└ L2 ──┘
          └── L3 ─┘└──── L3 ペイロード ────┘
                    └ L4 ┘└─ L4 ペイロード ┘

L2 から見れば、IPヘッダ以降すべてが「ただのペイロード」です。L2 は中身がIPかARPかを EtherType で区別するだけで、IPの構造そのものは一切解釈しません。これが関心の分離の実体です。

実バイト列：3つのヘッダを並べて読む

代表的な IPv4 + TCP の最小構成（オプション無し）を、先頭からのバイトオフセットで追います。ここを正確に押さえると、パケットキャプチャの16進ダンプが読めます。手を動かす手順は /network/packet-capture/ を参照してください。

Ethernet II ヘッダ（先頭14バイト）

offset 0  : 宛先MAC      6B  (次ホップのMAC)
offset 6  : 送信元MAC    6B
offset 12 : EtherType    2B  (0x0800=IPv4, 0x0806=ARP, 0x86DD=IPv6)

EtherType が 0x0800 なら、受信側はオフセット14から先をIPv4解析器に渡します。MACは1ホップごとに書き換わる一方、IP以降は変わりません。この対比は /network/arp/ のIP↔MAC解決と合わせると腑に落ちます。

IPv4 ヘッダ（オフセット14から20バイト）

Protocol フィールドが、L3 が次にどのL4解析器へ渡すかを決めます。6 ならTCP、17 ならUDPです。IHL（Internet Header Length）が4バイト単位なので、オプション無しの最小ヘッダは IHL=5、すなわち 20バイト。ここを足し込んでオフセット34からがTCPヘッダになります。

TCP ヘッダ（オフセット34から20バイト）

offset 34 : 送信元ポート   2B
offset 36 : 宛先ポート     2B   (この値でL7アプリを特定)
offset 38 : シーケンス番号 4B
offset 42 : ACK番号        4B
offset 46 : Data Offset+予約+フラグ 2B (上位4bitがヘッダ長/4バイト単位)
offset 48 : ウィンドウサイズ 2B
offset 50 : チェックサム   2B
offset 52 : 緊急ポインタ   2B
offset 54 : (オプション無しならここからアプリデータ)

宛先ポート がL4からL7への分岐キーです。443 ならTLS/HTTPS、53 ならDNSへ渡す、という対応はポートとソケットの仕組み（/network/socket-port/）が前提になります。Data Offset が 5（=20バイト）ならオプション無しで、オフセット54からアプリ層のデータが始まります。

オーバーヘッドとMTUの会計

カプセル化はヘッダの分だけ実効ペイロードを削ります。Ethernet の MTU 1500バイトを基準に、IPv4(20) + TCP(20) を引くと、TCPが1セグメントで運べるアプリデータは最大 1460バイト。これが標準的な MSS（Maximum Segment Size） です。

VPNやトンネルではここに外側のヘッダが追加で被さるため、内側のMSSをさらに下げないと分割や無言の詰まりが起きます。MTU/MSSの会計と落とし穴は /network/mtu/ で深掘りできます。

つまずきポイント

• ヘッダは前置、トレーラはL2だけ：IPやTCPは前にヘッダを付けるだけで末尾には何も足しません。誤り検出の後置（FCS）はL2フレームに固有です。
• 「パケット」を全層で使う誤用：厳密にはL3のPDUがパケット。L4はセグメント/データグラム、L2はフレーム。トラブル報告で層がぶれる原因になります。
• ヘッダ長が固定だと思い込む：IPv4の IHL もTCPの Data Offset も可変です。オプション付きならオフセット計算が20バイト超になり、固定で読むとペイロード先頭を取り違えます。
• 次層識別フィールドの見落とし：EtherType・Protocol・宛先ポート の連鎖を辿らずにオフセットだけで読むと、IPv6やVLANタグ（0x8100）が挟まった瞬間に解析がずれます。