OSI参照モデルとTCP/IPモデル

ネットワーク通信を「層」に分けて理解するモデル。OSI 7層モデルは理論、TCP/IP 4層モデルは実践。各層の役割とプロトコルの対応関係を把握する。

この章で学ぶこと

• OSI 7層モデルの各層の役割を理解する
• TCP/IP 4層モデルとの対応関係を把握する
• 各層の代表的なプロトコルを学ぶ
• カプセル化と非カプセル化のプロセスを把握する
• 各層のヘッダー構造を詳細に理解する
• ポート番号の体系と実務での使い方を学ぶ
• パケットキャプチャによる実践的な分析手法を習得する
• トラブルシューティングにおける層別アプローチを学ぶ

前提知識

• インターネットの仕組み（./00-how-internet-works.md）
• ネットワークの基本用語（パケット、プロトコル、サーバー、クライアント）
• コマンドライン（ターミナル）の基本操作

1. ネットワークモデルの歴史と背景

1.1 なぜ階層モデルが必要なのか

ネットワーク通信の複雑さ:
  アプリケーションが直接ハードウェアを制御する世界を想像してみる:

  1. メールアプリが自分でイーサネットフレームを組み立てる
  2. Webブラウザが電気信号のタイミングを制御する
  3. ゲームが光ファイバーの変調方式を意識する

  → これでは開発が不可能に近い
  → 各層を分離し、インターフェースだけを定義すれば
    上位層は下位層の実装を意識しなくて済む

階層化のメリット:
  ① 責務の分離: 各層が特定の機能に集中
  ② 交換可能性: 同じ層のプロトコルを差し替え可能
     例: Ethernet → Wi-Fi に変えてもTCP/IPは変わらない
  ③ 標準化: 異なるベンダーの機器が相互に通信可能
  ④ トラブルシューティング: 問題の層を特定して対処
  ⑤ 独立した進化: 各層が独自に発展可能
     例: HTTP/1.1 → HTTP/2 に変えてもTCPは変わらない

具体例で理解する階層化:
  郵便システムとの類比:

1.2 OSIモデルの誕生

歴史的経緯:
  1970年代: 各社が独自のネットワークプロトコルを開発
    - IBM: SNA (Systems Network Architecture)
    - DEC: DECnet
    - Xerox: XNS
    → 異なるメーカーの機器間で通信不可能

  1977年: ISO（国際標準化機構）がOSI参照モデルの策定を開始
  1984年: OSI参照モデル（ISO 7498）として公式発行
    → 7層の参照モデルとして定義
    → 「参照」モデル = 具体的な実装ではなく概念的な枠組み

  しかし:
    - OSIプロトコルスイート自体は複雑すぎて普及せず
    - 代わりにTCP/IPが事実上の標準（de facto standard）に
    - OSIモデルは教育・設計の参照フレームワークとして現在も使用

TCP/IPの勝利:
  1969年: ARPANET（インターネットの前身）で実験開始
  1974年: Vint Cerf & Bob Kahn がTCP/IPの概念を発表
  1983年: ARPANETがNCP → TCP/IPに切り替え（Flag Day）
  1990年代: WWWの爆発的普及でTCP/IPが事実上の標準に

  なぜTCP/IPが勝ったか:
    ① シンプル: 4層で十分実用的
    ② 実装先行: 実際に動くものが先にあった
    ③ 無料: BSDに実装が含まれ、誰でも利用可能
    ④ スケーラビリティ: インターネットの成長に対応できた

2. OSI参照モデル（7層）の詳細

2.1 モデル全体像

覚え方（上から）:
  日本語: 「あぷせとねでぶ」（ア プ セ ト ネ デ ブ）
  英語:   "All People Seem To Need Data Processing"
  英語:   "Please Do Not Throw Sausage Pizza Away"（下から）

2.2 第7層: アプリケーション層

役割:
  ユーザーが直接利用するアプリケーションにネットワーク機能を提供
  → ネットワーク透過なサービスの提供

代表的なプロトコル:

  HTTP/HTTPS（ポート80/443）:
    Webページの取得・API通信
    → ブラウザ、REST API、GraphQL

  FTP/SFTP（ポート20-21/22）:
    ファイル転送
    → サーバーへのファイルアップロード・ダウンロード

  SMTP（ポート25/587）:
    メール送信
    → メールサーバー間の通信

  POP3/IMAP（ポート110/143）:
    メール受信
    → メールクライアントがサーバーからメールを取得

  DNS（ポート53）:
    名前解決（ドメイン名 → IPアドレス）
    → ほぼ全てのインターネット通信の前段階

  SSH（ポート22）:
    セキュアなリモートアクセス
    → サーバー管理、ポートフォワーディング

  SNMP（ポート161/162）:
    ネットワーク機器の監視・管理
    → ルーター、スイッチの状態監視

  NTP（ポート123）:
    時刻同期
    → 全デバイスの時計を合わせる

  DHCP（ポート67/68）:
    IPアドレスの自動割り当て
    → ネットワーク接続時の自動設定

  LDAP（ポート389/636）:
    ディレクトリサービス
    → Active Directory、ユーザー認証

実務での位置づけ:
  ほとんどのアプリケーション開発者が直接扱う層
  → API設計、WebSocket実装、メール送信機能など

2.3 第6層: プレゼンテーション層

役割:
  データの表現形式の変換、暗号化、圧縮
  → アプリケーション層が扱いやすい形にデータを整形

主な機能:

  ① データ形式変換:
     文字コード: UTF-8, ASCII, Shift-JIS, EUC-JP
     データ形式: JSON, XML, ASN.1, Protocol Buffers
     画像形式:   JPEG, PNG, GIF, WebP
     音声形式:   MP3, AAC, Opus
     動画形式:   H.264, H.265, VP9, AV1

  ② 暗号化/復号:
     TLS/SSL: HTTPS通信の暗号化
       → AES-256-GCM（データ暗号化）
       → RSA/ECDHE（鍵交換）
       → SHA-256（ハッシュ）

  ③ 圧縮/展開:
     gzip, brotli, zstd
     → HTTPレスポンスの圧縮
     → 帯域幅の節約

  実務例:
    Content-Type: application/json; charset=utf-8
    Content-Encoding: gzip
    → データ形式（JSON）、文字コード（UTF-8）、圧縮（gzip）を指定

  TCP/IPモデルでは:
    プレゼンテーション層はアプリケーション層に統合される
    → TLS はトランスポート層とアプリケーション層の間に位置
    → データ形式はアプリケーションが自分で処理

