概述

       網絡信息傳輸主要有4種方式：單播（unicast）、任播（anycast）、組播（multicast）和廣播（broadcast）。廣播和組播為應用程序提供了兩種服務：數據分組交付至多個目的地，通過客戶端請求/發現服務器。

        ·交付至多個目的地。有許多應用程序將信息交付至多個收件方，例如，互動式會議、郵件或新聞分發至多個收件方。沒有廣播或組播，這些類型的服務只能將一個單獨的副本交付至每一個目的地，這是非常低效的。

       ·通過客戶端請求/發現服務器。使用廣播或組播，應用程序可以向一個服務器發送一個請求，而不用知道任何特定服務器的IP地址。當本地網絡環境的信息了解得很少時，這種功能在網絡配置過程中非常有用。例如嵌入式系統通過DHCP獲取其初始IP地址、ARP、IPv6 ND等。

       雖然廣播和組播都可以提供上述功能，但組播相對于廣播來說更為高效。因為組播只涉及那些支持或使用特定服務或協議的系統，而廣播不是。因此，一個廣播請求會影響在廣播域內所有可以到達的主機，而組播只影響那些可能對該請求“有興趣”的主機。在廣播的更高開銷和簡單性以及組播的效率改善和更復雜性之間存在一種平衡。

廣播

       廣播是指將報文發送到網絡中的所有可能的接收者。從原理上這很容易實現：路由器簡單地將它接收到的任何廣播報文副本轉發到除該報文到達的接口以外的每個接口。當多臺主機連接到同一個局域網時，廣播還能結合鏈路層特點提供相對更高效的轉發策略。

廣播地址

       在IPv4中，每個子網都有一個本地定向子網廣播地址，它是通過將地址中的主機部分全部置1形成的，特殊地質255.255.255.255對應于本地網絡廣播（也叫有限廣播）。

       例如，設備eth0的IP地址為172.16.0.15，子網掩碼為255.255.240.0，所以網絡前綴為172.16.0.0/20。因此廣播地址即為該地址的主機部分的32-20=12位的1相結合（或運算）得到的：172.16.0.0 | 0.0.15.255 = 172.16.15.255

組播

       為了減少在廣播中涉及的不必要的開銷，可以只向特定的一部分接收方（可以是域內也可以是域間）發送流量，這被稱為組播。從根本上說，通過發送方指明接收方，或是通過接收方獨立地指明它們的“興趣”，就可以完成這項工作。然后網絡只負責向預期的或感興趣的收件方發送流量。實現組播比廣播要復雜，因為組播狀態（multicast state）（信息）必須由主機和路由器來保持，以說明哪些接收方對哪類流量感興趣。這個信息作為主機和路由器中的軟狀態來維持，這意味著它必須定期更新（當這種情況發生時，組播流量的交付要目停止要目恢復為廣播）。如果正確地使用組播，只有那些在通信中參與或感興趣的主機需要處理相關的分組，流量只會被承載于它將被使用的鏈路上，并且只有任意組播數據報的一個副本被承載于這樣的鏈路上。

       為了使組播工作，希望參與通信的應用程序需要一種機制來發布其意愿的協議實現。然后主機軟件可以安排接收與應用程序的條件相匹配的分組。

ASM和SSM

       IP組播在諸如以太網的鏈路層網絡中，起初使用一種基于組尋址工作方式的設計。在這種方法中，每個站點選擇它愿意接收流量的組地址，而不考慮發送方。因為對于發送方的身份是不敏感的，所以這種方法有時也被稱為任源組播（Any Source Multicast，ASM）。而對于發送方身份敏感的組播類型被稱為特定源組播（Source Specific Multicast，SSM），它允許終端站點明確地包含或排除從一組特定發送方發送到一個組播組的流量。SSM服務模型比ASM更容易實現，這主要是因為在廣播組域中，確定單個源的位置比確定多個源的位置更容易。

IP組播地址轉換為IEEE 802地址

       在類似以太網的網絡中，使用單播地址時，通常根據目的地的IPv4地址確定其MAC地址，而在IPv6中則是由鄰居發現協議（ND）來承擔類似工作。在廣播中，一個MAC地址可以用于達到一個或上的所有站點。那么組播中應該如何確定何種MAC地址應該放置于鏈路層幀中呢？理想的情況下，我們不必使用協議報文來確定適當的MAC地址，而是簡單地將一個IP組播地址直接映射到一些對應的MAC地址。這些網絡代表了使用IP組播的最常見的網絡類型，具體映射方法在IPv4和IPv6中略有不同。

IPv4組播映射

       為了在鏈路層網絡中有效承載IP組播，在IP層和鏈路層幀的數據分組和地址之間應該有一個一對一的映射。IANA擁有組播地址空間（具體為224.0.0.0~239.255.255.255），且IANA還擁有IEEE組織唯一標識符（OUI，或稱以太網地址前綴）01:00:5e。有了它，IANA就被賦予權限去使用以01:00:5e開始的組（組播）MAC地址以及以00:00:5e開始的單播MAC地址。因此單播地址范圍為00:00:5e:00:00:00~00:00:5e:ff:ff:ff，組播地址范圍為01:00:5e:00:00:00~01:00:5e:ff:ff:ff。

       在組播地址中最高的4位固定為1110，因此有32-4=28位可用來編碼整個地址空間。對于IPv4，IANA分配一半的組地址用于支持IPv4組播，這以為這2^27=268435456個組播組ID需要被映射到只有2^23=8388608個用于組播的鏈路層地址空間，因此映射是非唯一的，即有多個IPv4組播地址唄映射到相同的組播MAC地址中。IPv4組地址到組MAC地址的映射例子如下圖所示：

IPv6組播映射

       對于IPv6，16位的OUI十六進制前綴是33:33。這意味著，IPv6地址的最后32位可以用來形成鏈路層地址。映射的例子如下圖所示：

       由于只使用了112個組播地址位中的32位，所有有2^80個IPv6組播地址映射到相同的MAC地址。

組播地址過濾

       在一個典型的交換式以太網環境中，廣播和組播幀沿著在交換機之間形成的一顆生成樹在VLAN中的所有段被復制。這樣的幀被交付到每臺主機上的網絡接口卡（NIC），它將會檢查幀的正確性。若是單播/任播幀，NIC值接收目的地址是接口的硬件地址或廣播地址的那些幀。然而當設計組播幀時情況要更復雜。

       NIC往往有兩類。一類執行基于組播硬件地址的散列值的過濾，主機的應用軟件可以表達對該硬件地址的興趣。但正如前面組播映射特點所述，映射是多對一的，這意味著散列沖突，一些不需要的幀總是可以通過。另一類偵聽組播地址的一張有限表，這意味著，如果主機需要接收超過表中能夠容納的更多的組播地址的幀，NIC將進入一種“組播混雜”模式。在這種模式下，所有的組播流量將會交給上層軟件。因此，兩種類型的接口需要設備驅動程序或高層軟件執行檢查，以確定接收到的幀是否真的需要，因此NIC的只是初步過濾。盡管存在不完美的地址映射和硬件過濾，組播地址仍然比廣播更高效。

       NIC進行初步過濾后，設備驅動程序將幀傳遞到下一層。例如，如果幀類型指定一個IP數據報，則為IP層。基于源IP地址和目的IP地址，IP層進行更多的過濾。并將過濾出來的幀傳遞到下一層（傳輸層，如TCP或UDP）進行下一步過濾。