OSI参照モデルとは｜7層の早見表とTCP/IP対応・パケット実例

送るデータは、上の層から順に「宛名のヘッダー」を前に足されて、最後に信号として流れます。数字は、実際に取った HTTP リクエスト1つの大きさです。

flowchart TD
    A[L7 HTTPのデータ<br>78バイト] --> B[L4 TCPヘッダー32バイトを足す<br>セグメント]
    B --> C[L3 IPヘッダー20バイトを足す<br>パケット]
    C --> D[L2 Ethernetヘッダー14バイトを足す<br>フレーム 144バイト]
    D --> E[L1 電気・光・電波の信号<br>ビット]

7つの層は、上から次のとおりです。

確認環境：Ubuntu 24.04.4・tcpdump 4.99.4（libpcap 1.10.4）・curl 8.5.0・Python 3.11.15・OpenSSL 3.0.13・iproute2（ip・ss）。Linux の network namespace（隔離したネットワーク）2つを仮想の LAN ケーブル（veth）でつなぎ、Python の HTTP サーバーへ curl で1回アクセスした通信を tcpdump で取り、ヘッダーを1バイトずつ読み解いています。障害は同じ環境でわざと起こし、ping・ip・ss・nc・curl の出力を載せています。規格は ISO・ITU-T の公式ページ、TCP/IP の層は RFC 1122、Windows のコマンドは Microsoft Learn で確かめました（確認日 2026年10月17日）。

OSI参照モデルとは

OSI参照モデル（OSI Reference Model）は、コンピューター同士の通信に必要な働きを7つの層に分けて整理した、国際標準の枠組みです。 OSI は Open Systems Interconnection（開放型システム間相互接続）の略です。メーカーが違う機器同士でも通信できるように、ISO（国際標準化機構）と CCITT（いまの ITU-T、国際電気通信連合の標準化部門）が検討し、同じ内容を両方の規格にしています。

「OSI基本参照モデル」との違い

OSI参照モデルと OSI基本参照モデルは同じものです。 規格の英語名が「Basic Reference Model」なので、訳すと「基本参照モデル」になります。情報処理技術者試験の教科書などでは「OSI基本参照モデル」と書かれることが多く、ふだんは「OSI参照モデル」「OSIモデル」「OSI 7層モデル」と呼ばれます。

実装の手順書ではなく「考え方の地図」

ISO の規格ページには、このモデルは実装の仕様として使うものではない、と書かれています。実際のインターネットで動いているのは、次の節の TCP/IP です。それでも OSI参照モデルが今も使われるのは、「どの層の話か」を短く伝える共通語として便利だからです。「L2スイッチ」「L3スイッチ」「L4ロードバランサー」「L7の攻撃」の L と数字は、この7層の番号です。

OSI参照モデルの7層の早見表

各層が受け持つことと、そこで使われる代表的なプロトコル（通信の約束ごと）・機器・データの単位です。

表を読むときの注意点です。

• TLS（HTTPS の暗号化）は、どの層かで説明が分かれます。 暗号化は L6、セッションの管理は L5 の働きに近く、TCP/IP モデルではアプリケーション層の一部として扱われます。
• ARP（IPアドレスからMACアドレスを調べる仕組み）は L2 と L3 のあいだで働きます。この記事では L2 の欄に入れています。
• L2 は、IEEE 802 の規格で LLC（論理リンク制御）と MAC（媒体アクセス制御）の2つの副層に分けられています。 OSI参照モデルができた当時は、Ethernet のような LAN が広まる前でした。
• 機器は「その層まで中身を見て判断する」という意味です。L3 のルーターは、L1・L2 の働きも持っています。

送信元・宛先を表す番号は、層ごとに違う

層ごとに「誰に届けるか」を表す番号が違います。障害の切り分けでも、この3つを分けて見ます。

関連記事「ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表」で扱っています。

OSI参照モデルの覚え方

7層の名前と順番は、語呂合わせで覚えるのが近道です。番号と「宛先を表すもの」を結びつけると、仕事で使える知識になります。

TCP/IPモデルとの違いと対応表

実際のインターネットで使われているのは TCP/IP モデル（インターネットプロトコルスイート）です。 RFC 1122 は、TCP/IP を4つの層（アプリケーション・トランスポート・インターネット・リンク）で説明しています。OSI参照モデルの7層とは、次のように対応します。