2.4 第5層: セッション層

役割:
  通信のセッション（対話）を確立・維持・終了する
  → いつ通信を開始し、いつ終了するかの管理

主な機能:

  ① セッション確立:
     → 認証情報の交換
     → 通信パラメータの合意

  ② セッション維持:
     → チェックポイント: 長時間転送の途中経過を保存
     → 同期ポイント: 障害時にどこから再開するかを記録

  ③ セッション終了:
     → グレースフルクローズ: 両者が合意して終了
     → アボート: 異常時の強制終了

  代表的なプロトコル/技術:
    NetBIOS: Windows のファイル共有
    RPC（Remote Procedure Call）: リモート関数呼び出し
    SIP（Session Initiation Protocol）: VoIP通話の確立
    PPTP: VPNトンネリング

  実務例:
    Webアプリケーションのセッション管理:
      → HTTPは本来ステートレス
      → Cookieやトークンでセッションを実現
      → サーバーサイドのセッションストア（Redis等）

  TCP/IPモデルでは:
    セッション層もアプリケーション層に統合される
    → セッション管理はアプリケーションの責務

2.5 第4層: トランスポート層

役割:
  エンドツーエンド（端末間）の通信を管理
  → プロセス間通信のためのポート番号の概念を提供

主な機能:

  ① 信頼性の提供（TCP）:
     → データの到達保証
     → 順序保証
     → エラー検出と再送
     → フロー制御と輻輳制御

  ② 軽量な通信（UDP）:
     → コネクションレス
     → 低レイテンシ
     → ブロードキャスト/マルチキャスト対応

  ③ ポート番号によるプロセス識別:
     → 送信元ポート + 宛先ポート でプロセスを特定
     → 1つのIPアドレスで複数のサービスを提供

  PDU（Protocol Data Unit）: セグメント（TCP）/ データグラム（UDP）

  代表的なプロトコル:
    TCP: 信頼性重視（HTTP, SSH, FTP等）
    UDP: 速度重視（DNS, 動画配信, ゲーム等）
    SCTP: マルチストリーム対応（電話網のシグナリング等）
    QUIC: UDP上のモダンプロトコル（HTTP/3の基盤）

  実務での重要性:
    → ソケットプログラミングの基盤
    → ファイアウォールのルール設定（ポート制御）
    → ロードバランサーのL4バランシング
    → コンテナのポートマッピング

2.6 第3層: ネットワーク層

役割:
  異なるネットワーク間のルーティング（経路選択）
  → 送信元から宛先までの最適な経路を決定

主な機能:

  ① 論理アドレッシング（IPアドレス）:
     → 全デバイスに一意のアドレスを付与
     → ネットワーク部とホスト部に分割

  ② ルーティング:
     → パケットを宛先に向けて転送
     → ルーティングテーブルに基づく経路選択
     → 動的ルーティング: OSPF, BGP, RIP
     → 静的ルーティング: 手動設定

  ③ パケットのフラグメンテーション:
     → MTU（Maximum Transmission Unit）を超えるパケットの分割
     → 受信側で再組み立て

  PDU: パケット

  代表的なプロトコル:
    IPv4: 32ビットアドレス（現在の主流）
    IPv6: 128ビットアドレス（次世代）
    ICMP: 制御メッセージ（ping, traceroute）
    ARP:  IPアドレス → MACアドレス解決
    OSPF: 内部ルーティングプロトコル
    BGP:  外部ルーティングプロトコル（インターネットの骨格）

  ネットワーク機器:
    ルーター: L3で動作、パケットを転送
    L3スイッチ: ルーティング機能付きスイッチ

  実務例:
    $ ip route show          # ルーティングテーブル表示（Linux）
    $ netstat -rn            # ルーティングテーブル表示（汎用）
    $ traceroute example.com # 経路追跡
    $ ping example.com       # ICMP疎通確認

2.7 第2層: データリンク層

役割:
  物理的に接続された隣接ノード間の信頼性ある通信
  → 同一ネットワークセグメント内でのフレーム転送

主な機能:

  ① フレーミング:
     → ビット列をフレーム単位に区切る
     → フレームの開始/終了を識別

  ② 物理アドレッシング（MACアドレス）:
     → 48ビット（6バイト）のハードウェアアドレス
     → 例: 00:1A:2B:3C:4D:5E
     → 前半24ビット: OUI（製造元識別子）
     → 後半24ビット: デバイス固有ID

  ③ エラー検出:
     → FCS（Frame Check Sequence）による誤り検出
     → CRC-32アルゴリズム
     → 誤りの訂正は行わず、フレームを破棄

  ④ メディアアクセス制御（MAC副層）:
     → CSMA/CD（Ethernet）: 衝突検出して再送
     → CSMA/CA（Wi-Fi）: 衝突回避
     → トークンパッシング: トークンを持つ端末だけが送信

  PDU: フレーム

  サブ層:
    LLC（Logical Link Control）:
      → ネットワーク層プロトコルの識別
      → フロー制御

    MAC（Media Access Control）:
      → メディアへのアクセス制御
      → MACアドレスによるフレーム配信

  代表的なプロトコル/技術:
    Ethernet（IEEE 802.3）: 有線LAN
    Wi-Fi（IEEE 802.11）: 無線LAN
    PPP: ポイントツーポイント接続
    VLAN（IEEE 802.1Q）: 仮想LAN

  ネットワーク機器:
    スイッチ（L2スイッチ）: MACアドレステーブルに基づくフレーム転送
    ブリッジ: ネットワークセグメントの接続

  実務例:
    $ arp -a                # ARPテーブル表示
    $ ip link show          # インターフェース情報
    $ ethtool eth0          # Ethernetインターフェース詳細
    $ iwconfig wlan0        # Wi-Fiインターフェース詳細

2.8 第1層: 物理層

