#0152（2025/05/25）マルチキャストとは？

# マルチキャストとは？

## 0. モチベーション

あなたのアプリが 1000 台のクライアントへ毎秒 3 Mbps のデータを流すとき、**ユニキャストなら 3 Gbps** をサーバが吐き続けなければなりません。マルチキャストを使えば **1 本 3 Mbps** で済みます。ところが *“ルーターを越えない”* だの *“IGMP が必要”* だの敷居が高く感じて手を出せない……。本稿はそんなエンジニア向けに、**概念 → プロトコル → コード → 設計 → 運用** の層で一気に腹落ちさせる解説を目指します。

---

## 1. 三つの通信モデルを一枚図で俯瞰

```
┌────────────┐       ┌───────────────┐
│  ユニキャスト│       │ブロードキャスト  │
│  192.0.2.1 │────→  │255.255.255.255│ (全端末)
└────────────┘       └───────────────┘
         │                         ▲
         ▼                         │
┌──────────────────────────────────────────┐
│      マルチキャスト 239.1.1.1 (group)       │
└──────────────────────────────────────────┘
```

|            | ユニキャスト         | ブロードキャスト                       | **マルチキャスト**                               |
| ---------- | -------------- | ------------------------------ | ----------------------------------------- |
| **対象**     | 1 対 1          | 同セグメント全員                       | **任意参加者**                                 |
| **IP 範囲**  | グローバル / プライベート | `255.255.255.255`, `n.n.n.255` | `224.0.0.0/4` (IPv4)<br>`ff00::/8` (IPv6) |
| **ルーター越え** | ○ 普通にルーティング    | ✕ 基本遮断                         | **○ PIM/IGMP Proxy があれば**                 |
| **帯域効率**   | N 受信で N 倍      | 1 送信だが全端末が処理                   | **1 送信 / 参加端末のみ処理**                       |
| 主な用途       | Web, API       | ARP, DHCP DISCOVER             | IPTV, 金融ティッカー, e‑Learning                 |

**要点:** 送信データがまったく同一かつ受信者数が多いとき → マルチキャスト一択。

---

## 2. プロトコル分解図

```
┌────────────────────────────┐
│ アプリ            Zoom/FFmpeg/自作UDP │
├──────────────┬─────────┬─────────┤
│ Transport層   │ UDP      │ TCP(SRM*)│
├──────────────┴─────────┴─────────┤
│      IP層       Multicast IP (224.x / ff0x::)  │
├────────────────────────────────────────┤
│ IGMP/MLD      参加・離脱をルータへ通達     │
├────────────────────────────────────────┤
│ PIM-SM/SSM   ルータ間で配信ツリーを生成     │
└────────────────────────────────────────┘
```

\*SRM = Scalable Reliable Multicast (TCP類似の再送をアプリ側で実装)

* **IGMPv2/v3** (IPv4) / **MLDv2** (IPv6) … 端末↔ルータの *Listenership* 手続。
* **PIM‑SM** … Rendezvous Point(RP) を中心に共有ツリー ⇒ 最適化でSPTへ。
* **SSM (232/ff3x::)** … 送信者 IP も含めて購読。セキュリティと迷惑パケット対策が容易。

---

## 3. ハンズオン：5 分で動く最小構成

### 3‑1 ネットワーク要件

* 同一サブネット、TTL=1、家庭用 Wi‑Fi でも OK。
* Windows の場合は `EnableMulticastLoopback` をレジストリで有効にすると同一 PC 上で受信確認可。

### 3‑2 Python サンプル（再掲 + コメント詳細）

```python
# receiver.py  (Python 3.8+)
import socket, struct, sys
GROUP = '239.255.0.1'; PORT = 5000
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
# 1) 複数プロセスが同ポートをバインドできるように
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 2) すべてのローカルIPで受信
sock.bind(('', PORT))
# 3) IGMP Join (INADDR_ANY で任意NIC)
mreq = struct.pack('4sl', socket.inet_aton(GROUP), socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
print('Join OK -> waiting...')
while True:
    data, addr = sock.recvfrom(2048)
    print(f'[{addr[0]}] {data.decode()}')
```

```python
# sender.py
import socket, time
GROUP = '239.255.0.1'; PORT = 5000
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
# TTL=1 → ルータを越えない（実験用途）。企業WANなら 5～32 に。
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 1)
msg_id = 0
while True:
    payload = f'MCast {msg_id}'.encode()
    sock.sendto(payload, (GROUP, PORT))
    print('→', payload.decode())
    msg_id += 1; time.sleep(1)
```

実行：

```bash
$ python3 receiver.py   # PC A や同一PC別ターミナル
$ python3 sender.py     # PC B または同一PC
```

**複数端末**で `receiver.py` を起動すると、*同じメッセージが同時に表示* されることを確認。

> 🎯 **学びポイント**: IGMP Join/Leave を Wireshark `igmp` フィルタで眺めると理解が加速。

---

## 4. ユースケース詳細

### 4‑1 映像ストリーミング (IPTV, e‑Learning)

* **要求**: 数百〜数万同時視聴。低遅延。帯域節約。
* **構成**: 送信サーバ → PIM‑SM → 拠点 RP → 教室 or 社内端末。
* **注意**: 大学や企業 WAN は PIM‐DM より SM。QoS マーク(DSCP 46)を付け、下流スイッチで Policing。

### 4‑2 金融マーケットデータ

* **要求**: サブミリ秒配信。フィード分割 (A/B) + 冗長化。
* **構成**: 232.x.x.x/8 の SSM。受信側で Source Filter により迷惑トラフィック排除。
* **注意**: 障害時の IGMP Re‑Join が “ブラインドスポット” を生まないよう、Fast‑Failover(PIM‑BFD) を併用。

