OSI参照モデル

なぜ層に分けるのか

通信は「電気信号を流す」から「Webページを表示する」まで、性質のまったく違う仕事の積み重ねです。これを1つの塊で考えると手に負えません。役割ごとに層へ切り分けると、

• 関心の分離：各層は すぐ下の層 だけを頼り、すぐ上の層 にサービスを提供する。中身は隠す（カプセル化）
• 差し替えがきく：Wi-Fi から有線に変えても（L1/L2 が変わるだけ）、上の HTTP（L7）はそのまま動く
• 共通言語になる：「これは L3 の問題（ルーティング）」「L7 の問題（アプリ設定）」と切り分けが速くなる

7つの層

下（物理）から上（アプリ）へ、各層が何をして、現場で何が出てくるかをまとめます。番号は 下が L1、上が L7 です。

順番を覚えるなら、上から App / Presentation / Session / Transport / Network / Data link / Physical の頭文字で。日本語では「アプ・プレ・セ・トラ・ネット・デー・物理」と唱える人も多いです。

下位3層（L1〜L3）— データを“運ぶ”側

• L1 物理層：0/1の信号を物理媒体に乗せるだけ。ケーブル規格やピン配置、電圧の世界
• L2 データリンク層：MACアドレス を使い、同じネットワーク（同一セグメント）内 の相手にフレームを届ける。担当機器は スイッチ
• L3 ネットワーク層：IPアドレス で ネットワークをまたいで 相手まで運ぶ。経路を選ぶのが ルータ の仕事

上位4層（L4〜L7）— データを“使う”側

• L4 トランスポート層：ポート番号 でアプリを区別し、TCP（順序保証・再送あり）か UDP（速いが無保証）かを選ぶ
• L5 セッション層：通信の論理的な区切り（開始〜終了）の管理
• L6 プレゼンテーション層：文字コード変換・圧縮・暗号化（TLS） など“表現”の調整
• L7 アプリケーション層：HTTP や DNS など、アプリが直接話すプロトコル

TCP/IP 4層モデルとの対応

インターネットを実際に動かしているのは、OSIではなく TCP/IP（4層）モデル です。OSIの細かい上位3層をまとめ、下位2層もざっくり1つにしたものと考えると対応が取れます。

カプセル化：層を下りるたび“封筒”が増える

送信側ではデータが上の層から下の層へ渡されるたび、各層が自分のヘッダ（宛先情報など）を付け足します。これが カプセル化 です。受信側は逆に、下から上へ封筒を1枚ずつ開けていきます（非カプセル化）。

• L4 で TCP/UDP ヘッダ（ポート番号）→ セグメント
• L3 で IP ヘッダ（IPアドレス）→ パケット
• L2 で Ethernet ヘッダ（MACアドレス）→ フレーム

つまり「データ → セグメント → パケット → フレーム」と、層を下るごとに呼び名と封筒が増えていきます。

つまずきポイント

• 層番号と方向の混同：番号が小さい L1が物理（下）、大きい L7がアプリ（上）。「7が一番下」ではない
• L2とL3の役割の取り違え：スイッチ＝L2（MAC）、ルータ＝L3（IP）。最近のL3スイッチは両方やるため曖昧になりがち
• OSIを“実装仕様”だと思い込む：OSIは 整理の物差し。実際のプロトコルが層をまたぐのは普通のこと
• L4とL7のロードバランサ混同：ポートで振り分けるのが L4 LB、URLやヘッダの中身で振り分けるのが L7 LB（/network/proxy-lb/ 参照）

ハンズオン

各層を“見る”コマンドで、机上の知識を手元で確かめてみましょう。

# L2: ARPテーブル（IP↔MAC の対応）を見る
arp -a

# L3: 宛先までの経路（ルータ＝L3機器を1ホップずつ）を辿る
traceroute example.com      # Windows は tracert example.com

# L3: ICMP で到達性を確認（L3が生きているか）
ping example.com

# L4: いま開いている TCP/UDP ポート（L4の“窓口”）を一覧
ss -tunlp                   # 旧来は netstat -tunlp

# L7: HTTP のやり取り（アプリ層の中身）を確認
curl -v https://example.com

ping（L3）→ ポート確認（L4）→ curl（L7）と 下の層から順に 切り分ければ、どの層で止まっているかが自然に見えてきます。