役割:
  ビット列を物理的な信号（電気・光・電波）に変換して伝送
  → 0と1を実際の信号として送受信する

主な機能:

  ① 信号変換:
     → デジタル信号 ↔ 電気信号（銅線）
     → デジタル信号 ↔ 光信号（光ファイバー）
     → デジタル信号 ↔ 電波（無線）

  ② 伝送媒体の特性定義:
     → ケーブルの種類、コネクタの形状
     → 伝送速度、帯域幅
     → 最大伝送距離

  ③ 信号の同期:
     → ビット同期: クロック信号の共有
     → 基準電圧の定義

  伝送媒体の比較:

ネットワーク機器:
    ハブ: 受信した信号を全ポートに転送（現在はほぼ使われない）
    リピーター: 信号を増幅・再生
    メディアコンバーター: 銅線 ↔ 光ファイバーの変換

  コネクタ:
    RJ-45: Ethernetケーブル（UTPケーブル）
    LC, SC: 光ファイバーコネクタ
    SFP/SFP+/QSFP: モジュール式光トランシーバー

3. TCP/IP モデル（4層）の詳細

3.1 モデル全体像

実務では TCP/IP モデルが主流:
  → OSI は理論的な参照モデル
  → TCP/IP は実際のインターネットの構造
  → 5層モデル（ハイブリッドモデル）を使う教科書も多い

3.2 OSIモデルとの対応比較

7層モデル vs 4層モデル の詳細対応:

  OSI 7層                TCP/IP 4層           5層モデル
  ─────────────         ────────────         ────────────
  L7 アプリケーション ─┐
  L6 プレゼンテーション┼→ アプリケーション → L5 アプリケーション
  L5 セッション ───────┘
  L4 トランスポート ───→ トランスポート   → L4 トランスポート
  L3 ネットワーク ─────→ インターネット   → L3 ネットワーク
  L2 データリンク ─────┐
  L1 物理 ─────────────┼→ ネットワーク     → L2 データリンク
                        │  インターフェース → L1 物理
                        └─────────────────

なぜ5層モデルが使われることがあるか:
  TCP/IP 4層モデルでは物理層とデータリンク層を区別しない
  → しかし実務ではこの2つは全く異なる技術領域
  → 5層モデルはOSIの下位2層の区別を維持しつつ、
    上位3層を統合した実用的な妥協案

各モデルの使い分け:
  OSI 7層: 教育、資格試験（CCNA, CompTIA Network+）、設計文書
  TCP/IP 4層: プロトコル仕様書（RFC）、実装
  5層モデル: 大学の教科書、実務的な議論

3.3 TCP/IP各層の実務における役割

① アプリケーション層の実務:
  開発者が最も関わる層
  → REST API の設計（HTTP）
  → WebSocket によるリアルタイム通信
  → gRPC によるマイクロサービス通信
  → メール機能の実装（SMTP/IMAP）
  → DNS設定とトラブルシューティング
  → TLS/SSL証明書の管理

  実務でよく扱うツール:
    curl: HTTPリクエストの送信
    Postman: API テスト
    openssl: TLS/SSL のデバッグ
    dig/nslookup: DNS 問い合わせ

② トランスポート層の実務:
  → ソケットプログラミング
  → ポート番号の管理（ファイアウォール設定）
  → ロードバランサーの設定（L4 vs L7）
  → TCPチューニング（カーネルパラメータ）

  実務でよく扱うツール:
    netstat/ss: ソケットの状態確認
    tcpdump: パケットキャプチャ
    iptables/nftables: ファイアウォール

③ インターネット層の実務:
  → IPアドレス設計（VPC, サブネット）
  → ルーティング設定
  → NAT設定
  → VPN構築

  実務でよく扱うツール:
    ip: ネットワーク設定（Linux）
    traceroute: 経路追跡
    ping: 疎通確認

④ ネットワークインターフェース層の実務:
  → VLAN設定
  → Wi-Fi設定
  → ネットワークインターフェースの設定
  → MTUの調整

  実務でよく扱うツール:
    ethtool: Ethernet設定
    iwconfig: Wi-Fi設定
    ifconfig/ip link: インターフェース管理

4. カプセル化と非カプセル化

4.1 カプセル化の基本プロセス

データが各層を通過する際の変化:

  アプリケーション層:
    [HTTP データ]

  トランスポート層:
    [TCP ヘッダー][HTTP データ]  ← セグメント

  インターネット層:
    [IP ヘッダー][TCP ヘッダー][HTTP データ]  ← パケット

  ネットワーク層:
    [Eth ヘッダー][IP][TCP][HTTP データ][Eth FCS]  ← フレーム

  物理層:
    01101001 10110010 ...  ← ビット列

  送信側: データにヘッダーを追加（カプセル化）
  受信側: ヘッダーを除去して上位層に渡す（非カプセル化）

4.2 各層のPDU（Protocol Data Unit）

PDU = 各層でデータを呼ぶ際の単位名

4.3 カプセル化の具体例

HTTPリクエストが送信されるまでの完全な流れ:

ステップ1: アプリケーション層
  ブラウザが HTTP GET リクエストを生成:
  GET /index.html HTTP/1.1
  Host: www.example.com
  Accept: text/html
  → データサイズ: 約200バイト

ステップ2: トランスポート層（TCP）
  TCPヘッダー（20バイト）を追加:

→ セグメントサイズ: 220バイト

ステップ3: インターネット層（IPv4）
  IPヘッダー（20バイト）を追加:

→ パケットサイズ: 240バイト

ステップ4: データリンク層（Ethernet）
  Ethernetヘッダー（14バイト）+ FCS（4バイト）を追加:

→ フレームサイズ: 258バイト

ステップ5: 物理層
  フレームをビット列に変換:
  → 258 × 8 = 2064ビット の電気信号/光信号
  → プリアンブル（8バイト）+ フレーム + IFG（12バイト）
  → 合計: 278バイト がワイヤー上を流れる

4.4 ルーターでの非カプセル化と再カプセル化

