13.1 引言

12.4節(jié)概述了IP多播給出，并介紹了D類(lèi)IP地址到以太網(wǎng)地址的映射方式。也簡(jiǎn)要說(shuō)明了在單個(gè)物理網(wǎng)絡(luò)中的多播過(guò)程，但當(dāng)涉及多個(gè)網(wǎng)絡(luò)并且多播數(shù)據(jù)必須通過(guò)路由器轉(zhuǎn)發(fā)時(shí)，情況會(huì)復(fù)雜得多。

本章將介紹用于支持主機(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 111 2中定義[Deering 1989]。

正如ICMP一樣，IGMP也被當(dāng)作IP層的一部分。IGMP報(bào)文通過(guò)IP數(shù)據(jù)報(bào)進(jìn)行傳輸。不像我們已經(jīng)見(jiàn)到的其他協(xié)議，IGMP有固定的報(bào)文長(zhǎng)度，沒(méi)有可選數(shù)據(jù)。圖13-1顯示了IGMP報(bào)文如何封裝在IP數(shù)據(jù)報(bào)中。

IGMP報(bào)文通過(guò)IP首部中協(xié)議字段值為2來(lái)指明。

13.2 IGMP報(bào)文

圖13-2顯示了長(zhǎng)度為8字節(jié)的IGMP報(bào)文格式。

這是版本為1的IGMP。IGMP類(lèi)型為1說(shuō)明是由多播路由器發(fā)出的查詢報(bào)文，為2說(shuō)明是主機(jī)發(fā)出的報(bào)告報(bào)文。檢驗(yàn)和的計(jì)算和ICMP協(xié)議相同。

組地址為D類(lèi)IP地址。在查詢報(bào)文中組地址設(shè)置為0，在報(bào)告報(bào)文中組地址為要參加的組地址。在下一節(jié)中，當(dāng)介紹IGMP如何操作時(shí)，我們將會(huì)更詳細(xì)地了解它們。

13.3 IGMP協(xié)議

13.3.1 加入一個(gè)多播組

多播的基礎(chǔ)就是一個(gè)進(jìn)程的概念（使用的術(shù)語(yǔ)進(jìn)程是指操作系統(tǒng)執(zhí)行的一個(gè)程序），該進(jìn)程在一個(gè)主機(jī)的給定接口上加入了一個(gè)多播組。在一個(gè)給定接口上的多播組中的成員是動(dòng)態(tài)的—它隨時(shí)因進(jìn)程加入和離開(kāi)多播組而變化。

這里所指的進(jìn)程必須以某種方式在給定的接口上加入某個(gè)多播組。進(jìn)程也能離開(kāi)先前加入的多播組。這些是一個(gè)支持多播主機(jī)中任何API所必需的部分。使用限定詞“接口”是因?yàn)槎嗖ソM中的成員是與接口相關(guān)聯(lián)的。一個(gè)進(jìn)程可以在多個(gè)接口上加入同一多播組。

Stanford大學(xué)伯克利版Unix中的IP多播詳細(xì)說(shuō)明了有關(guān)socket API的變化，這些變化在Solaris 2.x和ip(7)的文檔中也提供了。

這里暗示一個(gè)主機(jī)通過(guò)組地址和接口來(lái)識(shí)別一個(gè)多播組。主機(jī)必須保留一個(gè)表，此表中包含所有至少含有一個(gè)進(jìn)程的多播組以及多播組中的進(jìn)程數(shù)量。

13.3.2 IGMP報(bào)告和查詢

多播路由器使用IGMP報(bào)文來(lái)記錄與該路由器相連網(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)程離開(kāi)一個(gè)組時(shí)，主機(jī)不發(fā)送IGMP報(bào)告，即便是組中的最后一個(gè)進(jìn)程離開(kāi)。主機(jī)知道在確定的組中已不再有組成員后，在隨后收到的IGMP查詢中就不再發(fā)送報(bào)告報(bào)文。
3. 多播路由器定時(shí)發(fā)送IGMP查詢來(lái)了解是否還有任何主機(jī)包含有屬于多播組的進(jìn)程。多播路由器必須向每個(gè)接口發(fā)送一個(gè)IGMP查詢。因?yàn)槁酚善飨Ｍ鳈C(jī)對(duì)它加入的每個(gè)多播組均發(fā)回一個(gè)報(bào)告，因此IGMP查詢報(bào)文中的組地址被設(shè)置為0。
4. 主機(jī)通過(guò)發(fā)送IGMP報(bào)告來(lái)響應(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ī)的接口上。

