單元 06 單播、廣播與多播：LAN 內的交付
學習目標與問題
先讀 04 的子網與下一跳、05 的交換表、ARP 與 VLAN。本單元只看一個 IPv4 廣播域內的交付：先分單播、廣播與多播的語義，再看交換器依 FDB、MDB 與 router port 決定的實際出口。完成後應能追蹤不同交付方式、區分 FDB 與 MDB，並解釋 IGMP、snooping 與 querier 的分工。IPv6 多播、跨網段多播與服務探索留到 15。
本文以「多播」稱 multicast，其他資料也常稱群播或組播。問題：交換器看到多播訊框，是否一定送到所有主機？
6.1 先分交付語義，再看實際出口
| 類型 | 目的與範圍 | 交換器簡化行為 |
|---|---|---|
| 已知單播 | 一個鏈路目的 MAC | FDB 命中時送目的埠 |
| 未知單播 | 目的仍是單播 MAC | FDB 未命中時，同 VLAN 泛洪 |
| 廣播 | ff:ff:ff:ff:ff:ff | 同 VLAN 可轉送埠，排除入口 |
| 多播 | 一個群組，可能零／一／多個接收者 | 依成員、router port 及裝置政策決定 |
上表假設無埠隔離、ACL、鏡像及特殊控制訊框規則。泛洪是交換器的轉送動作，不會把單播目的改成廣播。接收端收到鏈路副本，也不表示 IP／socket 或應用一定接受。
IPv4 有限廣播 255.255.255.255 限制在本鏈路；子網導向廣播如 192.0.2.255/24 的語義不同，路由器預設不應轉送這類導向廣播。不要為了跨網段探索直接開啟廣播轉送。
ARP 請求通常用 Ethernet 廣播；但 ARP 本身不是 IP 資料報（EtherType 0x0806），既不是 IPv4 廣播也不是 IPv4 多播。IPv6 的對應機制見 14、15。
6.2 IP 群組與鏈路 MAC 不是一對一
IPv4 多播範圍 224.0.0.0/4；224.0.0.0/24 供本地網路控制，239.0.0.0/8 供管理範圍，實際邊界仍需路由與管理政策。
Ethernet 上的 IPv4 多播 MAC 使用 01:00:5e 加上群組 IP 的低 23 bits，所以 32 個 IPv4 群組可以對映到同一 MAC。239.192.0.42 與 224.64.0.42 皆對映到 01:00:5e:40:00:2a；若設備只按 MAC 過濾，可能多送副本，IP 層仍需按群組過濾。
Socket 是程式使用網路服務的介面，UDP 以資料報收送，細節見 09。多播發送者不必先加入接收群組；接收者透過 socket 加入指定介面的群組。群組不是可直接建立普通 TCP 連線的單一伺服器。多播資料常用 UDP，但管理封包 IGMP 或 ICMPv6 本身不使用 UDP 埠；不能將「多播只有 UDP」當成分層定義。
6.3 成員管理、snooping 與路由三種工作
| 機制 | 知道什麼 | 負責什麼 |
|---|---|---|
| FDB 來源學習 | VLAN、來源 MAC、入口埠 | 單播鏈路轉送 |
| IGMP（IPv6 為 MLD） | 某鏈路有接收者對哪些群組／來源有興趣 | 主機向相鄰多播路由器報告 |
| IGMP snooping、MDB | 群組對應成員埠，另記 router port | 交換器限制 LAN 內多播副本 |
| 多播路由／PIM 等 | 跨鏈路的樹、上游與下游 | 路由器跨子網轉送多播；見 15 |
一次成員生命週期
- B 的應用在指定介面加入群組 G；OS 更新接收狀態，依協定發送成員報告。
- snooping 交換器從控制訊息更新 B 所在埠的 MDB 狀態；router port 另由協定觀察或靜態設定取得。
- C 送 G 的資料；已知群組通常送成員埠與相關 router port，排除入口，不查普通單播 FDB 來找全部成員。
- Querier 發 Query，接收者回報仍需哪些流量；表項會依時間與規則更新。
- 應用 leave 或停止回報，不一定瞬間刪掉整個埠：埠後方可能還有其他接收者，需查詢／逾時或明確追蹤。Fast leave 只適合符合拓樸假設的部署。
沒有 querier 時，某些 snooping 環境會在老化後丟失成員狀態，呈現「剛開始正常，幾分鐘後不穩」。不同設備可能退回泛洪或丟棄；不能把症狀當唯一診斷。查 Query、Report、MDB、router port 與計時器才有證據。
未知多播是否泛洪取決於設備與政策；router port、控制群組及版本相容性也會影響轉送。IPv4 的 224.0.0.x 非 IGMP 資料在 RFC 4541 建議下應送所有相關埠，不能一律按普通群組的 MDB 裁切。因此「開 snooping 後 mDNS 只到已加入者」不是通用保證。mDNS 是本鏈路名稱探索，見 15。
6.4 完整轉送例題
A、B、C、R 在 VLAN 10 的埠 1、2、3、4；D 在 VLAN 20 的埠 5。G=239.192.0.42，MDB 已知 B 與 C 是成員，R 是 router port；無其他過濾。這次改由成員 C 從埠 3 送出，FDB 已知 A 在埠 1。
| C 傳入埠 3 的訊框 | 出口 | 判斷 |
|---|---|---|
| 已知單播 A | 1 | FDB 命中 |
| 未知單播 X | 1、2、4 | 同 VLAN 泛洪，目的仍單播 |
| 廣播 | 1、2、4 | 不送 VLAN 20 |
| 已知 G 多播 | 2、4 | 成員埠加 router port，排除入口 3 |
| B 離開後的 G，假設成員移除已確認 | 4 | 不再送 2，仍送 router port |
| mDNS 224.0.0.251 | 本例 1、2、4 | link-local 控制範圍採泛洪政策 |
這是明示政策的紙上模型，並非所有交換器的逐條保證。IGMP 控制訊息有自己的轉送規則，不以此資料訊框表替代規範。
實驗、習題與檢核
做 L16 階段一的其餘部分：A 的六個多播案例與 B1–B4。前三案已在 05 完成，沿用原紀錄，不重做，和本階段一起評分。改變 MDB、成員老化、router port、VLAN 與未知多播政策時，先預測再執行；B1、B3 用手冊列出的參數重跑，不必改程式。習題 2 先手算推理，再用 B4 核對，理由只在 B4 寫一次。D 延伸（選做）觀察 FDB、MDB、router port、querier 與 IGMP Query／Report。B5、C 與 D 的 UDP 5353、IPv6 檢查屬階段二，讀完 15 再做。Linux bridge 觀察是延伸，未列為本機實測。
- 基本：未知單播送到多埠，為何仍不是廣播？
- 基本：239.192.0.42 與 224.64.0.42 為何可能共用 MAC？它們是否因此是同一群組？先手算，再用 L16 B4 核對；理由寫在 B4，只交一次。
- 基本：snooping 與 querier 各解決哪個問題？
- 分析：B 離開群組時，為何不能立即刪除整個共享埠？
檢核：能分開記錄目的 IP／MAC、VLAN、FDB、MDB 與 router port；知道本模型未實作 IGMP 封包。
來源（查閱 2026-10-06）：RFC 1112、RFC 2365、RFC 2644、RFC 9776 IGMPv3、RFC 4541 snooping、Linux bridge。RFC 4541 為 Informational 建議，不代替每款交換器的規格。