パケットがルーターを通過する際の処理:

  送信元PC ──→ ルーターA ──→ ルーターB ──→ 宛先サーバー

  ルーターAでの処理:
  1. 物理層: 電気信号 → ビット列
  2. データリンク層: フレームを受信、FCSを検証
     → 自分のMACアドレス宛か確認
     → Ethernetヘッダーを除去（非カプセル化）
  3. ネットワーク層: IPヘッダーを読む
     → 宛先IPを確認
     → ルーティングテーブルで次ホップを決定
     → TTLを1減算
     → 必要ならフラグメンテーション
  4. データリンク層: 新しいEthernetヘッダーを付加（再カプセル化）
     → 宛先MAC = ルーターBのMACアドレス
     → 送信元MAC = ルーターAの出力インターフェースのMAC
  5. 物理層: ビット列 → 電気信号

  重要なポイント:
    → L2ヘッダー（MAC）はホップごとに書き換わる
    → L3ヘッダー（IP）は基本的に変わらない（NATを除く）
    → L4ヘッダー（TCP/UDP）も変わらない（NAPTを除く）

  図解:
  PC → ルーターA → ルーターB → サーバー

  PC→ルーターA:
    SrcMAC=PC   DstMAC=RA   SrcIP=PC   DstIP=Srv

  ルーターA→ルーターB:
    SrcMAC=RA   DstMAC=RB   SrcIP=PC   DstIP=Srv  ← MACだけ変化

  ルーターB→サーバー:
    SrcMAC=RB   DstMAC=Srv  SrcIP=PC   DstIP=Srv  ← MACだけ変化

5. 各層のヘッダー詳細

5.1 Ethernetフレームヘッダー（L2）

Ethernet II フレーム（DIX形式、最も一般的）:

各フィールドの説明:
    Preamble（7バイト）: 0xAAAAAA... 受信側のクロック同期用
    SFD（1バイト）: 0xAB フレーム開始デリミタ
    宛先MAC（6バイト）: 宛先の物理アドレス
      例: 00:1A:2B:3C:4D:5E
      FF:FF:FF:FF:FF:FF = ブロードキャスト
    送信元MAC（6バイト）: 送信元の物理アドレス
    Type（2バイト）: 上位プロトコルの識別
      0x0800 = IPv4
      0x0806 = ARP
      0x86DD = IPv6
      0x8100 = 802.1Q VLAN タグ
    FCS（4バイト）: CRC-32によるエラー検出

  802.1Q VLANタグ付きフレーム:

VLANタグ:
      PCP（3ビット）: 優先度（QoS）
      DEI（1ビット）: 破棄適格性
      VID（12ビット）: VLAN ID（0-4095）
      → 最大4094個のVLANを定義可能（0と4095は予約）

  MTU（Maximum Transmission Unit）:
    標準: 1500バイト（ペイロードの最大サイズ）
    ジャンボフレーム: 9000バイト（データセンター内で使用）
    → MTUを超えるとIPフラグメンテーションが発生
    → パフォーマンス低下の原因になるため、Path MTU Discoveryが重要

5.2 IPパケットヘッダー（L3）

IPv4 ヘッダー（20バイト〜60バイト）:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

主要フィールド:
    Version（4ビット）: 4（IPv4）
    IHL（4ビット）: ヘッダー長（32ビット単位）、通常5（=20バイト）
    ToS/DSCP（8ビット）: サービス品質（QoS）
      DSCP（6ビット）: 差別化サービス
      ECN（2ビット）: 輻輳通知
    全長（16ビット）: パケット全体のバイト数（最大65535）
    識別子（16ビット）: フラグメントの再組み立て用
    フラグ（3ビット）:
      DF（Don't Fragment）: フラグメント禁止
      MF（More Fragments）: 後続フラグメントあり
    TTL（8ビット）: Time To Live（ホップ数制限）
      初期値: 64（Linux）、128（Windows）、255（ネットワーク機器）
      ルーター通過ごとに1減算、0になったらパケット破棄 + ICMP Time Exceeded
      → tracerouteの仕組みはTTLを利用
    プロトコル（8ビット）:
      1 = ICMP
      6 = TCP
      17 = UDP
      47 = GRE
      50 = ESP（IPsec）

5.3 TCPセグメントヘッダー（L4）

TCP ヘッダー構造（20バイト〜60バイト）:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

主要フラグ:
  SYN: 接続開始
  ACK: 確認応答
  FIN: 接続終了
  RST: 接続リセット（異常終了）
  PSH: バッファリングせず即座に配信
  URG: 緊急データあり
  ECE: ECN-Echo（輻輳通知受信）
  CWR: Congestion Window Reduced（輻輳ウィンドウ縮小済み）

  重要なオプション:
  MSS: Maximum Segment Size（通常1460バイト）
    → MTU(1500) - IPヘッダー(20) - TCPヘッダー(20) = 1460
  Window Scale: ウィンドウサイズの拡張（最大1GB）
    → 16ビット × 2^14 = 最大1GBウィンドウ
  SACK: Selective ACK（部分的な再送を可能に）
  Timestamp: RTT測定用、PAWS（Protection Against Wrapped Sequences）

5.4 UDPデータグラムヘッダー（L4）

UDP ヘッダー構造（8バイト固定）:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

特徴:
    → TCPの20-60バイトに対してわずか8バイト
    → シーケンス番号なし、ACKなし、ウィンドウサイズなし
    → 最小限の情報だけ → 高速処理が可能
    → チェックサムはIPv4ではオプション、IPv6では必須

6. ポート番号の体系

6.1 よく使うポート番号

6.2 ポート番号の範囲と分類

ポート番号の範囲:
  0-1023:     ウェルノウンポート（Well-known Ports）
    → root権限/管理者権限が必要
    → IANAが管理する公式割り当て
    → 例: 80(HTTP), 443(HTTPS), 22(SSH), 53(DNS)

  1024-49151: レジスタードポート（Registered Ports）
    → 一般ユーザーでも使用可能
    → IANAに登録されたアプリケーション用
    → 例: 3306(MySQL), 5432(PostgreSQL), 8080(HTTP代替)

  49152-65535: ダイナミック/エフェメラルポート（Dynamic/Ephemeral Ports）
    → クライアント側の一時的なポート
    → OSが自動的に割り当て
    → 接続ごとに異なるポートを使用

  エフェメラルポートの範囲（OS別）:
    Linux:   32768-60999（/proc/sys/net/ipv4/ip_local_port_range）
    Windows: 49152-65535
    macOS:   49152-65535

  実務例: ファイアウォール設定
    # インバウンド（サーバー側）
    ポート 80/443 を許可（Webサーバー）
    ポート 22 を特定IPからのみ許可（SSH）

    # アウトバウンド（クライアント側）
    通常は全ポート許可（エフェメラルポートを制限すると通信不可）

