レイヤモデル（OSI / TCP-IP）

ネットワークは「層を重ねた抽象化」で動いている。下層が上層に「パケットを届ける」サービスを提供する形で責務が分かれる。 OSI 参照モデル（理論）と TCP/IP モデル（実装）の対応を一通り。

なぜレイヤ化するのか

• 関心の分離: HTTP を書くときに電気信号を考えなくていい
• 差し替え可能: Ethernet を Wi-Fi に変えても上は何も変わらない
• 標準化しやすい: 各層ごとに別組織が仕様を作っても繋がる
• トラブル切り分け: どの層で詰まっているかを順に見ていける

OSI 参照モデル（7 層）

「OSI は 7 層」と覚えるのは試験用。実装は次の TCP/IP モデルで進む。

TCP/IP モデル（4 層 / 5 層）

実装側で広く使われる現代的なモデル。

カプセル化（encapsulation）

上から下へ降りるたびに、各層がヘッダを前に追加する。最後の物理層まで来ると元のデータは何重もの「封筒」に包まれている。

[アプリ]      "GET /index.html HTTP/1.1\r\n..."
[TCP]         [TCP ヘッダ | アプリのデータ]
[IP]          [IP ヘッダ | TCP セグメント]
[Ethernet]    [Ether ヘッダ | IP パケット | FCS]
[物理]        ── 電気信号 ──>
      

受信側では下から上へ昇りながらヘッダを 1 枚ずつ剥がす（デカプセル化）。

各層で扱う単位の名前

各層のアドレス

• アプリ層: URL / ドメイン名（人が読む）
• トランスポート層: ポート番号（プロセス識別）
• ネットワーク層: IP アドレス（ホスト識別、グローバル）
• データリンク層: MAC アドレス（NIC 識別、ローカル）

具体例: ブラウザで http://example.com を開く

1. アプリ: HTTP リクエスト「GET / HTTP/1.1」を作る
2. アプリ: example.com を DNS 解決 → 93.184.216.34
3. トランスポート: 送信ポートをランダム割り当て、宛先ポート 80。3-way handshake で TCP 接続
4. ネットワーク: 自 IP / 宛先 IP をヘッダに付ける。ルーティングテーブル参照
5. データリンク: デフォルトゲートウェイの MAC を ARP で解決し、Ethernet フレームに包む
6. 物理: NIC が電気/電波で送出
7. 各ルーターを通り、目的サーバ NIC に届く
8. 受信側で逆方向に剥がしていき、HTTP プロセスがリクエストを受け取る

L4 と L7 の境目

ネットワーク機器の話で「L4 ロードバランサ」「L7 ロードバランサ」とよく出てくる:

• L4 LB: TCP/UDP の段階で振り分け（高速・中身を見ない）
• L7 LB: HTTP ヘッダや URL を見て振り分け（高機能・TLS 終端）

どの層で詰まっているかを切り分ける

トラブル時は下から上へ順に確認するのが定石。

1. L1: ケーブル / 電源 / リンクランプ
2. L2: arp -a で隣接ノードの MAC が見えるか
3. L3: ping で IP 疎通、traceroute で経路
4. L4: nc -zv host port でポート疎通
5. L7: curl -v で HTTP 応答

詳しい使い方は 解析ツール へ。

標準化団体

• IETF (Internet Engineering Task Force) — RFC を作る。HTTP / TCP / IP / DNS など
• W3C — Web 標準（HTML / CSS / Web API）
• WHATWG — HTML Living Standard、Fetch、URL
• IEEE — Ethernet (802.3) / Wi-Fi (802.11) など物理層〜L2
• IANA / ICANN — IP アドレス / ドメイン名の管理

RFC とは

Request For Comments — IETF が発行する仕様書。HTTP/1.1 は RFC 9110 / 9111 / 9112、 HTTP/2 は RFC 9113、HTTP/3 は RFC 9114、TCP は RFC 9293（最新）など。 困ったら原典である RFC を読むのが最終手段。