【寸劇で学ぶネットワーク】Application層 編

🎬「ナオおばあちゃん、送り状を書き上げる」

キャラクター

- 👵 ナオおばあちゃん（奈良の里山、黒飴奉納者／送り主）
- 🧒 ニューラちゃん（東京の郊外、風を読むAIの天才6歳児／受取人）
- 受付嬢：宅配便カウンターで送り状を作成する（HTTP）
- 住所録台帳係：宅配便本社の住所簿を調べる（DNS）

寸劇本文

# 寸劇 詳細編（Application 層：送り状と住所探し）

奈良の里山に暮らすナオおばあちゃん。

今年は畑のキャベツが豊作で、食べきれないほど山のように採れた。

「せっかくやから、東京のニューラ市場に送って、たくさんの人に食べてもらおうかのう」

そう思い立ったおばあちゃんは、収穫したキャベツを抱えて、里山の宅配便支店へ向かった。

---

### 1.1 送り状を書く（HTTP）

**ナオおばあちゃん**

「ほな、このキャベツを東京のニューラ市場に送ってやってくれんかの（リクエスト）」

受付嬢（HTTP）はにっこり笑い、送り状用紙を取り出した。

**受付嬢（HTTP）**

「はい、おばあちゃん。送り状を作りますね（HTTP リクエスト作成）」

差出人欄や荷物の内容はすぐに書けたが、肝心の宛先が空白のままだった。

---

### 1.2 住所を調べる（DNS 問い合わせ）

**ナオおばあちゃん**

「宛先はニューラ市場やけど、どこにあるんやったかのう？」

奥から現れたのは住所録台帳係（DNS）。分厚い帳簿を抱えている。

**住所録台帳係（DNS）**

「ご安心ください！ 全国の住所簿から探します（DNS 検索）」

その横で、腰に小さな手帳をぶら下げた手帳持ちの小僧（リゾルバ）が言った。

**手帳持ちの小僧（リゾルバ）**

「前に調べた記録がこの手帳（キャッシュ）に残っておれば、すぐ答えられますよ」

---

### 1.3 住所の階層をたどる（DNS 階層構造）

住所録台帳係（DNS）は帳簿をめくりながら説明した。

**住所録台帳係（DNS）**

「住所は階層になっとります。まずは大元の“ルート”、それから『.com』や『.jp』みたいな地域（TLD）、その下に『glasscom.com』の世帯、最後に『www』や『lab』といった家屋。順にたどれば必ず見つかります」

やがて指先が一行で止まった。

**住所録台帳係（DNS）**

「ありました！ 東京都 ◯◯ 市、ニューラ市場の所在地です！（DNS 応答）」

---

### 1.4 送り状完成（HTTP メッセージ）

受付嬢（HTTP）は宛先欄に住所を書き込み、満足げにペンを置いた。

**受付嬢（HTTP）**

「これで送り状が完成しました。次の運び手に渡せます（HTTP メッセージ完成）」

ナオおばあちゃんはキャベツの山をトントンと叩き、笑みを浮かべた。

**ナオおばあちゃん**

「ありがとさん。これで市場も助かるやろなあ」

---

### 地の文（バトンリレー）

こうしてキャベツを送る送り状が完成した。

次は、実際にキャベツをトラックに積んで出荷する **Transport 層** の出番である。

📖 Application層とは？

Application層は、**ユーザーが最初に操作する“窓口”**です。

- ナオおばあちゃん（ユーザー）が「キャベツを送りたい」とリクエストを出す
- 受付嬢（HTTP）がその注文を「送り状」にまとめる
- 住所録係（DNS）が市場の住所を調べて記入する

つまり、「送りたい」という気持ちを“送り状”に変換するのが Application層の役割です。

📝 用語解説

- **HTTP（Hypertext Transfer Protocol）**
    
    Webページやアプリがやり取りする「注文書」。リクエストやレスポンスはまずここで作成されます。
    
- **DNS（Domain Name System）**
    
    サイト名（例：neura-market.jp）を数値の住所（IPアドレス）に変換する住所録システム。
    
- **リゾルバ（Resolver）**
    
    手元のキャッシュや順番に問い合わせて、最終的にIPアドレスを見つける“探偵役”。
    
- **キャッシュ（Cache）**
    
    一度調べた住所を保存しておくメモ。次回以降の問い合わせを早くします。

Mermaid図**（構成図）**

flowchart TD

  %% =======================
  %% Application層
  %% =======================
  subgraph Application層
    A1[ナオおばあちゃん\\nキャベツ出荷を決意]
    A2[受付嬢（HTTP）\\n送り状を書く]
    A3[住所録台帳係（DNS）\\n住所検索]
    A4[手帳持ちの小僧（リゾルバ）\\nキャッシュ確認]
    A5[送り状完成_HTTPメッセージ]
    A1 --> A2 --> A3 --> A4 --> A5
  end

  %% =======================
  %% Transport層
  %% =======================
  subgraph Transport層
    T1[出荷係（TCP）\\n大口便手配]
    T2[市場の荷受担当\\nACKで確認]
    T3[倉庫管理人\\nウィンドウ制御]
    T4[軽トラ運転手（UDP）\\n臨時便]
    A5 --> T1 --> T2 --> T3
    A5 --> T4
  end

  %% =======================
  %% Internet層
  %% =======================
  subgraph Internet層
    I1[トラック（IPパケット）\\n伝票＝IPアドレス]
    I2[町内仕分け係（ARP）\\nMAC表札を調べる]
    I3[道路係（ルータ）\\n経路決定]
    I4[寿命シール（TTL）\\n寿命管理]
    I5[宅配網\\nPOP/NOC/IX/Tier1]
    I6[細分梱包係（フラグメンテーション）\\n道幅調整]
    I7[クレーム係（ICMP）\\nエラー通知]
    I8[東京市場到着]
    T2 --> I1 --> I2 --> I3 --> I4 --> I5 --> I6 --> I7 --> I8
    T4 --> I1
  end

  %% =======================
  %% Network Access層
  %% =======================
  subgraph Network Access層
    N1[表札確認係（ARP）]
    N2[宅配所の仕分けベルト\\n（スイッチングハブ）]
    N3[表札帳管理人（MACテーブル）]
    N4[町内放送係（リピーターハブ）]
    N5[交差点ルール係（CSMA/CD）]
    N6[無線の譲り合い係（CSMA/CA）]
    N7[検品係（FCS）]
    N8[ニューラ市場の玄関口]
    I8 --> N1 --> N2 --> N3 --> N7 --> N8
    N2 --> N4
    N2 --> N5
    N2 --> N6
  end

flowchart LR
  User["👩‍🦳 ユーザー（ナオおばあちゃん）"]
  App["📑 Application層（HTTP注文窓口 + DNS住所録）"]
  Trans["📦 Transport層（小箱に梱包）"]
  Net["🚚 Internet層（住所指定と道路中継）"]
  Link["🏠 Network Access層（表札と回線）"]
  Server["🏬 ニューラ市場（サーバー）"]

  User --> App --> Trans --> Net --> Link --> Server

📚 Appendix

🔹 実事例（CaseStudy）

- ブラウザでURLを入力すると → DNSがIPを返す
- HTTPリクエストが作られて → サーバーに送られる
- 結果として、ユーザーがWebページを閲覧できる

🔹 全体構成・目次

1. Application層（受付嬢と住所係）
2. Transport層（TCP配達員とUDP配達員）
3. Internet層（配送センターと警備員）
4. Network Access層（MAC兄さんとトラック）
5. クラウド応用編（仮想配送支店）

📝 まとめと次回予告