導入
「データが相手に届く」までには、実は複数の役割がバケツリレーのように連携しています。これを整理したのが TCP/IP の階層モデル です。全部を暗記する必要はありませんが、「どの層で何をしているか」の地図があると、トラブル調査（ping は届く？ curl は返る？）の切り分けが上達します。
説明
通信は、役割ごとに 4つの層 に分かれています。上（アプリに近い）から下（ケーブルに近い）へ、こう積み重なっています。
flowchart TD
L4["アプリケーション層<br/>HTTP / SSH / DNS<br/>『何を』やりとりするか"]
L3["トランスポート層<br/>TCP / UDP・ポート番号<br/>『どの窓口へ・確実に or 速く』"]
L2["インターネット層<br/>IP・IPアドレス<br/>『どの住所へ届けるか』"]
L1["ネットワーク層<br/>Ethernet / Wi-Fi<br/>『実際のケーブル・電波』"]
L4 --> L3 --> L2 --> L1
手紙にたとえると分かりやすいです。
- アプリケーション層 … 手紙の本文（用件そのもの）。HTTP なら「このページをください」。
- トランスポート層 … 封筒と宛先の部屋番号（ポート）。TCP なら「ちゃんと届いたか確認しながら送る」。
- インターネット層 … 住所（IPアドレス） を頼りに、中継地点をたどって運ぶ。
- ネットワーク層 … 実際の道路・配達手段（LANケーブルや Wi-Fi）。
送るときは上から下へ順番に「封筒に入れて」いき、受け取る側は下から上へ「開けて」いきます。
flowchart LR
subgraph 送信側
S4["本文(HTTP)"] --> S3["封筒(TCP/ポート)"] --> S2["住所(IP)"] --> S1["発送"]
end
S1 -->|ネットワーク| R1
subgraph 受信側
R1["受取"] --> R2["住所を確認(IP)"] --> R3["封筒を開ける(TCP)"] --> R4["本文を読む(HTTP)"]
end
この地図があると、トラブル調査の順番が見えてきます。
pingが返らない → インターネット層（IP） より下で切れている（住所に届いていない）pingは返るがcurlが返らない → IP は届くが、アプリ層（HTTP）やポートの問題- つまり「下の層から順に確かめる」のが切り分けのコツ
実務では「4層モデル」または、より細かい「7層の OSI 参照モデル」という言葉も出てきます。細部より、「通信は役割ごとの層が積み重なってできている」「下の層（届く）→上の層（中身）へと順に切り分ける」という考え方をつかんでおけば十分です。次のレッスンから、各層を確かめるコマンド（
ip・ping・dig・curl・ss）を実際に打っていきます。
この章のまとめ
- 通信は役割ごとに 4つの層（アプリ／トランスポート／インターネット／ネットワーク）に分かれる
- 各層は「本文・封筒とポート・住所・配達手段」と手紙にたとえられる
- トラブルは 下の層（届くか）から順に切り分けると原因を絞りやすい
- 次から、各層を確かめるコマンドを手で打って確認する