12.1 引言
在第1章中我們提到有三種IP地址：?jiǎn)尾サ刂贰V播地址和多播地址。本章將更詳細(xì)地
介紹廣播和多播。
廣播和多播僅應(yīng)用于UDP，它們對(duì)需將報(bào)文同時(shí)傳往多個(gè)接收者的應(yīng)用來(lái)說(shuō)十分重要。
TCP是一個(gè)面向連接的協(xié)議，它意味著分別運(yùn)行于兩主機(jī)（由IP地址確定）內(nèi)的兩進(jìn)程
（由端口號(hào)確定）間存在一條連接。
考慮包含多個(gè)主機(jī)的共享信道網(wǎng)絡(luò)如以太網(wǎng)。每個(gè)以太網(wǎng)幀包含源主機(jī)和目的主機(jī)的以
太網(wǎng)地址（48 bit）。通常每個(gè)以太網(wǎng)幀僅發(fā)往單個(gè)目的主機(jī)，目的地址指明單個(gè)接收
接口，因而稱為單播(unicast)。在這種方式下，任意兩個(gè)主機(jī)的通信不會(huì)干擾網(wǎng)內(nèi)其
他主機(jī)（可能引起爭(zhēng)奪共享信道的情況除外）。
然而，有時(shí)一個(gè)主機(jī)要向網(wǎng)上的其他主機(jī)發(fā)送幀，這就是廣播。通過(guò)ARP和RARP可以看
到這一過(guò)程。多播(multicast) 處于單播和廣播之間：幀僅傳送給屬于多播組的多個(gè)主
機(jī)。
為了弄清廣播和多播，需要了解主機(jī)對(duì)由信道傳送過(guò)來(lái)幀的過(guò)濾過(guò)程。圖12.1說(shuō)明了這
一過(guò)程。
首先，網(wǎng)卡查看由信道傳送過(guò)來(lái)的幀，確定是否接收該幀，若接收后就將它傳往設(shè)備驅(qū)
動(dòng)程序。通常網(wǎng)卡僅接收那些目的地址為網(wǎng)卡物理地址或廣播地址的幀。另外，多數(shù)接
口均被設(shè)置為混合模式，這種模式能接收每個(gè)幀的一個(gè)復(fù)制。作為一個(gè)例子，tcpdump
使用這種模式。
圖12.1 協(xié)議棧各層對(duì)收到幀的過(guò)濾過(guò)程
目前，大多數(shù)的網(wǎng)卡經(jīng)過(guò)配置都能接收目的地址為多播地址或某些子網(wǎng)多播地址的幀。
對(duì)于以太網(wǎng)，當(dāng)?shù)刂分凶罡咦止?jié)的最低位設(shè)置為1時(shí)表示該地址是一個(gè)多播地址，用十
六進(jìn)制可表示為01:00:00:00:00:00。（以太網(wǎng)廣播地址ff:ff:ff:ff:ff:ff可看作是以
太網(wǎng)多播地址的特例。）
如果網(wǎng)卡收到一個(gè)幀，這個(gè)幀將被傳送給設(shè)備驅(qū)動(dòng)程序。（如果幀檢驗(yàn)和錯(cuò)，網(wǎng)卡將丟
棄該幀。）設(shè)備驅(qū)動(dòng)程序?qū)⑦M(jìn)行另外的幀過(guò)濾。首先，幀類型中必須指定要使用的協(xié)議
（IP，ARP等等）。其次，進(jìn)行多播過(guò)濾來(lái)檢測(cè)該主機(jī)是否屬于多播地址說(shuō)明的多播組。
設(shè)備驅(qū)動(dòng)程序隨后將數(shù)據(jù)幀傳送給下一層，比如，當(dāng)幀類型指定為IP數(shù)據(jù)報(bào)時(shí)，就傳往
IP層。IP根據(jù)IP地址中的源地址和目的地址進(jìn)行更多的過(guò)慮檢測(cè)，如果正常，將數(shù)據(jù)報(bào)
傳送給下一層（如TCP或UDP）。
每次UDP收到由IP傳送來(lái)的數(shù)據(jù)報(bào)，就根據(jù)目的端口號(hào)，有時(shí)還有源端口號(hào)進(jìn)行數(shù)據(jù)報(bào)
過(guò)濾。如果當(dāng)前沒(méi)有進(jìn)程使用該目的端口號(hào)，就丟棄該數(shù)據(jù)報(bào)并產(chǎn)生一個(gè)ICMP不可達(dá)報(bào)
文。（TCP根據(jù)它的端口號(hào)作相似的過(guò)慮。）如果UDP數(shù)據(jù)報(bào)存在檢驗(yàn)和錯(cuò)，將被丟棄。
使用廣播的問(wèn)題在于它增加了對(duì)廣播數(shù)據(jù)不感興趣主機(jī)的處理負(fù)荷。拿一個(gè)使用UDP廣
播應(yīng)用作為例子，如果網(wǎng)內(nèi)有50個(gè)主機(jī)，但僅有20個(gè)參與該應(yīng)用，每次這20個(gè)主機(jī)中的
一個(gè)發(fā)送UDP廣播數(shù)據(jù)時(shí)，其余30個(gè)主機(jī)不得不處理這些廣播數(shù)據(jù)報(bào)，而直到UDP層，收
到的UDP廣播數(shù)據(jù)報(bào)才會(huì)被丟棄。這30個(gè)主機(jī)丟棄UDP廣播數(shù)據(jù)報(bào)是因?yàn)檫@些主機(jī)沒(méi)有使
用這個(gè)目的端口。
多播的出現(xiàn)減少了對(duì)應(yīng)用不感興趣主機(jī)的處理負(fù)荷。使用多播，主機(jī)可加入一個(gè)或多個(gè)
多播組。這樣，網(wǎng)卡將獲悉該主機(jī)屬于哪個(gè)多播組，然后僅接收主機(jī)所在多播組的那些
多播幀。
12.2 廣播
在圖3.9中，我們知道了四種IP廣播地址，下面對(duì)它們進(jìn)行更詳細(xì)的介紹。
受限的廣播
受限的廣播地址是255.255.255.255。該地址用于主機(jī)配置過(guò)程中IP數(shù)據(jù)報(bào)中目的地址，
此時(shí)，主機(jī)可能還不知道它所在網(wǎng)絡(luò)的網(wǎng)絡(luò)掩碼，甚至連它的IP地址也不知道。
在任何情況下，路由器都不轉(zhuǎn)發(fā)目的地址為受限的廣播地址的數(shù)據(jù)報(bào)，這樣的數(shù)據(jù)報(bào)僅
出現(xiàn)在本地網(wǎng)絡(luò)中。
一個(gè)未解的問(wèn)題是：如果一個(gè)主機(jī)是多接口的，當(dāng)一個(gè)進(jìn)程向本網(wǎng)廣播地址發(fā)送數(shù)據(jù)報(bào)
時(shí)，為實(shí)現(xiàn)廣播，是否應(yīng)該將數(shù)據(jù)報(bào)發(fā)送到每個(gè)相連的接口上？如果不是這樣，想對(duì)主
機(jī)所有接口廣播的應(yīng)用必須確定主機(jī)中支持廣播的所有接口，然后向每個(gè)接口發(fā)送一個(gè)
數(shù)據(jù)報(bào)復(fù)制。
大多數(shù)BSD系統(tǒng)將255.255.255.255看作是配置后第一個(gè)接口的廣播地址，并且不提供向
所屬具備廣播能力接口傳送數(shù)據(jù)報(bào)的功能。不過(guò)，routed（見(jiàn)10.3）和rwhod（BSD
rwho客戶的服務(wù)器）是向每個(gè)接口發(fā)送UDP數(shù)據(jù)報(bào)的兩個(gè)應(yīng)用程序。這兩個(gè)應(yīng)用程序均
有相似的啟動(dòng)過(guò)程來(lái)確定主機(jī)中的所有接口，并了解哪些接口具備廣播能力。同時(shí)，將
對(duì)應(yīng)于那種接口的指向網(wǎng)絡(luò)的廣播地址作為向該接口發(fā)送的數(shù)據(jù)報(bào)的目的地址。
Host Requirements RFC沒(méi)有進(jìn)一步涉及多接口主機(jī)是否應(yīng)當(dāng)向其所有的接口發(fā)送受限
的廣播。
指向網(wǎng)絡(luò)的廣播
指向網(wǎng)絡(luò)的廣播地址是主機(jī)號(hào)字段均為1的地址。A類網(wǎng)絡(luò)廣播地址為
netid.255.255.255，其中netid為A類網(wǎng)絡(luò)的網(wǎng)絡(luò)號(hào)。
一個(gè)路由器必須轉(zhuǎn)發(fā)指向網(wǎng)絡(luò)的廣播，但它也必須有一個(gè)不進(jìn)行轉(zhuǎn)發(fā)的選擇。
指向子網(wǎng)的廣播
指向子網(wǎng)的廣播地址為主機(jī)號(hào)碼字段均為1且有特定子網(wǎng)號(hào)的地址。作為子網(wǎng)直接廣播
地址的IP地址需要了解子網(wǎng)的掩碼。例如，如果路由器收到發(fā)往128.1.2.255的數(shù)據(jù)報(bào)，
當(dāng)B類網(wǎng)絡(luò)128.1的子網(wǎng)掩碼為255.255.255.0時(shí)，該地址就是指向子網(wǎng)的廣播地址；但
如果該子網(wǎng)的掩碼為255.255.254.0，該地址就不是指向子網(wǎng)的廣播地址。
指向所有子網(wǎng)的廣播
指向所有子網(wǎng)的廣播也需要了解目的網(wǎng)絡(luò)的子網(wǎng)掩碼，以便與指向網(wǎng)絡(luò)的廣播地址區(qū)分
開(kāi)。指向所有子網(wǎng)的廣播地址的子網(wǎng)號(hào)字段及主機(jī)號(hào)字段均為1。例如，如果目的子網(wǎng)
掩碼為255.255.255.0，那么IP地址128.1.255.255是一個(gè)指向所有子網(wǎng)的廣播地址。然
而，如果網(wǎng)絡(luò)沒(méi)有劃分子網(wǎng)，這就是一個(gè)指向網(wǎng)絡(luò)的廣播。
當(dāng)前的看法[Almquist 1993]是這種廣播是陳舊過(guò)時(shí)的，更好的方式是使用多播而不是
對(duì)所有子網(wǎng)的廣播。
----[Almquist 1993] 解釋了RFC 922需要一個(gè)向所有子網(wǎng)的廣播來(lái)傳送給所有子網(wǎng)，但
當(dāng)前的路由器沒(méi)有這么做。這很幸運(yùn)，因?yàn)橐粋€(gè)已經(jīng)錯(cuò)誤配置的主機(jī)沒(méi)有它的主機(jī)掩碼
會(huì)把它的本地廣播傳送到所有子網(wǎng)。例如，如果IP地址為128.1.2.3的主機(jī)沒(méi)有設(shè)置子
網(wǎng)掩碼，它的廣播地址在正常情況下的默認(rèn)值是128.1.255.255。但如果子網(wǎng)掩碼被設(shè)
置為255.255.255.0，那么由錯(cuò)誤配置的主機(jī)發(fā)出的廣播將指向所有的子網(wǎng)。
--
--1983年問(wèn)世的4.2BSD是第一個(gè)影響廣泛的TCP/IP的實(shí)現(xiàn)，它使用主機(jī)號(hào)全0作為廣播地
址。一個(gè)最早有關(guān)廣播IP地址參考是IEN 212 [Gurwitz and Hinden 1982]，它提出用
主機(jī)號(hào)中的1比特來(lái)表示IP廣播地址。（IENs 是互聯(lián)網(wǎng)試驗(yàn)注釋，基本上是RFC的前
身。）RFC 894 [Hornig 1984]認(rèn)為4.2BSD使用不標(biāo)準(zhǔn)的廣播地址，但RFC 906
[Finlayson 1984] 注意到對(duì)廣播地址還沒(méi)有Internet標(biāo)準(zhǔn)。他還在RFC 906加了一個(gè)腳
注承認(rèn)缺少標(biāo)準(zhǔn)的廣播地址，并強(qiáng)烈推薦將主機(jī)號(hào)全1作為廣播地址。盡管1986年的
4.3BSD采用主機(jī)號(hào)全1表示廣播地址，但直到90年代早期操作系統(tǒng)（突出的是SunOS 4.x）
還繼續(xù)使用非標(biāo)準(zhǔn)的廣播地址。
12.3 廣播的例子
廣播是怎樣傳送的？路由器及主機(jī)又如何處理廣播？很遺憾，這是難于回答的問(wèn)題，因
為它依賴于廣播的類型、應(yīng)用的類型、TCP/IP實(shí)現(xiàn)方法以及有關(guān)路由器的配置。
首先，應(yīng)用程序必須支持廣播。如果執(zhí)行
sun % ping 255.255.255.255
/usr/etc/ping: unknown host 255.255.255.255
打算進(jìn)行在本地電纜上的廣播，但它無(wú)法進(jìn)行，原因在于該應(yīng)用程序（ping）中存在一
個(gè)程序設(shè)計(jì)上的問(wèn)題。大多數(shù)應(yīng)用程序收到點(diǎn)分十進(jìn)制的IP地址或主機(jī)名后，會(huì)調(diào)用函
數(shù)inet_addr(3)來(lái)把它們轉(zhuǎn)化為32 bit的二進(jìn)制IP地址。假定要轉(zhuǎn)化的是一個(gè)主機(jī)名，
如果轉(zhuǎn)化失敗，該庫(kù)函數(shù)將返回-1來(lái)表明存在某種差錯(cuò)（例如是字符而不是數(shù)字或串中
有小數(shù)點(diǎn)），但本網(wǎng)廣播地址（255.255.255.255）也被當(dāng)作存在差錯(cuò)而返回-1。大多
數(shù)程序均假定接收到的字符串是主機(jī)名，然后查找域名系統(tǒng)DNS（第14章），失敗后輸
出差錯(cuò)信息如“未知主機(jī)”。
如果我們修復(fù)ping程序中這個(gè)欠缺，結(jié)果也并不總是令人滿意的。在6個(gè)不同系統(tǒng)的測(cè)
試中，僅有一個(gè)像預(yù)期的那樣產(chǎn)生了一個(gè)本網(wǎng)廣播數(shù)據(jù)報(bào)。大多數(shù)則在路由表中查找IP
地址255.255.255.255，而該地址被用作默認(rèn)路由器地址，因此向默認(rèn)路由器單播一個(gè)
數(shù)據(jù)報(bào)。最終該數(shù)據(jù)報(bào)被丟棄。
指向子網(wǎng)的廣播是我們應(yīng)該使用的。在6.3節(jié)中，我們向測(cè)試網(wǎng)絡(luò)（見(jiàn)封2）中IP地址為
140.252.13.63 的以太網(wǎng)發(fā)送數(shù)據(jù)報(bào)，并接收以太網(wǎng)中所有主機(jī)的回答。與子網(wǎng)廣播
地址關(guān)聯(lián)的每個(gè)接口是用于命令ifconfig（見(jiàn)3.8節(jié)）的值。如果我們ping那個(gè)地址，
預(yù)期的結(jié)果是：
（見(jiàn)原書(shū)p.173①）
IP通過(guò)目的地址（140.252.13.63）來(lái)確定這是指向子網(wǎng)的廣播地址，然后向鏈路層的
廣播地址發(fā)送該數(shù)據(jù)報(bào)。
我們?cè)?.3提及的這種類型廣播的接收對(duì)象為包括發(fā)送主機(jī)在內(nèi)的局域網(wǎng)中的所有主機(jī)，
因此可以看到除了收到網(wǎng)內(nèi)其他主機(jī)的答復(fù)外，還收到了來(lái)自發(fā)送主機(jī)（sun）的答復(fù)。
在這個(gè)例子中，我們也顯示了執(zhí)行ping廣播地址前后ARP緩存的內(nèi)容。這可以顯示廣播
與ARP之間的相互作用。執(zhí)行ping命令前ARP緩存是空的，而執(zhí)行后是滿的。（也就是說(shuō)，
對(duì)網(wǎng)內(nèi)其他每個(gè)響應(yīng)回顯請(qǐng)求的主機(jī)在ARP緩存中均有一個(gè)條目。）我們提到的該以太
數(shù)據(jù)幀被傳送到鏈路層的廣播地址（0xffffffff）是如何發(fā)生的呢？由sun主機(jī)發(fā)送的
數(shù)據(jù)幀不需要ARP。
如果使用tcpdump來(lái)觀察ping的執(zhí)行過(guò)程，可以看到廣播數(shù)據(jù)幀的接收者在發(fā)送它的響
應(yīng)之前，首先產(chǎn)生一個(gè)對(duì)sun主機(jī)的ARP請(qǐng)求，因?yàn)樗幕卮鹗且詥尾バ问桨l(fā)回的。在
4.5節(jié)我們介紹了一個(gè)ARP請(qǐng)求的接收者（該例中是sun）通常在發(fā)送ARP應(yīng)答外，還將請(qǐng)
求主機(jī)的IP地址和物理地址加入到ARP緩存中去。這基于這樣一個(gè)假定：如果請(qǐng)求者向
我們發(fā)送一個(gè)數(shù)據(jù)報(bào)，我們也很可能想向它發(fā)回什么。
我們使用的ping程序有些特殊，原因在于它使用的編程接口（在大多數(shù)Unix實(shí)現(xiàn)中是
“低級(jí)插口(raw socket)”）通常允許向一個(gè)廣播地址發(fā)送數(shù)據(jù)報(bào)。如果我們使用不支
持廣播的應(yīng)用如TFTP情況如何呢？（TFTP將在第15章詳細(xì)介紹。）
bsdi % tftp-------- 啟動(dòng)客戶程序
tftp> connect 140.252.13.63----說(shuō)明服務(wù)器的IP地址
tftp> get temp.foo------ 試圖從服務(wù)器或獲取一個(gè)文件
tftp: sendto: Permission denied
tftp> quit-------- 終止客戶程序
在這個(gè)例子中，程序立即產(chǎn)生了一個(gè)差錯(cuò)，但不向網(wǎng)絡(luò)發(fā)送任何信息。產(chǎn)生這一切的原
因在于插口提供的應(yīng)用程序接口API只有進(jìn)程明確打算進(jìn)行廣播時(shí)才允許它向廣播地址
發(fā)送UDP數(shù)據(jù)報(bào)。這主要是為了防止用戶錯(cuò)誤地采用了廣播地址（正如此例）而應(yīng)用程
序卻不打算廣播。
在廣播UDP數(shù)據(jù)報(bào)之前，使用插口中API的應(yīng)用程序必須設(shè)置SO_BROADCAST 插
口選項(xiàng)。
并非所有系統(tǒng)均強(qiáng)制使用這個(gè)限制。某些系統(tǒng)中無(wú)需進(jìn)程進(jìn)行這個(gè)說(shuō)明就能廣
播UDP數(shù)據(jù)報(bào)。而某些系統(tǒng)則有更多的限制，需要有超級(jí)用戶權(quán)限的進(jìn)程才能廣播。
下一個(gè)問(wèn)題是是否轉(zhuǎn)發(fā)廣播數(shù)據(jù)。一些系統(tǒng)內(nèi)核和路由器有一選項(xiàng)來(lái)控制允許或禁止這
一特性。（見(jiàn)附錄E）
如果我們讓路由器bsdi能夠轉(zhuǎn)發(fā)廣播數(shù)據(jù)，然后在主機(jī)slip上運(yùn)行ping程序，我們能夠
觀察到由路由器bsdi轉(zhuǎn)發(fā)的子網(wǎng)廣播數(shù)據(jù)報(bào)。轉(zhuǎn)發(fā)廣播數(shù)據(jù)報(bào)意味著路由器接收廣播數(shù)
據(jù)，確定該目的地址是對(duì)哪個(gè)接口的廣播，然后用鏈路層廣播向?qū)?yīng)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)。
（見(jiàn)原書(shū)p.174①）
我們觀察到它的確正常工作了，同時(shí)也看到了BSD系統(tǒng)中的ping程序檢查重復(fù)的數(shù)據(jù)報(bào)
序列號(hào)，如果出現(xiàn)重復(fù)的序列號(hào)的數(shù)據(jù)報(bào)就顯示DUP! ，它意味著一個(gè)數(shù)據(jù)報(bào)已經(jīng)在某
處重復(fù)了，然而它正是我們所期望看到的，因?yàn)槲覀冋蛞粋€(gè)廣播地址發(fā)送數(shù)據(jù)。
我們還可以從更遠(yuǎn)離廣播所指向的絡(luò)網(wǎng)上的主機(jī)上來(lái)進(jìn)行這個(gè)試驗(yàn)。如果在主機(jī)
angogh.cx.berkeley.edu（和我們的網(wǎng)絡(luò)距離14跳）上運(yùn)行ping程序，如果路由器sun
被設(shè)置為能夠轉(zhuǎn)發(fā)所指向的廣播，它還能正常工作。在這種情況下，這個(gè)IP數(shù)據(jù)報(bào)（傳
送ICMP回顯請(qǐng)求）被路徑上的每個(gè)路由器像正常的數(shù)據(jù)報(bào)一樣轉(zhuǎn)發(fā)，它們均不知道它們
傳送的實(shí)際上是廣播數(shù)據(jù)。接著最后一個(gè)路由器netb看到主機(jī)號(hào)為63，就將其轉(zhuǎn)發(fā)給路
由器sun。路由器sun覺(jué)察到該目的IP地址事實(shí)上是一個(gè)相連子網(wǎng)接口上的廣播地址，就
以該數(shù)據(jù)報(bào)以鏈路層廣播傳往相應(yīng)網(wǎng)絡(luò)。
廣播是一種應(yīng)該謹(jǐn)慎使用功能。在許多情況下，IP多播被證明是一個(gè)更好的解決辦法。
12.4 多播
IP多播提供兩類服務(wù)。
1. 向多個(gè)目的地址傳送數(shù)據(jù)。有許多向多個(gè)接收者傳送信息的應(yīng)用：例如交互式會(huì)議
系統(tǒng)和向多個(gè)接收者分發(fā)郵件或新聞。如果不采用多播，目前這些應(yīng)用大多采用TCP來(lái)
完成（向每個(gè)目的地址傳送一個(gè)單獨(dú)的數(shù)據(jù)復(fù)制）。然而，既使使用多播，某些應(yīng)用可
能繼續(xù)采用TCP來(lái)保證它的可靠性。
2. 客戶對(duì)服務(wù)器的請(qǐng)求。例如，無(wú)盤(pán)工作站需要確定啟動(dòng)引導(dǎo)服務(wù)器。目前，這項(xiàng)服
務(wù)是通過(guò)廣播來(lái)提供的（正如第16章的BOOTP），但是使用多播可降低不提供這項(xiàng)服務(wù)
主機(jī)的負(fù)擔(dān)。
多播組地址
圖12.2 顯示了D類IP地址的格式。
圖12.2 D類IP地址格式
不像圖1.5 所示的其他三類IP地址（A、B和C），分配的28 bit均用作多播組號(hào)碼而不
再表示其他。
多播組地址包括最高4 bit為1110的類別比特和多播組號(hào)。它們通常可表示為由點(diǎn)分十
進(jìn)制數(shù)，范圍從224.0.0.0到239.255.255.255。
能夠接收發(fā)往一個(gè)特定多播組地址數(shù)據(jù)的主機(jī)集合稱為主機(jī)組(host group)。一個(gè)主機(jī)
組可跨越多個(gè)網(wǎng)絡(luò)。主機(jī)組中成員可隨時(shí)加入或離開(kāi)主機(jī)組。主機(jī)組中對(duì)主機(jī)的數(shù)量沒(méi)
有限制，同時(shí)不屬于某一主機(jī)組的主機(jī)可以向該組發(fā)送信息。
一些多播組地址被IANA確定為熟知地址。它們也被當(dāng)作永久主機(jī)組，這和TCP及UDP中的
熟知端口相似。同樣的，這些熟知多播地址在RFC最新分配數(shù)字中列出。注意這些多播
地址所代表的組是永久組，而它們的組成員卻不是永久的。
例如，224.0.0.1代表“該子網(wǎng)內(nèi)的所有系統(tǒng)組”，224.0.0.2代表“該子網(wǎng)內(nèi)的所有路
由器組”。多播地址224.0.1.1用作網(wǎng)絡(luò)時(shí)間協(xié)議NTP，224.0.0.9用作RIP-2(見(jiàn)10.5節(jié))，
224.0.1.2用作SGI公司的dogfight應(yīng)用。
多播組地址到以太網(wǎng)地址的轉(zhuǎn)換
IANA擁有一個(gè)以太網(wǎng)地址塊，即高位24 bit為00:00:5e（十六進(jìn)制表示）的以太網(wǎng)地址，
這意味著該地址塊所擁有的地址范圍從00:00:5e:00:00:00到00:00:5e:ff:ff:ff。IANA
將其中的一半分配為多播地址。為了指明一個(gè)多播地址，任何一個(gè)以太網(wǎng)地址的首字節(jié)
必須是01，這意味著與IP多播相對(duì)應(yīng)的以太網(wǎng)地址范圍從01:00:5e:00:00:00到
01:00:5e:7f:ff:ff。
----這里對(duì)CSMA/CD或令牌網(wǎng)使用的是Internet標(biāo)準(zhǔn)比特順序，和在內(nèi)存中出現(xiàn)的比特順
序一樣。這也是大多數(shù)程序設(shè)計(jì)者和系統(tǒng)管理者采用的順序。IEEE文檔采用了這種比特
的傳輸順序。Assigned Numbers RFC給出了這些表示的差別。
這個(gè)地址分配將使以太網(wǎng)多播地址中的23 bit與IP多播組號(hào)對(duì)應(yīng)起來(lái)，這通過(guò)將多播組
號(hào)中的低位23 bit映射到以太網(wǎng)地址中的低位23 bit實(shí)現(xiàn)，這個(gè)過(guò)程如圖12.3。
既然多播組號(hào)中的最高5 bit在映射過(guò)程中被忽略，因此每個(gè)以太網(wǎng)多播地址對(duì)應(yīng)的多
播組是不唯一的。32個(gè)不同的多播組號(hào)被映射為一個(gè)以太網(wǎng)地址。例如，多播地址
224.128.64.32（十六進(jìn)制e0.80.40.20）和224.0.64.32（十六進(jìn)制e0.00.40.20）都映
射為同一以太網(wǎng)地址01:00:5e:00:40:20。
既然地址映射是不唯一的，這意味著設(shè)備驅(qū)動(dòng)程序或IP層（見(jiàn)圖12.1）必須進(jìn)行數(shù)據(jù)報(bào)
過(guò)濾，因?yàn)榫W(wǎng)卡可能接收到主機(jī)不想接收的多播數(shù)據(jù)幀。另外，如果網(wǎng)卡不提供足夠的
多播數(shù)據(jù)幀過(guò)濾功能，設(shè)備驅(qū)動(dòng)程序就必須接收所有多播數(shù)據(jù)幀，然后對(duì)它們進(jìn)行過(guò)濾。
圖12.3 D類IP地址到以太網(wǎng)多播地址的映射
局域網(wǎng)網(wǎng)卡趨向兩種處理類型，一種是網(wǎng)卡根據(jù)對(duì)多播地址的散列值實(shí)行多播過(guò)濾，這
意味仍會(huì)接收到不想接收的多播數(shù)據(jù)。另一種網(wǎng)卡是只接收一些固定數(shù)目的多播地址，
這意味著當(dāng)主機(jī)想接收超過(guò)網(wǎng)卡預(yù)先支持多播地址以外的多播地址時(shí)，必須將網(wǎng)卡設(shè)置
為“多播混雜(multicast promiscuous)”模式。因此，這兩種類型的網(wǎng)卡仍需要設(shè)備
驅(qū)動(dòng)程序檢查收到的幀是否真是主機(jī)所需要的。
既使網(wǎng)卡實(shí)現(xiàn)了完美的多播過(guò)濾（基于48 bit的硬件地址），由于從D類IP地址到48
bit的硬件地址的映射不是一對(duì)一的，過(guò)濾過(guò)程仍是必要的。
盡管存在地址映射不完美和需要硬件過(guò)濾的不足，多播仍然比廣播好。
單個(gè)物理網(wǎng)絡(luò)的多播是簡(jiǎn)單的。多播進(jìn)程將目的IP地址指明為多播地址，設(shè)備驅(qū)動(dòng)程序
將它轉(zhuǎn)換為相應(yīng)的以太網(wǎng)地址，然后把數(shù)據(jù)發(fā)送出去。這些接收進(jìn)程必須通知它們的IP
層它們想接收的發(fā)往給定多播地址的數(shù)據(jù)報(bào)，并且設(shè)備驅(qū)動(dòng)程序必須能夠接收這些多播
幀。這個(gè)過(guò)程就是“加入一個(gè)多播組”。（使用“接收進(jìn)程”復(fù)數(shù)形式的原因在于對(duì)一
確定的多播信息，在同一主機(jī)或多個(gè)主機(jī)上存在多個(gè)接收者，這也是為什么要首先使用
多播的原因。）當(dāng)一個(gè)主機(jī)收到多播數(shù)據(jù)報(bào)時(shí)，它必須向?qū)儆谀莻€(gè)多播組的每個(gè)進(jìn)程均
傳送一個(gè)復(fù)制。這和單個(gè)進(jìn)程收到單播UDP數(shù)據(jù)報(bào)的UDP不同，使用多播，一個(gè)主機(jī)上可
能存在多個(gè)屬于同一多播組的進(jìn)程。
當(dāng)把多播擴(kuò)展到單個(gè)物理網(wǎng)絡(luò)以外需要通過(guò)路由器轉(zhuǎn)發(fā)多播數(shù)據(jù)時(shí)，復(fù)雜性就增加了。
需要有一個(gè)協(xié)議讓多播路由器了解確定網(wǎng)絡(luò)中屬于確定多播組的任何一個(gè)主機(jī)。這個(gè)協(xié)
議就是Internet組管理協(xié)議（IGMP），也是下一章介紹的內(nèi)容。
FDDI和令牌環(huán)網(wǎng)絡(luò)中的多播
FDDI網(wǎng)絡(luò)使用相同的D類IP地址到48 bit FDDI地址的映射過(guò)程[Katz 1990]。令牌環(huán)網(wǎng)
絡(luò)通常使用不同的地址映射方法，這是因?yàn)榇蠖鄶?shù)令牌控制中的限制。
12.5 小結(jié)
廣播是將數(shù)據(jù)報(bào)發(fā)送到網(wǎng)絡(luò)中的所有主機(jī)（通常是本地相連的網(wǎng)絡(luò)），而多播是將數(shù)據(jù)
報(bào)發(fā)送到網(wǎng)絡(luò)的一個(gè)主機(jī)組。這兩個(gè)概念的基本點(diǎn)在于當(dāng)收到送往上一個(gè)協(xié)議棧的數(shù)據(jù)
幀時(shí)采用不同類型的過(guò)濾。每個(gè)協(xié)議層均可以因?yàn)椴煌睦碛蓙G棄數(shù)據(jù)報(bào)。
目前有四種類型的廣播地址：受限的廣播、指向網(wǎng)絡(luò)的廣播、指向子網(wǎng)的廣播和指向所
有子網(wǎng)的廣播。最常用的是指向子網(wǎng)的廣播。受限的廣播通常只在系統(tǒng)初始啟動(dòng)時(shí)才會(huì)
用到。
試圖通過(guò)路由器進(jìn)行廣播而發(fā)生的問(wèn)題，常常是因?yàn)槁酚善鞑涣私饽康木W(wǎng)絡(luò)的子網(wǎng)掩碼。
結(jié)果與多種因素有關(guān)：廣播地址類型、配置參數(shù)等等。
D類IP地址被稱為多播組地址。通過(guò)將其低位23 bit映射到相應(yīng)以太網(wǎng)地址中便可實(shí)現(xiàn)
多播組地址到以太網(wǎng)地址的轉(zhuǎn)換。由于地址映射是不唯一的，因此需要其他的協(xié)議實(shí)現(xiàn)
額外的數(shù)據(jù)報(bào)過(guò)濾。
習(xí)題
12.1 廣播是否增加了網(wǎng)絡(luò)通信量？
12.2 考慮一個(gè)擁有50臺(tái)主機(jī)的以太網(wǎng)：20臺(tái)運(yùn)行TCP/IP而其他30臺(tái)運(yùn)行其他的協(xié)議族。
主機(jī)如何處理來(lái)自運(yùn)行另一個(gè)協(xié)議族主機(jī)的廣播？
12.3 你登錄到一個(gè)過(guò)去從來(lái)沒(méi)有用過(guò)的Unix系統(tǒng)，并且打算找出所有支持廣播的接口
的指向子網(wǎng)的廣播地址。你如何做到這點(diǎn)？
12.4 如果我們用ping程序向一個(gè)廣播地址發(fā)送一個(gè)長(zhǎng)的分組，如
（見(jiàn)原書(shū)p.178①）
它正常工作，但將分組的長(zhǎng)度再增加一個(gè)字節(jié)后出現(xiàn)如下差錯(cuò)：
sun % ping 140.252.13.63 1473
PING 140.252.13.63: 1473 data bytes
sendto: Message too long
究竟出了什么問(wèn)題?
12.5 重做習(xí)題10.6，假定8個(gè)RIP報(bào)文是通過(guò)多播而不是廣播（使用RIP 版本2）。有什
么變化？
12—1