6.3 ソケットとポートの関係

ソケット = IPアドレス + ポート番号の組み合わせ

  TCP接続の識別（5タプル）:
    ① プロトコル: TCP
    ② 送信元IP:   192.168.1.100
    ③ 送信元ポート: 54321
    ④ 宛先IP:     93.184.216.34
    ⑤ 宛先ポート:  443

  → 5タプルが異なれば別々の接続として識別
  → 1つのサーバーポートに複数のクライアントが接続可能

  例: Webサーバー（ポート443）への複数接続
    接続1: (TCP, 192.168.1.10:50001, 93.184.216.34:443)
    接続2: (TCP, 192.168.1.10:50002, 93.184.216.34:443)
    接続3: (TCP, 192.168.1.11:50001, 93.184.216.34:443)
    → 全て別々の接続として管理される

  最大接続数の理論値:
    1つのサーバーポートに対して:
    → 2^32（IP）× 2^16（ポート）= 約2.8×10^14 接続
    → 実際はメモリやファイルディスクリプタで制限される
    → Linux: ulimit -n で確認（デフォルト1024、設定可能）

  ポート確認コマンド:
    $ ss -tlnp              # TCP LISTENポート一覧
    $ ss -tunp              # 全アクティブ接続
    $ lsof -i :8080         # 特定ポートを使用中のプロセス
    $ netstat -tlnp         # TCP LISTENポート一覧（レガシー）

7. パケットキャプチャによる実践分析

7.1 tcpdumpによるキャプチャ

# 基本的なキャプチャ
sudo tcpdump -i eth0
 
# 特定ホストへの通信
sudo tcpdump -i eth0 host 192.168.1.100
 
# 特定ポートの通信
sudo tcpdump -i eth0 port 80
 
# TCPフラグでフィルタ（SYNパケットのみ）
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'
 
# ファイルに保存（後でWiresharkで分析）
sudo tcpdump -i eth0 -w capture.pcap
 
# パケットの中身を表示（16進ダンプ）
sudo tcpdump -i eth0 -X port 80
 
# 最初の10パケットだけキャプチャ
sudo tcpdump -i eth0 -c 10

7.2 Wiresharkでの分析

Wireshark = GUIパケット分析ツール（ネットワークエンジニア必須）

主要な表示フィルタ:
  http                          # HTTPトラフィック
  tcp.port == 443               # ポート443の通信
  ip.addr == 192.168.1.100      # 特定IPの通信
  tcp.flags.syn == 1            # SYNパケット
  tcp.analysis.retransmission   # 再送パケット
  dns                           # DNS通信
  tcp.analysis.zero_window      # ゼロウィンドウ

分析のポイント:
  ① TCP 3-way Handshake の確認:
     SYN → SYN-ACK → ACK の流れを追跡
     → RTT（Round Trip Time）を計測

  ② HTTP リクエスト/レスポンスの確認:
     → リクエストヘッダー、ボディの内容
     → レスポンスのステータスコード
     → Content-Length, Transfer-Encoding

  ③ TCP再送の検出:
     → [TCP Retransmission] マークのパケット
     → 再送頻度が高い = ネットワーク品質の問題

  ④ DNSクエリの確認:
     → クエリタイプ（A, AAAA, MX等）
     → 応答時間
     → レスポンスのIPアドレス

  ⑤ TLSハンドシェイクの分析:
     → Client Hello: 対応する暗号スイート一覧
     → Server Hello: 選択された暗号スイート
     → 証明書の確認

7.3 実務的なキャプチャシナリオ

シナリオ1: Webアプリのレスポンスが遅い

  キャプチャポイント:
  クライアント ──→ ロードバランサー ──→ Webサーバー ──→ DB

  分析手順:
  1. DNS解決時間を確認（dns.time > 0.1 は問題）
  2. TCP接続確立時間を確認（SYN → SYN-ACK の間隔）
  3. TLSハンドシェイク時間を確認
  4. HTTPリクエスト→レスポンスの時間を確認
  5. 再送パケットの有無を確認

  → 遅延がどの層で発生しているかを特定

シナリオ2: 接続が突然切れる

  確認ポイント:
  1. RST パケットが送られているか
     → アプリケーションが異常終了した可能性
  2. FIN が送られているか
     → 正常なクローズの可能性
  3. パケットが消えているか（片方だけ送信）
     → ネットワーク機器の問題

シナリオ3: TCPウィンドウサイズの問題

  確認ポイント:
  1. tcp.analysis.zero_window でフィルタ
  2. ウィンドウサイズの推移を確認
  3. Window Scale オプションが設定されているか
  → 受信側の処理が追いつかない場合に発生

8. ネットワーク機器と動作する層

各機器がどの層で動作するかの理解:

L4ロードバランサー vs L7ロードバランサー:
  L4:
    → TCPコネクションレベルで振り分け
    → 高速（ヘッダーだけ見る）
    → DSR（Direct Server Return）が可能
    → 例: AWS NLB, HAProxy(TCPモード)

  L7:
    → HTTPリクエストの中身で振り分け
    → URL パス、ホスト名、Cookie で制御可能
    → SSL/TLS 終端が可能
    → 例: AWS ALB, nginx, HAProxy(HTTPモード)

クラウドでの対応（AWS）:

9. トラブルシューティングの層別アプローチ

9.1 ボトムアップアプローチ

問題が発生したとき、下位層から順に確認する:

Step 1: 物理層（L1）の確認
  □ ケーブルは正しく接続されているか
  □ リンクLEDは点灯しているか
  □ Wi-Fiの電波強度は十分か

  コマンド:
    $ ip link show                 # インターフェース状態
    $ ethtool eth0                 # リンク状態、速度
    $ iwconfig wlan0               # Wi-Fi信号強度