違いをまとめると次のとおりです。

RFC 1122 には、TCP/IP のアプリケーション層は、OSI のプレゼンテーション層とアプリケーション層の働きをまとめたものと書かれています。HTTP のようなアプリのプロトコルが、文字コードや圧縮（L6 の働き）も自分で決めているのはこのためです。

カプセル化とは：送るときにヘッダーが重なる流れ

カプセル化は、上の層のデータの前に、下の層が自分のヘッダー（宛名や制御情報）を足していく仕組みです。 受け取る側は逆に、下の層から順にヘッダーを外していきます（非カプセル化）。

途中のルーターは L3 まで外して IPアドレスを見て、次の隣へ渡すために L2 のヘッダーを付け替えます。 IPアドレスは最後まで同じで、MACアドレスは区間ごとに変わります。

1回のHTTP通信をtcpdumpで分解する

ここからは、実際に取った通信で各層のヘッダーを見ます。2つのネットワーク空間を仮想の LAN ケーブルでつなぎ、10.58.0.1（クライアント）から 10.58.0.2:25880（Python の HTTP サーバー）へ curl で1回アクセスしました。

取り方のコマンド

# 1つ目の端末：通信を取る（-w でファイルに保存）
sudo tcpdump -i s258c0 -w http.pcap
# 2つ目の端末：HTTPで1回アクセスする
curl -s http://10.58.0.2:25880/
# 取ったファイルを、MACアドレス付き（-e）で表示する
tcpdump -r http.pcap -n -e

手元の PC で試すときは、-i にふだん使っているインターフェース名（ip -br link で見られます）を、-w の前に 'host 宛先 and tcp port 80' のような条件を付けます。-i lo（ループバック）で取ると、MACアドレスはすべて 00:00:00:00:00:00 と表示されました。

1回のアクセスで流れた15個のフレーム

curl 1回で、15個のフレームが流れました。左から、送信元MAC > 宛先MAC、L2 の種類（ethertype）、L3・L4 の中身です（日時と一部の値を短くしています）。

02:58:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.58.0.2 tell 10.58.0.1, length 28
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.58.0.2 is-at 02:58:00:00:00:02, length 28
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 74: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [S], ... length 0
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype IPv4 (0x0800), length 74: 10.58.0.2.25880 > 10.58.0.1.41730: Flags [S.], ... length 0
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [.], ack 1, ... length 0
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 144: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [P.], seq 1:79, ... length 78
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.58.0.2.25880 > 10.58.0.1.41730: Flags [.], ack 79, ... length 0
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype IPv4 (0x0800), length 183: 10.58.0.2.25880 > 10.58.0.1.41730: Flags [P.], seq 1:118, ... length 117
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [.], ack 118, ... length 0
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype IPv4 (0x0800), length 76: 10.58.0.2.25880 > 10.58.0.1.41730: Flags [P.], seq 118:128, ... length 10
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [.], ack 128, ... length 0
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.58.0.2.25880 > 10.58.0.1.41730: Flags [F.], seq 128, ... length 0
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [F.], seq 79, ... length 0
02:58:00:00:00:02 > 02:58:00:00:00:01, ethertype IPv4 (0x0800), length 66: 10.58.0.2.25880 > 10.58.0.1.41730: Flags [.], ack 80, ... length 0
02:58:00:00:00:01 > 02:58:00:00:00:02, ethertype IPv4 (0x0800), length 66: 10.58.0.1.41730 > 10.58.0.2.25880: Flags [.], ack 129, ... length 0

上から順に、層の働きがそのまま見えます。

144バイトのリクエストを1バイトずつ読む

6行目の HTTP リクエストのフレームを、-XX（L2 から全部を16進数で表示）で見ました。