圖13-3顯示了兩個(gè)IGMP報(bào)文，一個(gè)是主機(jī)發(fā)送的報(bào)告，另一個(gè)是路由器發(fā)送的查詢。該路由器正在要求那個(gè)接口上的每個(gè)主機(jī)說(shuō)明它加入的每個(gè)多播組。

對(duì)TTL字段我們將在本節(jié)的后面介紹。

13.3.3 實(shí)現(xiàn)細(xì)節(jié)

為改善該協(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~10秒的范圍內(nèi)隨機(jī)選擇。

其次，當(dāng)一個(gè)主機(jī)收到一個(gè)從路由器發(fā)出的查詢后，并不立即響應(yīng)，而是經(jīng)過(guò)一定的時(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)槿鐖D13-3所示的報(bào)告中的目的地址是那個(gè)組地址。這意味著如果一個(gè)主機(jī)在等待發(fā)送報(bào)告的過(guò)程中，卻收到了發(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ī)。

在沒(méi)有任何多播路由器的單個(gè)物理網(wǎng)絡(luò)中，僅有的IGMP通信量就是在主機(jī)加入一個(gè)新的多播組時(shí)，支持IP多播的主機(jī)所發(fā)出的報(bào)告。

13.3.4 生存時(shí)間字段

在圖13-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ò)。

通過(guò)增加TTL值的方法，一個(gè)應(yīng)用程序可實(shí)現(xiàn)對(duì)一個(gè)特定服務(wù)器的擴(kuò)展環(huán)搜索(expanding ring search)。第一個(gè)多播數(shù)據(jù)報(bào)以TTL等于1發(fā)送。如果沒(méi)有響應(yīng)，就嘗試將TTL設(shè)置為2，然后3，等等。在這種方式下，該應(yīng)用能找到以跳數(shù)來(lái)度量的最近的服務(wù)器。

從224.0.0.0到224.0.0.255的特殊地址空間是打算用于多播范圍不超過(guò)1跳的應(yīng)用。不管TTL值是多少，多播路由器均不轉(zhuǎn)發(fā)目的地址為這些地址中的任何一個(gè)地址的數(shù)據(jù)報(bào)。

13.3.5 所有主機(jī)組

在圖13-3中，我們看到了路由器的IGMP查詢被送到目的IP地址224.0.0.1。該地址被稱(chēng)為所有主機(jī)組地址。它涉及在一個(gè)物理網(wǎng)絡(luò)中的所有具備多播能力的主機(jī)和路由器。當(dāng)接口初始化后，所有具備多播能力接口上的主機(jī)均自動(dòng)加入這個(gè)多播組。這個(gè)組的成員無(wú)需發(fā)送IGMP報(bào)告。

13.4 一個(gè)例子

現(xiàn)在我們已經(jīng)了解了一些IP多播的細(xì)節(jié)，再來(lái)看看所包含的信息。我們使sun主機(jī)能夠支持多播，并將采用一些多播軟件所提供的測(cè)試程序來(lái)觀察具體的過(guò)程。

首先，采用一個(gè)經(jīng)過(guò)修改的netstat命令來(lái)報(bào)告每個(gè)接口上的多播組成員情況（在3.9節(jié)顯示了netstat -ni命令的輸出結(jié)果）。在下面的輸出中，用黑體表示有關(guān)的多播組。

其中，-n參數(shù)將以數(shù)字形式顯示IP地址（而不是按名字來(lái)顯示它們），-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和回送接口lo0，它們也屬于所有主機(jī)組。

我們也必須顯示IP路由表，用于多播的路由表同正常的路由表一樣。黑體表項(xiàng)顯示了所有傳往224.0.0.0的數(shù)據(jù)報(bào)均被送往以太網(wǎng)：

