層に分ける、という考え方を図にした。OSIの7層と、実際の4層

• 層に分けると、下を知らなくても上が書ける
• OSIは7層の参照モデル。実際の仕様は4層で書かれている
• 通信の切り分けは下から順にという形になる

HTTPもDNSもSSHも、同じ考え方の上に乗っている。その考え方を図にした。

7層と4層

インターネットの基本的な仕様を定めたRFC 1122は、4つの層で構成を説明している。

• アプリケーション層 … 利用者向けのプロトコルが直接サービスを提供する
• トランスポート層 … 端から端までの通信サービスを提供する。TCPとUDP
• インターネット層 … ホスト間でデータを転送する。IPなど
• リンク層 … 直接つながっている網で通信する

OSIとの対応も書かれている

同じ文書に、OSI参照モデルとの関係が明記されている。

• アプリケーション層は、OSIの表現層と応用層をまとめた形になっている
• インターネット層は、OSIのコネクションレスなネットワーク層にあたる

つまり7層は考え方の整理、4層は実際の作りという関係になる。どちらが正しいという話ではない。

層に分けて何が嬉しいのか

いちばん大きいのは下を知らなくても上が書けることだ。

ウェブページを作るときに、電波の変調方式を知っている必要はない。有線か無線かも気にしなくてよい。隣の層とだけ約束を交わしておけば、その先は任せられる。

• 片方だけ差し替えられる — 有線から無線に変えても、上は書き直さない
• 分業できる — 層ごとに別の人が作れる
• 切り分けの順番が決まる

切り分けが「下から順に」になる理由

上の層は下の層が動いていることを前提にしている。だから下が壊れていれば上は必ず動かない。逆は成り立たない。

この性質から、調べる順番が決まる。

1. 線はつながっているか（リンク層）
2. 相手の機械まで届くか（インターネット層）
3. 相手の口は開いているか（トランスポート層）
4. やり取りの中身は正しいか（アプリケーション層）

「サイトが見えない」とき、いきなり4番を調べると遠回りになる。1番から順に消していくと、どこで止まっているかが必ず分かる。

この考え方は通信に限らない。不具合を切り分ける順番そのものは不具合を直す順番を決めたら、原因に辿り着くのが速くなったに書いた。

困るところ

• どの層で詰まっているか分かりにくい — 上から見ると「繋がらない」としか見えない
• 無駄が出る — 層ごとに情報が付くので、運ぶ量が増える
• 層をまたぐ不具合は追いにくい — どちらの責任か決めにくい

3つ目が実務でいちばん厄介になる。たとえば暗号化された通信が途中で平文に戻されているような構成では、上の層から見ると辻褄が合わない現象が出る。

包んで渡す、という形

層を越えるとき、データはそのまま渡されるのではなく、その層の情報を付けて包まれる。下へ行くほど包みが増え、受け取った側は上へ行くほど包みが外れる。

だから各層は、自分の包みだけ見ればよい。中身が何かを知る必要がない。これが「下を知らなくても上が書ける」を成り立たせている仕組みになる。

代償もここから来る。包みのぶんだけ、運ぶ量が増える。小さなデータを大量に送る用途では、中身より包みのほうが大きくなることもある。

層の言葉で話すと通じる

障害の連絡をするとき、層の言葉を使うと伝わりやすい。

• 「繋がらない」→ どこまでは届いているのかを添える
• 「遅い」→ どの段階で待っているのかを添える

相手が調べる範囲が一気に狭まる。層は、分担の線でもある。

まとめ

• 層に分けると、下を知らなくても上が書ける
• OSIは7層の参照モデル。実際の仕様は4層で書かれている
• 仕様には、アプリケーション層がOSIの表現層と応用層をまとめた形と明記されている
• 切り分けは下から順に。下が壊れていれば上は必ず動かない
• 困るのは、層をまたぐ不具合と、どの層か分かりにくいこと

出典

• RFC 1122「Requirements for Internet Hosts」（4層の構成と各層の役割、OSI参照モデルとの対応）

図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。