Step 2: データリンク層（L2）の確認
  □ MACアドレスは正しく取得されているか
  □ ARPテーブルに対向のエントリがあるか
  □ VLANの設定は正しいか

  コマンド:
    $ arp -a                       # ARPテーブル
    $ ip neigh show                # 近隣テーブル
    $ bridge vlan show             # VLAN設定

Step 3: ネットワーク層（L3）の確認
  □ IPアドレスは正しく設定されているか
  □ デフォルトゲートウェイに到達可能か
  □ ルーティングは正しいか
  □ 宛先にpingが通るか

  コマンド:
    $ ip addr show                 # IPアドレス確認
    $ ip route show                # ルーティングテーブル
    $ ping -c 3 192.168.1.1       # ゲートウェイへの疎通
    $ ping -c 3 8.8.8.8           # インターネットへの疎通
    $ traceroute example.com       # 経路追跡

Step 4: トランスポート層（L4）の確認
  □ 宛先ポートは開いているか
  □ ファイアウォールでブロックされていないか
  □ TCPハンドシェイクは完了するか

  コマンド:
    $ telnet example.com 80        # ポート到達確認
    $ nc -zv example.com 443       # ポートスキャン
    $ ss -tlnp                     # LISTEN中のポート
    $ iptables -L -n               # ファイアウォールルール

Step 5: アプリケーション層（L5-L7）の確認
  □ DNSは正しく解決されるか
  □ HTTPレスポンスは返ってくるか
  □ TLS/SSL証明書は有効か
  □ アプリケーションログにエラーはないか

  コマンド:
    $ dig example.com              # DNS解決
    $ curl -v https://example.com  # HTTP通信の詳細
    $ openssl s_client -connect example.com:443  # TLS確認

9.2 よくある問題と層の対応

10. 実務でのネットワークモデルの適用

10.1 Webアプリケーションの通信フロー

ブラウザで https://api.example.com/users にアクセスする場合の
完全な通信フロー:

Phase 1: DNS解決（アプリケーション層）
  ① ブラウザDNSキャッシュ → ミス
  ② OS DNSキャッシュ → ミス
  ③ リゾルバに問い合わせ（UDP:53）
  ④ api.example.com → 203.0.113.50 を取得
  → 所要時間: 5-50ms

Phase 2: TCP接続確立（トランスポート層）
  ① SYN（クライアント → サーバー）
  ② SYN-ACK（サーバー → クライアント）
  ③ ACK（クライアント → サーバー）
  → 所要時間: 1.5 RTT（東京-US間: 約150ms）

Phase 3: TLSハンドシェイク（プレゼンテーション/アプリケーション層）
  ① Client Hello（対応暗号スイート一覧）
  ② Server Hello（選択暗号スイート + 証明書）
  ③ 鍵交換（ECDHE）
  ④ Finished（暗号化通信開始）
  → TLS 1.3: 1 RTT（TLS 1.2は2 RTT）
  → 所要時間: 約100ms

Phase 4: HTTPリクエスト送信（アプリケーション層）
  GET /users HTTP/2
  Host: api.example.com
  Authorization: Bearer eyJhbGciOiJSUzI1NiI...
  Accept: application/json

Phase 5: レスポンス受信
  HTTP/2 200 OK
  Content-Type: application/json
  Content-Encoding: br
  Content-Length: 2048

  [JSON データ]

Phase 6: TCP接続維持（Keep-Alive）
  → HTTP/2: 1つのTCP接続で複数リクエストを多重化
  → 次のリクエストはPhase 2-3をスキップ

合計レイテンシ（初回リクエスト）:
  DNS:        50ms
  TCP:       150ms
  TLS:       100ms
  HTTP往復:  100ms
  ──────────────
  合計:      約400ms（東京-US間）

10.2 コンテナネットワーキングとOSIモデル

Docker/Kubernetesでのネットワークモデルの適用:

Dockerの場合:

層の対応:
    L2: docker0 ブリッジ（仮想スイッチ）
    L3: IPアドレスの割り当て、NAT
    L4: ポートマッピング（-p 8080:80）
    L7: コンテナ内のアプリケーション

Kubernetesの場合:
  Pod間通信:
    → CNI（Container Network Interface）プラグインが制御
    → Calico: L3ルーティングベース（BGP使用）
    → Cilium: eBPFベース（カーネルレベルで高速処理）
    → Flannel: VXLAN オーバーレイ

  Service:
    → ClusterIP: L4ロードバランシング（kube-proxy/iptables）
    → NodePort: 全ノードの特定ポートを公開
    → LoadBalancer: クラウドのL4/L7 LBと統合

  Ingress:
    → L7ロードバランシング
    → URL パスベースのルーティング
    → TLS 終端
    → 例: nginx-ingress, traefik, istio-gateway

10.3 マイクロサービスにおけるネットワーク

マイクロサービスアーキテクチャでの各層の関わり:

サービスメッシュ（Istio/Linkerd）:

サイドカーが提供する機能:
    L4: TCP接続の管理、接続プーリング
    L7: リトライ、タイムアウト、サーキットブレーカー
    L7: mTLS（サービス間のTLS認証）
    L7: トレーシング（分散トレーシングのヘッダー伝播）
    L7: メトリクス収集（リクエスト数、レイテンシ）

通信パターンと層:
  同期通信:
    gRPC (L7/HTTP/2): マイクロサービス間RPC
    REST (L7/HTTP): 外部API公開

  非同期通信:
    Kafka (L7/TCP): イベント駆動
    RabbitMQ (L7/AMQP): メッセージキュー
    NATS (L7/TCP): 軽量メッセージング

11. プロトコルスタックの実装

11.1 Linuxカーネルのネットワークスタック