如果將這個(gè)路由表與9.2節(jié)中sun路由器的路由表作比較，會(huì)發(fā)現(xiàn)只是多了有關(guān)多播的條目。

現(xiàn)在使用一個(gè)測(cè)試程序來(lái)讓我們能在一個(gè)接口上加入一個(gè)多播組（不再顯示使用這個(gè)測(cè)試程序的過(guò)程）。在以太網(wǎng)接口（140.252.13.33）上加入多播組224.1.2.3。執(zhí)行netstat程序看到內(nèi)核已加入這個(gè)組，并得到期望的以太網(wǎng)地址。用黑體字來(lái)突出顯示和前面netstat輸出的不同。

我們?cè)谳敵鲋性俅物@示了其他兩個(gè)接口：sl0和lo0，目的是為了重申加入多播組只發(fā)生在一個(gè)接口上。

圖13-4顯示了tcpdump對(duì)進(jìn)程加入這個(gè)多播組的跟蹤過(guò)程。

當(dāng)主機(jī)加入多播組時(shí)產(chǎn)生第1行的輸出顯示。第2行是經(jīng)過(guò)時(shí)延后的IGMP報(bào)告，我們介紹過(guò)報(bào)告重發(fā)的時(shí)延是10秒內(nèi)的隨機(jī)時(shí)延。

在兩行中顯示硬件地址證實(shí)了以太網(wǎng)目的地址就是正確的多播地址。我們也看到了源IP地址為相應(yīng)的sun主機(jī)地址，而目的IP地址是多播組地址。同時(shí)，報(bào)告的地址和期望的多播組地址是一致的。

最后，我們注意到，正像指明的那樣，TTL是1。當(dāng)TTL的值為0或1時(shí)，tcpdump在打印時(shí)用方括號(hào)將它們括起來(lái)，這是因?yàn)門(mén)TL在正常情況下均高于這些值。然而，使用多播我們期望看到許多TTL為1的IP數(shù)據(jù)報(bào)。

在這個(gè)輸出中暗示了一個(gè)多播路由器必須接收在它所有接口上的所有多播數(shù)據(jù)報(bào)。路由器無(wú)法確定主機(jī)可能加入哪個(gè)多播組。

多播路由器的例子：

繼續(xù)前面的例子，但我們將在sun主機(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é)果。

在這個(gè)輸出中沒(méi)有包括以太網(wǎng)地址，因?yàn)橐呀?jīng)證實(shí)了它們是正確的。也刪去了TTL等于1的說(shuō)明，同樣因?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ù)程序要將其多播路由表盡快建立起來(lái)。

第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)。

13.5 小結(jié)

多播是一種將報(bào)文發(fā)往多個(gè)接收者的通信方式。在許多應(yīng)用中，它比廣播更好，因?yàn)槎嗖ソ档土瞬粎⑴c通信的主機(jī)的負(fù)擔(dān)。簡(jiǎn)單的主機(jī)成員報(bào)告協(xié)議(IGMP)是多播的基本模塊。

在一個(gè)局域網(wǎng)中或跨越鄰近局域網(wǎng)的多播需要使用本章介紹的技術(shù)。廣播通常局限在單個(gè)局域網(wǎng)中，對(duì)目前許多使用廣播的應(yīng)用來(lái)說(shuō)，可采用多播來(lái)替代廣播。

然而，多播還未解決的一個(gè)問(wèn)題是在廣域網(wǎng)內(nèi)的多播。[Deering and Cheriton 1990]提出擴(kuò)展目前的路由協(xié)議來(lái)支持多播。9.13節(jié)中的[Perlman 1992]討論了廣域網(wǎng)多播的一些問(wèn)題。

[Casner and Deering 1992] 介紹了使用多播和一個(gè)稱(chēng)為MBONE（多播主干）的虛擬網(wǎng)絡(luò)在整個(gè)Internet上傳送IETF會(huì)議的情況。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-741731.html

到了這里，關(guān)于網(wǎng)絡(luò)協(xié)議--IGMP：Internet組管理協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！