マルチキャストとは？
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)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 サンプル（再掲 + コメント詳細）
# 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()}')
# 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)
実行：
$ 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. よくある落とし穴 & ベストプラクティス
-
Wi‑Fi 親機がマルチキャストを低速レートで送る → AP 設定で
Multicast-to-UnicastやIGMP Snoopingを有効化。 -
家庭用ルータは PIM 非対応 → OpenWRT +
igmpproxyで簡易ブリッジ可。 - OS ファイアウォールが UDP:5000 を遮断 → Windows Defender の受信規則を追加。
- IGMP Snooping 未対応スイッチでストーム → ハブ的製品は要注意。スヌーピング対応機へ交換。
- 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 への移行計画を学ぶと実務力が飛躍的にアップします。