Linuxでのパケット処理フロー（受信時）:

  NIC（物理層/L1）
    ↓ DMA でパケットをメモリにコピー
  デバイスドライバ（データリンク層/L2）
    ↓ sk_buff 構造体を作成
    ↓ NAPI（割り込みの最適化）
  netfilter/iptables（L3-L4）
    ↓ PREROUTING チェーン
  IPレイヤー（ネットワーク層/L3）
    ↓ ルーティング判断（ローカル配信 or フォワード）
    ↓ INPUT チェーン（ローカル宛の場合）
  TCPレイヤー（トランスポート層/L4）
    ↓ ソケットバッファにデータを格納
  アプリケーション（アプリケーション層/L7）
    ↓ read()/recv() でデータを取得

  カーネルパラメータ（チューニング可能なポイント）:
    # TCP バッファサイズ
    net.core.rmem_max = 16777216        # 受信バッファ最大値
    net.core.wmem_max = 16777216        # 送信バッファ最大値
    net.ipv4.tcp_rmem = 4096 87380 16777216  # TCP受信バッファ
    net.ipv4.tcp_wmem = 4096 65536 16777216  # TCP送信バッファ

    # TCP接続管理
    net.ipv4.tcp_max_syn_backlog = 4096  # SYNキューサイズ
    net.core.somaxconn = 4096            # LISTENバックログ
    net.ipv4.tcp_fin_timeout = 30        # FIN_WAIT_2タイムアウト
    net.ipv4.tcp_tw_reuse = 1            # TIME_WAITソケットの再利用

    # 輻輳制御
    net.ipv4.tcp_congestion_control = bbr  # BBRアルゴリズム
    net.core.default_qdisc = fq            # Fair Queueing

確認方法:
  $ sysctl -a | grep tcp          # TCP関連パラメータ一覧
  $ cat /proc/net/tcp             # TCP接続一覧
  $ cat /proc/net/sockstat        # ソケット統計

11.2 ソケットプログラミングとOSIモデル

# Pythonでの簡単なTCPサーバー実装
# 各行がどの層に対応するかをコメントで示す
 
import socket
 
# L4: TCPソケットを作成
server = socket.socket(
    socket.AF_INET,      # L3: IPv4
    socket.SOCK_STREAM   # L4: TCP（SOCK_DGRAM ならUDP）
)
 
# L4: ポート番号をバインド
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server.bind(('0.0.0.0', 8080))  # L3: IPアドレス + L4: ポート
 
# L4: 接続待ちキューのサイズを設定
server.listen(128)
 
while True:
    # L4: TCP 3-way Handshake が完了した接続を受け入れ
    client, addr = server.accept()
    print(f"Connection from {addr}")  # (IPアドレス, ポート)
 
    # L7: アプリケーションデータの送受信
    data = client.recv(4096)  # 受信
 
    # L7: HTTPレスポンスの構築
    response = (
        "HTTP/1.1 200 OK\r\n"
        "Content-Type: text/plain\r\n"
        "\r\n"
        "Hello, World!"
    )
    client.send(response.encode())  # 送信
 
    # L4: TCP接続の切断（4-way Handshake）
    client.close()

// Goでの簡単なTCPサーバー実装
 
package main
 
import (
    "fmt"
    "net"
    "io"
)
 
func main() {
    // L3+L4: TCP/IPv4でLISTEN
    listener, err := net.Listen("tcp", ":8080")
    if err != nil {
        panic(err)
    }
    defer listener.Close()
 
    for {
        // L4: 接続受け入れ
        conn, err := listener.Accept()
        if err != nil {
            continue
        }
 
        // 並行処理
        go handleConnection(conn)
    }
}
 
func handleConnection(conn net.Conn) {
    defer conn.Close()
 
    // L7: データの読み取り
    buf := make([]byte, 4096)
    n, err := conn.Read(buf)
    if err != nil && err != io.EOF {
        return
    }
 
    fmt.Printf("Received: %s\n", buf[:n])
 
    // L7: レスポンス送信
    response := "HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nHello from Go!"
    conn.Write([]byte(response))
}

12. 現代のプロトコルとモデルの進化

12.1 従来のモデルに収まらないプロトコル

QUIC（HTTP/3の基盤）:
  従来: HTTP/2 → TLS → TCP → IP
  QUIC:  HTTP/3 → QUIC(TLS内蔵) → UDP → IP

  OSIモデルでの位置づけが曖昧:
    → UDPの上に構築（L4の上のL4？）
    → TLSを内蔵（L6の機能をL4に統合？）
    → ストリーム多重化（L5の機能？）
  → 厳密な層分けが困難 = モデルの限界

WebRTC:
  ブラウザ間のP2P通信
  → STUN/TURN（NAT越え）
  → DTLS（暗号化）
  → SRTP（メディア転送）
  → SCTP（データチャネル）
  → 複数の層にまたがる複合プロトコル

eBPF/XDP:
  Linuxカーネル内でパケットを超高速処理
  → NICドライバレベル（L1-L2）でパケットをフィルタ
  → カーネルのネットワークスタックをバイパス
  → 従来の層構造とは異なるアプローチ
  → Cilium（Kubernetes CNI）で実用化

Service Mesh（Istio/Envoy）:
  L7プロキシがL4-L7の機能を提供
  → 従来のOSIモデルでは整理しきれない
  → 「レイヤー7.5」と呼ぶ人もいる

12.2 ゼロトラストネットワーキング

従来のネットワークセキュリティ:
  「境界型防御」= ファイアウォールの内側は信頼
  → L3/L4のアクセス制御が中心

ゼロトラストの考え方:
  「何も信頼しない」= 全通信を検証
  → L7レベルでの認証・認可が必須

  実装のポイント:
    ① アイデンティティベースのアクセス制御
       → IPアドレスではなくユーザー/サービスIDで認証
    ② マイクロセグメンテーション
       → ワークロード単位でのネットワーク分離
    ③ 暗号化の徹底
       → 社内ネットワークでもTLS必須（mTLS）
    ④ 継続的な検証
       → 接続後も定期的に認証を再実行

  技術スタック:
    BeyondCorp（Google）: L7アクセスプロキシ
    Tailscale/WireGuard: L3暗号化VPN
    Istio/Linkerd: L7サービスメッシュ（mTLS）
    SPIFFE/SPIRE: ワークロードアイデンティティ

13. 資格試験で問われるポイント

CCNA（Cisco Certified Network Associate）:
  OSIモデルの各層の役割と代表プロトコル
  カプセル化/非カプセル化のプロセス
  各層のPDU名称
  ネットワーク機器と動作する層
  ルーターとスイッチの違い（L3 vs L2）

