摘要：文章來自于《TCP/IP詳解》卷一第十三章。本文詳細(xì)介紹IGMP協(xié)議原理及實現(xiàn)實例。
1、引言
本文將介紹用于支持主機和路由器進行多播的Internet組管理協(xié)議（IGMP）。它讓一個物理網(wǎng)絡(luò)上的所有系統(tǒng)知道主機當(dāng)前所在的多播組。多播路由器需要這些信息以便知道多播數(shù)據(jù)報應(yīng)該向哪些接口轉(zhuǎn)發(fā)。IGMP在RFC 1112中定義[Deering 1989].
正如ICMP一樣， IGMP 也被當(dāng)作IP 層的一部分。IGMP報文通過IP數(shù)據(jù)報進行傳輸。不像我們已經(jīng)見到的其他協(xié)議， IGMP有固定的報文長度，沒有可選數(shù)據(jù)。圖13-1顯示了IGMP報文如何封裝在IP數(shù)據(jù)報中。
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖一）
IGMP報文通過IP首部中協(xié)議字段值為2來指明。
2、 IGMP報文
圖1 3 - 2顯示了長度為8字節(jié)的IGMP報文格式。
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖二）
這是版本為1的IGMP.IGMP類型為1說明是由多播路由器發(fā)出的查詢報文，為2說明是主機發(fā)出的報告報文。檢驗和的計算和ICMP協(xié)議相同。
組地址為D類IP地址。在查詢報文中組地址設(shè)置為0，在報告報文中組地址為要參加的組地址。在下一節(jié)中，當(dāng)介紹IGMP如何操作時，我們將會更詳細(xì)地了解它們。
3、 IGMP 協(xié)議
3.1 加入一個多播組
多播的基礎(chǔ)就是一個進程的概念（使用的術(shù)語進程是指操作系統(tǒng)執(zhí)行的一個程序），該進程在一個主機的給定接口上加入了一個多播組。在一個給定接口上的多播組中的成員是動態(tài)的—它隨時因進程加入和離開多播組而變化。
這里所指的進程必須以某種方式在給定的接口上加入某個多播組。進程也能離開先前加入的多播組。這些是一個支持多播主機中任何API所必需的部分。使用限定詞“接口”是因為多播組中的成員是與接口相關(guān)聯(lián)的。一個進程可以在多個接口上加入同一多播組。
Stanford大學(xué)伯克利版Unix中的IP 多播詳細(xì)說明了有關(guān)socket API的變化，這些變化在Solaris 2.x和ip（7）的文檔中也提供了。
這里暗示一個主機通過組地址和接口來識別一個多播組。主機必須保留一個表，此表中包含所有至少含有一個進程的多播組以及多播組中的進程數(shù)量。
3.2 IGMP 報告和查詢
多播路由器使用IGMP報文來記錄與該路由器相連網(wǎng)絡(luò)中組成員的變化情況。使用規(guī)則如下：
1） 當(dāng)?shù)谝粋€進程加入一個組時，主機就發(fā)送一個IGMP報告。如果一個主機的多個進程加入同一組，只發(fā)送一個IGMP報告。這個報告被發(fā)送到進程加入組所在的同一接口上。
2） 進程離開一個組時，主機不發(fā)送IGMP報告，即便是組中的最后一個進程離開。主機知道在確定的組中已不再有組成員后，在隨后收到的IGMP查詢中就不再發(fā)送報告報文。
3） 多播路由器定時發(fā)送IGMP查詢來了解是否還有任何主機包含有屬于多播組的進程。多播路由器必須向每個接口發(fā)送一個IGMP查詢。因為路由器希望主機對它加入的每個多播組均發(fā)回一個報告，因此IGMP查詢報文中的組地址被設(shè)置為0.
4） 主機通過發(fā)送IGMP報告來響應(yīng)一個IGMP查詢，對每個至少還包含一個進程的組均要發(fā)回IGMP報告。
使用這些查詢和報告報文，多播路由器對每個接口保持一個表，表中記錄接口上至少還包含一個主機的多播組。當(dāng)路由器收到要轉(zhuǎn)發(fā)的多播數(shù)據(jù)報時，它只將該數(shù)據(jù)報轉(zhuǎn)發(fā)到（使用相應(yīng)的多播鏈路層地址）還擁有屬于那個組主機的接口上。
圖1 3 - 3顯示了兩個IGMP報文，一個是主機發(fā)送的報告，另一個是路由器發(fā)送的查詢。該路由器正在要求那個接口上的每個主機說明它加入的每個多播組。
為改善該協(xié)議的效率，有許多實現(xiàn)的細(xì)節(jié)要考慮。首先，當(dāng)一個主機首次發(fā)送IGMP報告（當(dāng)?shù)谝粋€進程加入一個多播組）時，并不保證該報告被可靠接收（因為使用的是IP交付服務(wù)）。下一個報告將在間隔一段時間后發(fā)送。這個時間間隔由主機在0 ~ 1 0秒的范圍內(nèi)隨機選擇。
其次，當(dāng)一個主機收到一個從路由器發(fā)出的查詢后，并不立即響應(yīng)，而是經(jīng)過一定的時間間隔后才發(fā)出一些響應(yīng)（采用“響應(yīng)”的復(fù)數(shù)形式是因為該主機必須對它參加的每個組均發(fā)送一個響應(yīng)）。既然參加同一多播組的多個主機均能發(fā)送一個報告，可將它們的發(fā)送間隔設(shè)置為隨機時延。在一個物理網(wǎng)絡(luò)中的所有主機將收到同組其他主機發(fā)送的所有報告，因為如圖1 3 - 3所示的報告中的目的地址是那個組地址。這意味著如果一個主機在等待發(fā)送報告的過程中，卻收到了發(fā)自其他主機的相同報告，則該主機的響應(yīng)就可以不必發(fā)送了。因為多播路由器并不關(guān)心有多少主機屬于該組，而只關(guān)心該組是否還至少擁有一個主機。的確，一個多播路由器甚至不關(guān)心哪個主機屬于一個多播組。它僅僅想知道在給定的接口上的多播組中是否還至少有一個主機。
在沒有任何多播路由器的單個物理網(wǎng)絡(luò)中，僅有的IGMP通信量就是在主機加入一個新的多播組時，支持IP多播的主機所發(fā)出的報告。
3.4 生存時間字段
在圖1 3 - 3中，我們注意到IGMP報告和查詢的生存時間（TTL）均設(shè)置為1，這涉及到IP首部中的TTL字段。一個初始TTL為0的多播數(shù)據(jù)報將被限制在同一主機。在默認(rèn)情況下，待傳多播數(shù)據(jù)報的TTL被設(shè)置為1，這將使多播數(shù)據(jù)報僅局限在同一子網(wǎng)內(nèi)傳送。更大的TTL值能被多播路由器轉(zhuǎn)發(fā)。
回顧6 . 2節(jié)，對發(fā)往一個多播地址的數(shù)據(jù)報從不會產(chǎn)生ICMP差錯。當(dāng)TTL值為0時，多播路由器也不產(chǎn)生ICMP“超時”差錯。
在正常情況下，用戶進程不關(guān)心傳出數(shù)據(jù)報的TTL.然而，一個例外是Traceroute程序（第8章），它主要依據(jù)設(shè)置TTL值來完成。既然多播應(yīng)用必須能夠設(shè)置要傳送數(shù)據(jù)報的TTL值，這意味著程序設(shè)計接口必須為用戶進程提供這種能力。
通過增加TTL值的方法，一個應(yīng)用程序可實現(xiàn)對一個特定服務(wù)器的擴展環(huán)搜索（eXPandingring search）。第一個多播數(shù)據(jù)報以TTL等于1發(fā)送。如果沒有響應(yīng)，就嘗試將TTL設(shè)置為2，然后3，等等。在這種方式下，該應(yīng)用能找到以跳數(shù)來度量的最近的服務(wù)器。
從224.0.0.0到224.0.0.255的特殊地址空間是打算用于多播范圍不超過1跳的應(yīng)用。不管TTL值是多少，多播路由器均不轉(zhuǎn)發(fā)目的地址為這些地址中的任何一個地址的數(shù)據(jù)報。
3.5 所有主機組
在圖1 3 - 3中，我們看到了路由器的IGMP查詢被送到目的IP地址224.0.0.1.該地址被稱為所有主機組地址。它涉及在一個物理網(wǎng)絡(luò)中的所有具備多播能力的主機和路由器。當(dāng)接口初始化后，所有具備多播能力接口上的主機均自動加入這個多播組。這個組的成員無需發(fā)送IGMP報告。
4 、一個例子
現(xiàn)在我們已經(jīng)了解了一些IP多播的細(xì)節(jié)，再來看看所包含的信息。我們使sun主機能夠支持多播，并將采用一些多播軟件所提供的測試程序來觀察具體的過程。
首先，采用一個經(jīng)過修改的netstat命令來報告每個接口上的多播組成員情況（在3.9節(jié)顯示了netstat-ni命令的輸出結(jié)果）。在下面的輸出中，用黑體表示有關(guān)的多播組。
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖四）
其中， - n參數(shù)將以數(shù)字形式顯示IP地址（而不是按名字來顯示它們），- i參數(shù)將顯示接口的統(tǒng)計結(jié)果，- a參數(shù)將顯示所有配置的接口。
輸出結(jié)果中的第2行l(wèi)e0（以太網(wǎng)）顯示了這個接口屬于主機組224.0.0.1（“所有主機”），和兩行地址，后一行顯示相應(yīng)的以太網(wǎng)地址為：01： 00：5e：00：00：01.這正是我們期望看到的以太網(wǎng)地址，和12 . 4節(jié)介紹的地址映射一致。我們還看到其他兩個支持多播的接口：SLIP接口sl0和回送接口l o 0，它們也屬于所有主機組。
我們也必須顯示IP路由表，用于多播的路由表同正常的路由表一樣。黑體表項顯示了所有傳往224.0.0.0的數(shù)據(jù)報均被送往以太網(wǎng)：
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖五）
如果將這個路由表與9 . 2節(jié)中s u n路由器的路由表作比較，會發(fā)現(xiàn)只是多了有關(guān)多播的條目。
現(xiàn)在使用一個測試程序來讓我們能在一個接口上加入一個多播組（不再顯示使用這個測試程序的過程）。在以太網(wǎng)接口（ 1 4 0 . 2 5 2 . 1 3 . 3 3）上加入多播組2 2 4 . 1 . 2 . 3.執(zhí)行n e t s t a t程序看到內(nèi)核已加入這個組，并得到期望的以太網(wǎng)地址。用黑體字來突出顯示和前面n e t s t a t輸出的不同。
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖六）
我們在輸出中再次顯示了其他兩個接口： s l 0和l o 0，目的是為了重申加入多播組只發(fā)生在一個接口上。
圖1 3 - 4顯示了t c p d u m p對進程加入這個多播組的跟蹤過程。
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖七）
當(dāng)主機加入多播組時產(chǎn)生第1行的輸出顯示。第2行是經(jīng)過時延后的IGMP報告，我們介紹過報告重發(fā)的時延是1 0秒內(nèi)的隨機時延。
在兩行中顯示硬件地址證實了以太網(wǎng)目的地址就是正確的多播地址。我們也看到了源IP地址為相應(yīng)的s u n主機地址，而目的IP地址是多播組地址。同時，報告的地址和期望的多播組地址是一致的。
最后，我們注意到，正像指明的那樣， TTL是1.當(dāng)TTL的值為0或1時，tcpdump在打印時用方括號將它們括起來，這是因為TTL在正常情況下均高于這些值。然而，使用多播我們期望看到許多TTL為1的IP數(shù)據(jù)報。
在這個輸出中暗示了一個多播路由器必須接收在它所有接口上的所有多播數(shù)據(jù)報。路由器無法確定主機可能加入哪個多播組。
5、多播路由器的例子
繼續(xù)前面的例子，但我們將在s u n主機中啟動一個多播選路的守護程序。這里我們感興趣的并不是多播選路協(xié)議，而是要研究所交換的IGMP查詢和報告。即使多播選路守護程序只運行在支持多播的主機（sun）上，所有的查詢和報告都將在那個以太網(wǎng)上進行多播，所以我們在該以太網(wǎng)中的其他系統(tǒng)中也能觀察到它們。
在啟動選路守護程序之前，加入另外一個多播組224.9.9.9，圖13-5顯示了輸出的結(jié)果。
IGMP（Internet組管理協(xié)議）報文及協(xié)議（圖八）
在這個輸出中沒有包括以太網(wǎng)地址，因為已經(jīng)證實了它們是正確的。也刪去了TTL等于1的說明，同樣因為它們也是我們期望的那樣。
當(dāng)選路守護程序啟動時，輸出第1行。它發(fā)出一個已經(jīng)加入了組224.0.0.4的報告。多播地址224.0.0.4是一個知名的地址，它被當(dāng)前用于多播選路的距離向量多播選路協(xié)議DVMRP（Distance Vector Multicast Routing Protocol）所使用（DVMRP在RFC 1075中定義[Waitzman ，Partridge， and Deering]）。
在該守護程序啟動時，它也發(fā)送一個IGMP查詢（第2行）。該查詢的目的IP地址為224.0.0.1（所有主機組），如圖13-3所示。
第一個報告（第3行）大約在5秒后收到，報告給組224.9.9.9.這是在下一個查詢發(fā)出之前（第4行）收到的唯一報告。當(dāng)守護程序啟動后，兩次查詢（第2行和第4行）發(fā)出的間隔很短，這是因為守護程序要將其多播路由表盡快建立起來。
第5、6和7行正是我們期望看到的：sun主機針對它所屬的每個組發(fā)出一個報告。注意組224.0.0.4是被報告的，而其他兩個組則是明確加入的，因為只要選路守護程序還在運行，它始終要屬于組224.0.0.4.
下一個查詢位于第8行，大約在前一個查詢的2分鐘后發(fā)出。它再次引發(fā)三個我們所期望的報告（第9、10和11行）。這些報告的時間順序與前面不同，因為接收查詢和發(fā)送報告的時間是隨機的。
最后的查詢在前一個查詢的大約2分鐘后發(fā)出，我們再次得到了期望的響應(yīng)。
多播是一種將報文發(fā)往多個接收者的通信方式。在許多應(yīng)用中，它比廣播更好，因為多播降低了不參與通信的主機的負(fù)擔(dān)。簡單的主機成員報告協(xié)議（ IGMP ）是多播的基本模塊。
在一個局域網(wǎng)中或跨越鄰近局域網(wǎng)的多播需要使用本章介紹的技術(shù)。廣播通常局限在單個局域網(wǎng)中，對目前許多使用廣播的應(yīng)用來說，可采用多播來替代廣播。
然而，多播還未解決的一個問題是在廣域網(wǎng)內(nèi)的多播。[Deering and Cheriton 1990] 提出擴展目前的路由協(xié)議來支持多播。9.13節(jié)中的[Perlman 1992]討論了廣域網(wǎng)多播的一些問題。
[Casner and Deering 1992] 介紹了使用多播和一個稱為MBONE（多播主干）的虛擬網(wǎng)絡(luò)在整個Internet上傳送IETF會議的情況。
