#0171（2025/06/15）OSI参照モデル

## 1. はじめに

* OSI参照モデル (Open Systems Interconnection Reference Model) は、異機種間の通信を標準化するために ISO が 1984 年に策定した枠組みです。
* レイヤという階層化の考え方を導入し、**通信を 7 つの段階に分割**することで技術の交換性と相互運用性を確保します。
* 本稿では「なぜ 7 層なのか」「それぞれの層が何を担当するのか」を中上級エンジニア向けに**実運用・トラブルシュート視点**で掘り下げます。

---

## 2. OSI参照モデルが生まれた背景

* 1970 年代末、各ベンダが独自プロトコルを開発し **相互接続が困難**でした。
* ISO は CCITT (現 ITU-T) の X.25、ARPA の TCP/IP など複数案を統合しレイヤ化を提案。
* **目的**: ① 標準化、② 開発の分業、③ 新技術の継ぎ足しを容易に。
* 今日、多くのプロトコルは TCP/IP モデルで実装されていますが、概念整理として OSI は依然有効です。

---

## 3. 7 つのレイヤ概要

OSI参照モデルは、ネットワーク通信を7つの階層（レイヤ）に分け、それぞれに明確な役割を持たせることで、異なるベンダ間や技術間での互換性を担保します。
以下の表は、各レイヤの名称とその主な役割をまとめたものです。

| レイヤ | 名称         | 主な役割                            |
| --- | ---------- | ------------------------------- |
| L1  | 物理層        | ビットを物理信号に変換し、媒体上で送受信する          |
| L2  | データリンク層    | MACアドレスを使って同一ネットワーク内のフレーム伝送を行う  |
| L3  | ネットワーク層    | IPアドレスに基づき、異なるネットワーク間でパケットを転送する |
| L4  | トランスポート層   | エンドツーエンドの信頼性（順序制御、再送など）を提供する    |
| L5  | セッション層     | 通信の開始・維持・終了と再開点の管理を行う           |
| L6  | プレゼンテーション層 | データの表現形式（暗号、圧縮、文字コード）を処理する      |
| L7  | アプリケーション層  | ユーザーが操作するアプリケーションとネットワークの接続を担う  |


---

## 4. 各層の詳細

### L1 物理層 – ビットが流れる世界

* **役割**: 0/1 のビットを電位差・光パルス・周波数変調など物理信号へ変換。
* **要素**: UTP/光ファイバ/同軸ケーブル、SFP/QSFP モジュール、RJ‑45 コネクタ、Wi‑Fi アンテナ。
* **パラメータ**: NRZ / PAM4 符号化方式、帯域幅、SNR、リンク長。
* **実践 TIP**: ケーブル不良は L1 起因。ケーブルテスターや OTDR で反射や減衰を測定。

---

### L2 データリンク層 – 同一セグメントの司令塔

* **サブレイヤ**: LLC (論理リンク制御) と MAC (メディアアクセス制御)。
* **代表プロトコル**: Ethernet、Wi‑Fi、PPP。
* **機能**: フレーム化、MAC アドレス付与、エラーチェック (FCS)、フロー制御 (PAUSE)。
* **スイッチング**: CAM テーブルで MAC→ポート学習、STP/RSTP でループ防止。
* **トラブル**: **フレームエラーカウンタ**増加は MTU ミスマッチや障害の兆候。

---

### L3 ネットワーク層 – ルーティングで世界を繋ぐ

* **責務**: IP アドレスに基づくパケット転送経路決定。
* **IPv4/IPv6**: サブネット、CIDR、NDP/ARP。
* **ルーティングプロトコル**: OSPF, BGP, IS‑IS。
* **ICMP**: ネットワーク診断 (ping, traceroute)。
* **障害解析**: ルーティングループやブラックホールは **RIB/FIB** 差異で検知。

---

### L4 トランスポート層 – 信頼性と多重化

