13.1 引言
12.4節(jié)概述了IP多播給出，并介紹了D類IP地址到以太網(wǎng)地址的映射方式。也簡要說明了在單個(gè)物理網(wǎng)絡(luò)中的多播過程，但當(dāng)涉及多個(gè)網(wǎng)絡(luò)并且多播數(shù)據(jù)必須通過路由器轉(zhuǎn)發(fā)時(shí)，情況會復(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)文通過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報(bào)文通過IP首部中協(xié)議字段值為2來指明侵俗。
13.2 IGMP報(bào)文
圖13-2顯示了長度為8字節(jié)的IGMP報(bào)文格式。
這是版本為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í)渣玲，我們將會更詳細(xì)地了解它們。
13.3 IGMP協(xié)議
13.3.1 加入一個(gè)多播組
多播的基礎(chǔ)就是一個(gè)進(jìn)程的概念（使用的術(shù)語進(jìn)程是指操作系統(tǒng)執(zhí)行的一個(gè)程序）弟晚，該進(jìn)程在一個(gè)主機(jī)的給定接口上加入了一個(gè)多播組忘衍。在一個(gè)給定接口上的多播組中的成員是動態(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ī)通過組地址和接口來識別一個(gè)多播組嫩舟。主機(jī)必須保留一個(gè)表，此表中包含所有至少含有一個(gè)進(jìn)程的多播組以及多播組中的進(jìn)程數(shù)量怀偷。
13.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ī)對它加入的每個(gè)多播組均發(fā)回一個(gè)報(bào)告，因此IGMP查詢報(bào)文中的組地址被設(shè)置為0恋捆。
4:主機(jī)通過發(fā)送IGMP報(bào)告來響應(yīng)一個(gè)IGMP查詢，對每個(gè)至少還包含一個(gè)進(jìn)程的組均要發(fā)回IGMP報(bào)告重绷。
使用這些查詢和報(bào)告報(bào)文沸停，多播路由器對每個(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ī)說明它加入的每個(gè)多播組。
對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)過一定的時(shí)間間隔后才發(fā)出一些響應(yīng)（采用“響應(yīng)”的復(fù)數(shù)形式是因?yàn)樵撝鳈C(jī)必須對它參加的每個(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)告的過程中策彤，卻收到了發(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)告。
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é)看幼，對發(fā)往一個(gè)多播地址的數(shù)據(jù)報(bào)從不會產(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)對一個(gè)特定服務(wù)器的擴(kuò)展環(huán)搜索(expanding ring 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)。
13.3.5 所有主機(jī)組
在圖13-3中叉袍，我們看到了路由器的IGMP查詢被送到目的IP地址224.0.0.1始锚。該地址被稱為所有主機(jī)組地址。它涉及在一個(gè)物理網(wǎng)絡(luò)中的所有具備多播能力的主機(jī)和路由器喳逛。當(dāng)接口初始化后瞧捌，所有具備多播能力接口上的主機(jī)均自動加入這個(gè)多播組。這個(gè)組的成員無需發(fā)送IGMP報(bào)告润文。
13.4 一個(gè)例子
現(xiàn)在我們已經(jīng)了解了一些IP多播的細(xì)節(jié)姐呐，再來看看所包含的信息。我們使sun主機(jī)能夠支持多播典蝌，并將采用一些多播軟件所提供的測試程序來觀察具體的過程曙砂。
首先，采用一個(gè)經(jīng)過修改的netstat命令來報(bào)告每個(gè)接口上的多播組成員情況（在3.9節(jié)顯示了netstat-ni命令的輸出結(jié)果）骏掀。在下面的輸出中麦轰，用黑體表示有關(guān)的多播組乔夯。
其中，-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和回送接口lo0娜氏，它們也屬于所有主機(jī)組拳缠。
我們也必須顯示IP路由表，用于多播的路由表同正常的路由表一樣贸弥。黑體表項(xiàng)顯示了所有傳往224.0.0.0的數(shù)據(jù)報(bào)均被送往以太網(wǎng)：
如果將這個(gè)路由表與9.2節(jié)中sun路由器的路由表作比較窟坐，會發(fā)現(xiàn)只是多了有關(guān)多播的條目。
現(xiàn)在使用一個(gè)測試程序來讓我們能在一個(gè)接口上加入一個(gè)多播組（不再顯示使用這個(gè)測試程序的過程）绵疲。在以太網(wǎng)接口（140.252.13.33）上加入多播組224.1.2.3哲鸳。執(zhí)行netstat程序看到內(nèi)核已加入這個(gè)組，并得到期望的以太網(wǎng)地址盔憨。用黑體字來突出顯示和前面netstat輸出的不同徙菠。
我們在輸出中再次顯示了其他兩個(gè)接口：sl0和lo0，目的是為了重申加入多播組只發(fā)生在一個(gè)接口上郁岩。
圖13-4顯示了tcpdump對進(jìn)程加入這個(gè)多播組的跟蹤過程婿奔。
當(dāng)主機(jī)加入多播組時(shí)產(chǎn)生第1行的輸出顯示。第2行是經(jīng)過時(shí)延后的IGMP報(bào)告问慎，我們介紹過報(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í)用方括號將它們括起來猴仑，這是因?yàn)門TL在正常情況下均高于這些值审轮。然而肥哎，使用多播我們期望看到許多TTL為1的IP數(shù)據(jù)報(bào)。
在這個(gè)輸出中暗示了一個(gè)多播路由器必須接收在它所有接口上的所有多播數(shù)據(jù)報(bào)疾渣。路由器無法確定主機(jī)可能加入哪個(gè)多播組篡诽。
多播路由器的例子
繼續(xù)前面的例子，但我們將在sun主機(jī)中啟動一個(gè)多播選路的守護(hù)程序榴捡。這里我們感興趣的并不是多播選路協(xié)議杈女，而是要研究所交換的IGMP查詢和報(bào)告。即使多播選路守護(hù)程序只運(yùn)行在支持多播的主機(jī)（sun）上吊圾，所有的查詢和報(bào)告都將在那個(gè)以太網(wǎng)上進(jìn)行多播达椰，所以我們在該以太網(wǎng)中的其他系統(tǒng)中也能觀察到它們。
在啟動選路守護(hù)程序之前项乒，加入另外一個(gè)多播組224.9.9.9啰劲，圖13-5顯示了輸出的結(jié)果。
在這個(gè)輸出中沒有包括以太網(wǎng)地址檀何，因?yàn)橐呀?jīng)證實(shí)了它們是正確的蝇裤。也刪去了TTL等于1的說明，同樣因?yàn)樗鼈円彩俏覀兤谕哪菢印?/p>
當(dāng)選路守護(hù)程序啟動時(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ù)程序啟動時(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ù)程序啟動后仆嗦，兩次查詢（第2行和第4行）發(fā)出的間隔很短辉阶，這是因?yàn)槭刈o(hù)程序要將其多播路由表盡快建立起來。
第5瘩扼、6和7行正是我們期望看到的：sun主機(jī)針對它所屬的每個(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ī)的朵夏。
最后的查詢在前一個(gè)查詢的大約2分鐘后發(fā)出，我們再次得到了期望的響應(yīng)榆纽。
13.5 小結(jié)
多播是一種將報(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)中，對目前許多使用廣播的應(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會議的情況卖局。