CompTIA Network+:
  OSI 7層モデルとTCP/IP 4層モデルの比較
  各層のプロトコルとポート番号
  トラブルシューティングの層別アプローチ

AWS Solutions Architect:
  VPCの設計（L3: サブネット、ルーティング）
  Security GroupとNetwork ACL（L3-L4）
  ALB vs NLB（L7 vs L4ロードバランシング）
  CloudFront（L7: CDN）

よくある試験問題例:
  Q: データリンク層で使用されるアドレスは？
  A: MACアドレス

  Q: ルーターが動作する層は？
  A: ネットワーク層（L3）

  Q: HTTPが属する層は？
  A: アプリケーション層（L7）

  Q: TCPのPDUは？
  A: セグメント

  Q: カプセル化でヘッダーが追加される順序は？
  A: L7→L4（TCPヘッダー）→L3（IPヘッダー）→L2（Ethernetヘッダー）

14. FAQ（よくある質問）

FAQ 1: OSI 7層モデルとTCP/IP 4層モデルの対応関係は？

Q: OSI 7層モデルとTCP/IP 4層モデルはどのように対応しているのか？

A: TCP/IPモデルはOSIモデルを簡略化した実用モデルである。

対応関係:

重要な違い:
  ・OSI: 理論モデル（ISO標準）
  ・TCP/IP: 実装モデル（インターネット標準）
  ・TCP/IPではL5-L7を明確に分離せず、アプリケーションに任せる
  ・実務ではOSIの層番号でL3/L4/L7と呼ぶことが多い

FAQ 2: なぜOSIモデルを学ぶ必要があるのか？

Q: 実際にはTCP/IPが使われているのに、なぜOSIモデルを学ぶのか？

A: 以下の理由により、OSIモデルは依然として重要である。

1. 共通言語としての価値:
   ・「L3スイッチ」「L7ロードバランサー」など、
     業界全体でOSIの層番号を使って機器や機能を分類する
   ・ネットワークエンジニア間の意思疎通に不可欠

2. トラブルシューティングの枠組み:
   ・問題を層別に切り分けることで、原因特定が容易になる
   ・「L1の問題（ケーブル断線）」「L3の問題（ルーティング）」
     「L7の問題（アプリケーションエラー）」など

3. 技術の理解:
   ・各層の責務を理解することで、新しいプロトコルや技術の
     位置付けが把握しやすくなる
   ・「QUICはL4とL7の中間的な存在」といった議論が可能に

4. 資格試験での必須知識:
   ・CCNA、CompTIA Network+などの資格試験で必須
   ・ベンダー中立的な理論として出題される

実務的アドバイス:
  ・OSIモデルで概念を理解し、
    TCP/IPモデルで実装を理解する
  ・両方のモデルを使い分けられるようになることが理想

FAQ 3: カプセル化の仕組みを具体的に教えてほしい

Q: データがネットワークを通る際のカプセル化とは何か？

A: カプセル化とは、上位層のデータに下位層のヘッダーを
   順次追加していくプロセスである。

具体例（HTTPリクエストの送信）:

  L7（アプリケーション層）:
    HTTPリクエスト:
      GET /index.html HTTP/1.1
      Host: example.com
    → これが「データ」

  L4（トランスポート層）:
    TCPヘッダーを追加:
      [TCPヘッダー | HTTPリクエスト]
      ↑
      送信元ポート: 54321
      宛先ポート: 80
      シーケンス番号: 1000
      など

  L3（ネットワーク層）:
    IPヘッダーを追加:
      [IPヘッダー | TCPヘッダー | HTTPリクエスト]
      ↑
      送信元IP: 192.168.1.100
      宛先IP: 93.184.216.34
      TTL: 64
      など

  L2（データリンク層）:
    Ethernetヘッダーとトレーラーを追加:
      [Ethヘッダー | IPヘッダー | TCPヘッダー | HTTPリクエスト | FCS]
      ↑                                                        ↑
      送信元MAC: aa:bb:cc:dd:ee:ff                           誤り検出
      宛先MAC: 11:22:33:44:55:66

  L1（物理層）:
    電気信号/光信号に変換して送信

受信側では逆のプロセス（非カプセル化）:
  L1 → L2（FCS検証）→ L3（TTL減算、宛先IP確認）
  → L4（ポート確認、ACK送信）→ L7（HTTPリクエスト処理）

各層は自分の層のヘッダーのみを解釈し、
上位層のデータは「中身を見ないペイロード」として扱う。
これが階層化の利点である。

FAQ

Q1: このトピックを学ぶ上で最も重要なポイントは何ですか？

実践的な経験を積むことが最も重要です。理論だけでなく、実際にコードを書いて動作を確認することで理解が深まります。

Q2: 初心者がよく陥る間違いは何ですか？

基礎を飛ばして応用に進むことです。このガイドで説明している基本概念をしっかり理解してから、次のステップに進むことをお勧めします。

Q3: 実務ではどのように活用されていますか？

このトピックの知識は、日常的な開発業務で頻繁に活用されます。特にコードレビューやアーキテクチャ設計の際に重要になります。

まとめ

TCP/IPモデルとの対応:

次に読むべきガイド

参考文献

1. Tanenbaum, A. "Computer Networks." 6th Ed, Pearson, 2021.
2. RFC 1122. "Requirements for Internet Hosts." IETF, 1989.
3. Kurose, J. & Ross, K. "Computer Networking: A Top-Down Approach." 8th Ed, Pearson, 2021.
4. Stevens, W. R. "TCP/IP Illustrated, Volume 1." 2nd Ed, Addison-Wesley, 2011.
5. RFC 9293. "Transmission Control Protocol (TCP)." IETF, 2022.
6. ISO/IEC 7498-1. "Information technology — Open Systems Interconnection — Basic Reference Model." ISO, 1994.
7. Comer, D. "Internetworking with TCP/IP, Volume 1." 6th Ed, Pearson, 2015.
8. Fall, K. & Stevens, W. R. "TCP/IP Illustrated, Volume 1: The Protocols." 2nd Ed, Addison-Wesley, 2011.