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