廣播是怎樣傳送的？路由器及主機(jī)又如何處理廣播？很遺憾，這是難以回答的問題，因?yàn)樗蕾囉趶V播的類型、應(yīng)用的類型、TCP/IP實(shí)現(xiàn)方法以及有關(guān)路由器的配置。
首先，應(yīng)用程序必須支持廣播。如果執(zhí)行
sun%ping255.255.255.255
/usr/etc/ping:unknownhost255.255.255.255打算在本地電纜上進(jìn)行廣播。但它無法進(jìn)行，原因在于該應(yīng)用程序（ping）中存在一個(gè)程序設(shè)計(jì)上的問題。大多數(shù)應(yīng)用程序收到點(diǎn)分十進(jìn)制的IP地址或主機(jī)名后，會(huì)調(diào)用函數(shù)inet_addr(3)來把它們轉(zhuǎn)化為32bit的二進(jìn)制IP地址。假定要轉(zhuǎn)化的是一個(gè)主機(jī)名，如果轉(zhuǎn)化失敗，該庫函數(shù)將返回-1來表明存在某種差錯(cuò)（例如是字符而不是數(shù)字或串中有小數(shù)點(diǎn)）。但本網(wǎng)廣播地址（255.255.255.255）也被當(dāng)作存在差錯(cuò)而返回-1。大多數(shù)程序均假定接收到的字符串是主機(jī)名，然后查找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)該使用的。我們向測(cè)試網(wǎng)絡(luò)中IP地址為140.252.13.63的以太網(wǎng)發(fā)送數(shù)據(jù)報(bào)，并接收以太網(wǎng)中所有主機(jī)的應(yīng)答。與子網(wǎng)廣播地址關(guān)聯(lián)的每個(gè)接口是用于命令ifconfig的值。如果我們ping那個(gè)地址，預(yù)期的結(jié)果是：
IP通過目的地址（140.252.13.63）來確定，這是指向子網(wǎng)的廣播地址，然后向鏈路層的廣播地址發(fā)送該數(shù)據(jù)報(bào)。在6.3節(jié)提到的這種廣播類型的接收對(duì)象為局域網(wǎng)中包括發(fā)送主機(jī)在內(nèi)的所有主機(jī)，因此可以看到除了收到網(wǎng)內(nèi)其他主機(jī)的答復(fù)外，還收到來自發(fā)送主機(jī)（sun）的答復(fù)。
在這個(gè)例子中，我們也顯示了執(zhí)行ping廣播地址前后ARP緩存的內(nèi)容。這可以顯示廣播與ARP之間的相互作用。執(zhí)行ping命令前ARP緩存是空的，而執(zhí)行后是滿的（也就是說，對(duì)網(wǎng)內(nèi)其他每個(gè)響應(yīng)回顯請(qǐng)求的主機(jī)在ARP緩存中均有一個(gè)條目）。我們提到的該以太網(wǎng)數(shù)據(jù)幀被傳送到鏈路層的廣播地址（0xffffffff）是如何發(fā)生的呢？由sun主機(jī)發(fā)送的數(shù)據(jù)幀不需要ARP。
如果使用tcpdump來觀察ping的執(zhí)行過程，可以看到廣播數(shù)據(jù)幀的接收者在發(fā)送它的響應(yīng)之前，首先產(chǎn)生一個(gè)對(duì)sun主機(jī)的ARP請(qǐng)求，因?yàn)樗膽?yīng)答是單播的。在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í)插口(rawsocket)）通常允許向一個(gè)廣播地址發(fā)送數(shù)據(jù)報(bào)。如果使用不支持廣播的應(yīng)用如TFTP，情況又如何呢？（TFTP將在第15章詳細(xì)介紹。）
bsdi%tftp啟動(dòng)客戶程序
tftp>connect140.252.13.63說明服務(wù)器的IP地址
tftp>gettemp.foo試圖從服務(wù)器或獲取一個(gè)文件
tftp:sendto:Permissiondenied
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)中無需進(jìn)程進(jìn)行這個(gè)說明就能廣播UDP數(shù)據(jù)報(bào)。而某些系統(tǒng)則有更多的限制，需要有超級(jí)用戶權(quán)限的進(jìn)程才能廣播。
下一個(gè)問題是是否轉(zhuǎn)發(fā)廣播數(shù)據(jù)。有些系統(tǒng)內(nèi)核和路由器有一選項(xiàng)來控制允許或禁止這一特性
如果讓路由器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)。
我們觀察到它的確正常工作了，同時(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)離廣播所指向的網(wǎng)絡(luò)上的主機(jī)上來進(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覺察到該目的IP地址事實(shí)上是一個(gè)相連子網(wǎng)接口上的廣播地址，就將該數(shù)據(jù)報(bào)以鏈路層廣播傳往相應(yīng)網(wǎng)絡(luò)。
眾信咨詢：互聯(lián)網(wǎng)資質(zhì)代理誠信品牌