tcpdump -r http.pcap -n -XX 'tcp[tcpflags] & tcp-push != 0'

    0x0000:  0258 0000 0002 0258 0000 0001 0800 4500  .X.....X......E.
    0x0010:  0082 7f17 4000 4006 a6e8 0a3a 0001 0a3a  ....@.@....:...:
    0x0020:  0002 a302 6518 c3c4 5469 fe60 de95 8018  ....e...Ti.`....
    0x0030:  003f 14eb 0000 0101 080a 4a52 d9e6 c807  .?........JR....
    0x0040:  b046 4745 5420 2f20 4854 5450 2f31 2e31  .FGET./.HTTP/1.1
    0x0050:  0d0a 486f 7374 3a20 3130 2e35 382e 302e  ..Host:.10.58.0.
    0x0060:  323a 3235 3838 300d 0a55 7365 722d 4167  2:25880..User-Ag
    0x0070:  656e 743a 2063 7572 6c2f 382e 352e 300d  ent:.curl/8.5.0.
    0x0080:  0a41 6363 6570 743a 202a 2f2a 0d0a 0d0a  .Accept:.*/*....

左の 0x0000 などは、先頭から何バイト目か（16進数）です。先頭から順に、L2 → L3 → L4 → L7 のヘッダーが並んでいます。 送る側では後から足したヘッダーほど前にある、というカプセル化の結果がそのまま見えます。

同じ解析を、標準ライブラリだけの Python で書くと次のとおりです。pcap ファイルの n 番目のフレームを、層ごとに分けて表示します。

# layers.py  使い方: python3 layers.py http.pcap 6   （6 = 何番目のフレームか）
import struct, sys

def packets(path):
    with open(path, "rb") as f:
        f.read(24)                      # pcap のファイルヘッダー
        while h := f.read(16):
            _, _, incl, _ = struct.unpack("<IIII", h)
            yield f.read(incl)

def mac(b): return ":".join(f"{x:02x}" for x in b)
def ip(b):  return ".".join(str(x) for x in b)

data = list(packets(sys.argv[1]))[int(sys.argv[2]) - 1]
print(f"フレーム全体: {len(data)} バイト")

# L2 Ethernet（14バイト）
dst, src, etype = data[0:6], data[6:12], struct.unpack("!H", data[12:14])[0]
print(f"[L2 Ethernet] 14バイト  宛先MAC={mac(dst)} 送信元MAC={mac(src)} type=0x{etype:04x}")

# L3 IPv4（IHL×4 バイト）
p = data[14:]
ihl = (p[0] & 0x0f) * 4
total, ttl, proto = struct.unpack("!H", p[2:4])[0], p[8], p[9]
print(f"[L3 IPv4]     {ihl}バイト  版={p[0]>>4} 全長={total} TTL={ttl} proto={proto}(TCP) "
      f"送信元={ip(p[12:16])} 宛先={ip(p[16:20])}")

# L4 TCP（データオフセット×4 バイト）
t = p[ihl:]
sport, dport, seq, ack = struct.unpack("!HHII", t[0:12])
off = (t[12] >> 4) * 4
flags = "".join(n for b, n in [(0x10, "ACK "), (0x08, "PSH "), (0x02, "SYN "), (0x01, "FIN ")] if t[13] & b)
print(f"[L4 TCP]      {off}バイト  送信元ポート={sport} 宛先ポート={dport} seq={seq} flags={flags.strip()}")

# L7 HTTP（残り全部）
app = t[off:total - ihl]
first = app.split(b"\r\n")[0].decode()
print(f"[L7 HTTP]     {len(app)}バイト  先頭行={first!r}")
print(f"ヘッダー合計 {14 + ihl + off} バイト ＋ データ {len(app)} バイト")

6番目（リクエスト）と8番目（応答）、3番目（接続の申し込み SYN）の結果です。

$ python3 layers.py http.pcap 6
フレーム全体: 144 バイト
[L2 Ethernet] 14バイト  宛先MAC=02:58:00:00:00:02 送信元MAC=02:58:00:00:00:01 type=0x0800
[L3 IPv4]     20バイト  版=4 全長=130 TTL=64 proto=6(TCP) 送信元=10.58.0.1 宛先=10.58.0.2
[L4 TCP]      32バイト  送信元ポート=41730 宛先ポート=25880 seq=3284423785 flags=ACK PSH
[L7 HTTP]     78バイト  先頭行='GET / HTTP/1.1'
ヘッダー合計 66 バイト ＋ データ 78 バイト

$ python3 layers.py http.pcap 8
フレーム全体: 183 バイト
[L2 Ethernet] 14バイト  宛先MAC=02:58:00:00:00:01 送信元MAC=02:58:00:00:00:02 type=0x0800
[L3 IPv4]     20バイト  版=4 全長=169 TTL=64 proto=6(TCP) 送信元=10.58.0.2 宛先=10.58.0.1
[L4 TCP]      32バイト  送信元ポート=25880 宛先ポート=41730 seq=4267761301 flags=ACK PSH
[L7 HTTP]     117バイト  先頭行='HTTP/1.0 200 OK'
ヘッダー合計 66 バイト ＋ データ 117 バイト

$ python3 layers.py http.pcap 3
フレーム全体: 74 バイト
[L2 Ethernet] 14バイト  宛先MAC=02:58:00:00:00:02 送信元MAC=02:58:00:00:00:01 type=0x0800
[L3 IPv4]     20バイト  版=4 全長=60 TTL=64 proto=6(TCP) 送信元=10.58.0.1 宛先=10.58.0.2
[L4 TCP]      40バイト  送信元ポート=41730 宛先ポート=25880 seq=3284423784 flags=SYN
[L7 HTTP]     0バイト  先頭行=''
ヘッダー合計 74 バイト ＋ データ 0 バイト

各フレームのうち、どれだけがヘッダーかを並べると次のようになります。

読み取れることです。

• IPv4 と TCP のヘッダーは、どちらも最小20バイトです。 ここでは TCP にタイムスタンプのオプション（12バイト）が付いて32バイト、SYN では MSS などのオプションが付いて40バイトでした。
• tcpdump で見える Ethernet フレームには、末尾の FCS（誤り検出用の4バイト）が含まれていません。 L1 のプリアンブル（同期用の信号）も見えません。
• 表示の length 144 は L2 から数えた大きさ、length 78 は L4 の後ろ（HTTP のデータ）の大きさです。同じ行に2つの length が出るのは、層ごとに数えているためです。

HTTPSにすると、L7の中身は読めなくなる

同じ2台のあいだで、openssl s_server を使った HTTPS のサーバーに curl -k（証明書の確認を省く）でアクセスし、HTTP リクエストを運んだフレームを見ました。

    0x0000:  0258 0000 0002 0258 0000 0001 0800 4500  .X.....X......E.
    0x0010:  0098 2801 4000 4006 fde8 0a3a 0001 0a3a  ..(.@.@....:...:
    0x0020:  0002 da26 64f3 acbe 4eeb 65a9 9173 8018  ...&d...N.e..s..
    0x0030:  003f 1501 0000 0101 080a d318 0a3f 3e86  .?...........?>.
    0x0040:  ab77 1703 0300 5fc1 41be 109e f21b f8e1  .w...._.A.......
    0x0050:  55cd c03d a081 2170 63c5 b5fe b804 6977  U..=..!pc.....iw

L2・L3・L4 のヘッダーは HTTP のときと同じ形で、そのまま読めます。 変わったのは L4 より後ろです。先頭の 17 03 03 00 5f は TLS の記録の見出し（17 はアプリのデータ、00 5f は長さ 95バイト）で、その後ろは暗号化されています。取ったファイル全体で GET / という文字列を数えると、HTTP では1か所、HTTPS では0か所でした。

tcpdump -r http.pcap -A | grep -c 'GET /'   # → 1
tcpdump -r tls.pcap  -A | grep -c 'GET /'   # → 0

途中の機器（ルーターやスイッチ）が IPアドレス・ポート番号を見て中継できるのは、暗号化が L4 より上だけにかかっているからです。

関連記事「opensslコマンドの使い方｜目的別一覧と実行結果・エラー対処【3系】」で扱っています。

通信トラブルを層ごとに切り分ける手順

「つながらない」ときは、下の層から順に確かめると、原因の層を1つずつ消していけます。上と同じ2台の環境で、わざと障害を起こして出た表示を載せます。

実際に起こしたエラーの原文と、層の見分け方

見分けるときのポイントです。

• 自分の IP から返る Destination Host Unreachable は L2 の問題です。 同じネットワーク内の相手に ARP を送っても答えが無いとき、Linux の ping は自分のアドレス（From 10.58.0.1）からこの表示を出しました。ping を3回で止めると、表示が出ないまま 100% packet loss で終わったので、5回以上送ると見分けやすくなります。
• refused と timed out の違いは、L4 で相手が答えたかどうかです。 閉じたポートへの接続では、相手から RST（接続を断る知らせ）がすぐ返りました。ファイアウォールで捨てると何も返らず、待ち時間の3秒で失敗しました。

10.58.0.1.33556 > 10.58.0.2.25881: Flags [S], seq 3519742829, win 64240, ... length 0
10.58.0.2.25881 > 10.58.0.1.33556: Flags [R.], seq 0, ack 3519742830, win 0, length 0

• curl 8.5.0 は、閉じたポートでも curl: (7) Failed to connect to 10.58.0.2 port 25881 after 0 ms: Couldn't connect to server と表示し、refused の文字は出ませんでした。after 0 ms のようにすぐ失敗したら拒否、待ち時間ちょうどで失敗したら遮断と見分けられます。

関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。

層ごとの確認コマンド（Linux・Windows・Mac）

接続のあと、クライアント側で ss -tan を見ると、閉じた接続が TIME-WAIT（閉じたあとしばらく残る状態）で残っていました。L4 の接続の状態は、このように ss で追えます。

State     Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
TIME-WAIT 0      0          10.58.0.1:32802    10.58.0.2:25880

関連記事「curlコマンドの使い方｜よく使うオプションとAPIの確認方法」で扱っています。

よくある質問

Q. OSI参照モデルとは何ですか？ A. 通信の働きを、物理（L1）からアプリケーション（L7）までの7つの層に分けて整理した国際標準の枠組みです。ISO/IEC 7498-1 と ITU-T X.200 で決められています。「OSI参照モデルとは」の節にあります。

Q. OSI基本参照モデルと OSI参照モデルは違うものですか？ A. 同じものです。規格の英語名「Basic Reference Model」を訳すと「基本参照モデル」になります。

Q. OSI参照モデルの7層の覚え方は？ A. 上から「アプセトネデブ」（アプリケーション・プレゼンテーション・セッション・トランスポート・ネットワーク・データリンク・物理）が知られています。L2・L3・L4 を「MAC・IP・ポート」と結びつけると、機器の名前と一緒に覚えられます。

Q. OSI参照モデルと TCP/IP モデルの違いは？ A. OSI は7層、TCP/IP は4層です。TCP/IP のアプリケーション層が OSI の L5〜L7、インターネット層が L3、リンク層が L1・L2 にあたります。実際の通信は TCP/IP で動いていて、OSI は説明や切り分けの共通語として使われます。

Q. L2スイッチと L3スイッチの違いは？ A. L2スイッチは MACアドレスを見て、同じネットワークの中で転送します。L3スイッチは IPアドレスも見て、別のネットワークへの中継（ルーティング）もします。

まとめ

• OSI参照モデル（OSI基本参照モデル）は、通信の働きを7層に分けた国際標準の枠組み。規格は ISO/IEC 7498-1:1994・ITU-T X.200。
• 実際の通信は TCP/IP の4層で動いている。L5〜L7 が TCP/IP のアプリケーション層、L1・L2 がリンク層にあたる。
• 送るデータには、L4・L3・L2 の順にヘッダーが前に足される。curl 1回の HTTP リクエストは、14＋20＋32バイトのヘッダーと78バイトのデータで144バイトのフレームだった。
• HTTPS では L4 より後ろだけが暗号化され、L2〜L4 のヘッダーはそのまま読める。
• つながらないときは下の層から。NO-CARRIER は L1、Destination Host Unreachable と ARP の FAILED は L2、Network is unreachable は L3、refused と timed out は L4 で見分けられる。

参考・出典

確認日はいずれも 2026年10月17日です。

• ISO「ISO/IEC 7498-1:1994 Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model」：https://www.iso.org/standard/20269.html
• ITU-T「X.200 : Information technology - Open Systems Interconnection - Basic Reference Model: The basic model」：https://www.itu.int/rec/T-REC-X.200-199407-I/en
• RFC 1122「Requirements for Internet Hosts -- Communication Layers」：https://www.rfc-editor.org/rfc/rfc1122
• RFC 791「Internet Protocol」：https://www.rfc-editor.org/rfc/rfc791
• RFC 9293「Transmission Control Protocol (TCP)」：https://www.rfc-editor.org/rfc/rfc9293
• tcpdump「tcpdump(1) man page」：https://www.tcpdump.org/manpages/tcpdump.1.html
• Microsoft Learn「Test-NetConnection」：https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。