### 4‑3 ソフトウェア更新 (IoT・基地局)

* **要求**: 数千台へ同一 FW を一斉配布。
* **構成**: Limited TTL=5, UDP + SRM で再送制御。帯域 10 倍削減。
* **注意**: 再送制御 (NACK) をアプリ層で実装しないと個体差で失敗しがち。

---

## 5. 通信範囲と設計ガイド

### 5‑1 IPv4 (TTL)

| TTL | 想定スコープ         | 具体例            |
| --- | -------------- | -------------- |
| 1   | 同一サブネット        | 家庭用 Wi‑Fi, 教室内 |
| 5   | 拠点 LAN ⇔ 拠点ルータ | 小規模オフィス＋支店 VPN |
| 32  | 大規模企業 WAN      | 拠点が数十ホップ       |

### 5‑2 IPv6 (スコープ値)

| プレフィックス     | スコープ       | 説明                 |
| ----------- | ---------- | ------------------ |
| `ff02::/16` | Link‑Local | 1ホップのみ（ブロードキャスト代替） |
| `ff05::/16` | Site‑Local | 企業/大学サイト内部（ルータ越え可） |
| `ff0e::/16` | Global     | 実験用途。ISP を越えるケースは稀 |

**設計指針**: *「最小 TTL / スコープ」で必要最小限だけ届ける。*

---

## 6. よくある落とし穴 & ベストプラクティス

1. **Wi‑Fi 親機がマルチキャストを低速レートで送る** → AP 設定で `Multicast-to-Unicast` や `IGMP Snooping` を有効化。
2. **家庭用ルータは PIM 非対応** → OpenWRT + `igmpproxy` で簡易ブリッジ可。
3. **OS ファイアウォールが UDP:5000 を遮断** → Windows Defender の受信規則を追加。
4. **IGMP Snooping 未対応スイッチでストーム** → ハブ的製品は要注意。スヌーピング対応機へ交換。
5. **ISP を越えた配信がしたい** → CDN + HLS のほうが現実的。（インターネットマルチキャストは実質封印）

---

## 7. IPv6 とマルチキャストの関係

IPv6 ではブロードキャストが完全に廃止され、**すべての同報通信がマルチキャストで実装**されます。以下がその主な例です：

| IPv4 での動作             | IPv6 での置き換え                                 | 用途        |
| --------------------- | ------------------------------------------- | --------- |
| ARP (ブロードキャスト)        | Neighbor Discovery (ND) `ff02::1:ffXX:XXXX` | MACアドレス解決 |
| ICMP Router Discovery | Router Solicitation / Advertisement         | ルータ発見     |
| DHCP DISCOVER         | DHCPv6 Solicit                              | IPアドレス要求  |

* IPv6 のマルチキャストアドレスは `ff00::/8` に割り当てられ、Scope（到達範囲）とFlags により制御されます。
* グループ例：

  * `ff02::1` → 同一リンク上の全ホスト
  * `ff02::2` → 同一リンク上の全ルータ

また、マルチキャストグループへの参加は **IGMP の代わりに MLD（Multicast Listener Discovery）** を使って通知されます。

> IPv6ネットワークではマルチキャストは“使うかどうか”ではなく、“必ず使われる”存在です。

---

## 8. L2 ストームとは？

マルチキャストやブロードキャストが過剰に流れると、**スイッチが全ポートにパケットを複製し続け、帯域を圧迫・ネットワーク全体がフリーズする現象**が発生します。これが **L2ストーム（Layer 2 Storm）** です。

### 主なストームの種類：

| 種類               | 説明                                     |
| ---------------- | -------------------------------------- |
| **ブロードキャストストーム** | ARPなどのL2ブロードキャストが過剰発生し、スイッチ全体を圧迫       |
| **マルチキャストストーム**  | IGMPスヌーピング未対応・未設定のスイッチがマルチキャストを全ポートへ送出 |
| **フラッディングストーム**  | 宛先MACアドレスを学習していないとき、全ポートへ送る（初期ARPなど）   |

### 防止策：

* **IGMPスヌーピングの有効化**：マルチキャストトラフィックを必要なポートにだけ流す
* **スパニングツリープロトコル（STP）**：L2ループによる無限転送の防止
* **ストームコントロール機能**：一定以上のマルチキャスト/ブロードキャストを自動遮断
* **VLAN分離設計**：被害をセグメント内に局所化

> 特に Wi-Fi 環境ではマルチキャストは低速で送られるため、ストームが QoS に与える影響は甚大です。

---

## 9. まとめ & 次の学習ステップ

* **マルチキャスト = 1 対 多の帯域節約エンジン**。ブロードキャストと違い "参加者だけ" が受け取る。
* **IGMP/MLD + PIM** を理解すれば、セグメントを越えて自在に配信可能。
* **サンプルコード** でローカル実験 → **Wireshark** で Join/Leave を観察 → **24h 稼働テスト** で安定性をチェック。

### 📚 推奨ドキュメント

* RFC 1112  ▶ IPv4 マルチキャスト仕様
* RFC 2236 / 3376 ▶ IGMPv2 / IGMPv3
* RFC 4607  ▶ Source‑Specific Multicast (SSM)
* Cisco “IP Multicast Best Practices” Whitepaper

> **次の一歩**：PIM‑SM の RP 冗長化 (`auto‑RP` / `BSR`) と、SSM への移行計画を学ぶと実務力が飛躍的にアップします。