* **TCP**: コネクション指向、3‑way ハンドシェイク、ウィンドウ制御、再送、SACK。
* **UDP**: コネクションレス、低レイテンシ重視 (VoIP, DNS)。
* **ポート番号**: アプリ識別 (HTTP 80, HTTPS 443)。
* **セキュリティ**: TLS は L4 上に暗号チャネル (正確には L5–L6 を跨いで実装)。
* **デバッグ**: `ss -tan`、`tcpdump -nn -p ip proto \(tcp or udp)` で確認。

---

### L5 セッション層 – 対話を管理

* **機能**: コネクションの確立／維持／終了、チェックポイントと再開。
* **実装例**: gRPC, SMB, NetBIOS、TLS ハンドシェイクの一部。
* **運用視点**: API ゲートウェイでセッション粘着 (stickiness) を設定する際に意識。

---

### L6 プレゼンテーション層 – データをわかりやすく

* **役割**: データ形式の変換・暗号化・圧縮。
* **例**: JPEG/PNG, AES, gzip, JSON ⇔ BSON 変換。
* **TLS/SSL**: 暗号・復号、証明書検証。OSI 的には L6 に位置付けられることが多い。
* **注意**: 文字コード不一致 (UTF‑8 vs Shift\_JIS) も L6 問題。

---

### L7 アプリケーション層 – ユーザが触れる領域

* **プロトコル**: HTTP(S), SMTP, DNS, SSH, MQTT。
* **機能**: アプリケーション固有の要求／応答フォーマットを定める。
* **例**: ブラウザ → サーバへ HTTP GET、メールクライアント → SMTP 送信。
* **オブザーバビリティ**: L7 ログ (URL パス, ステータスコード) は SRE の重要指標。

---

## 5. 障害解析は「どのレイヤで壊れたか」から始まる

* **L1**: ケーブル断線 → リンクダウン LED 消灯。
* **L2**: MAC 学習ミス → ARP は通るがフレームが迷子。
* **L3**: ルーティングループ → TTL exceeded。
* **L4**: TCP Retransmission 異常 → 輻輳/パケットロス。
* **L7**: 500 Internal Server Error → アプリケーションバグ。

---

## 6. OSIとTCP/IPモデルの比較

```mermaid
flowchart LR
  subgraph OSI["OSI 7 Layers"]
    L7["L7
Application"]
    L6["L6
Presentation"]
    L5["L5
Session"]
    L4["L4
Transport"]
    L3["L3
Network"]
    L2["L2
Data Link"]
    L1["L1
Physical"]
  end
  subgraph TCPIP["TCP/IP 4 Layers"]
    T4["Application"]
    T3["Transport"]
    T2["Internet"]
    T1["Network Interface"]
  end
  L7 --> T4
  L6 --> T4
  L5 --> T4
  L4 --> T3
  L3 --> T2
  L2 --> T1
  L1 --> T1
```

* **補足**

    - **Transport** (TCP/UDP) は両モデルで共通だが、TCP/IP側ではポート番号・多重化の概念をより実装ベースで定義。
    - 実務では TCP/IP が標準実装ですが、障害切り分けや設計レビューでは OSI の 7 層分割が役立ちます。
    - 現代プロトコル (HTTP/3/QUIC) は Transport+Application を跨ぐため、レイヤの境界は徐々に曖昧になりつつあります。

---

## 7. クラウド・コンテナ時代のレイヤ思考. クラウド・コンテナ時代のレイヤ思考

* VPC/Subnet, Security Group → L3/L4 の仮想化。
* Service Mesh (Istio) → L4–L7 を sidecar で抽象化。
* eBPF でカーネル空間 (L3/L4) 可視化、Envoy で L7 ルーティング。
* **ゼロトラスト**: L7 認証 + L3 マイクロセグメンテーション。

---

## 8. まとめ

* OSI 参照モデルは**実装よりも概念整理**として価値が高く、トラブルシュートや設計レビューのフレームワークとなります。
* 各層の責務を正しく理解すると、障害切り分けが迅速化し、セキュリティ施策の適用ポイントも明確に。
* クラウドや SDN で境界が曖昧になっても、レイヤ思考を持つことはエンジニアに必須のスキルです。