16.1 引言
在第5章我們介紹了一個(gè)無盤系統(tǒng)，它在不知道自身IP地址的情況下，在進(jìn)行系統(tǒng)引導(dǎo)時(shí)能夠通過RARP來獲取它的IP地址。然而使用RARP有兩個(gè)問題：（1）IP地址是返回的唯一結(jié)果；（2）既然RARP使用鏈路層廣播，RARP請(qǐng)求就不會(huì)被路由器轉(zhuǎn)發(fā)（迫使每個(gè)實(shí)際網(wǎng)絡(luò)設(shè)置一個(gè)RARP服務(wù)器）。本章將介紹一種用于無盤系統(tǒng)進(jìn)行系統(tǒng)引導(dǎo)的替代方法，又稱為引導(dǎo)程序協(xié)議，或BOOTP。
BOOTP使用UDP，且通常需與TFTP（參見第15章）協(xié)同工作。RFC 951 [Croft and Gilmore 1985]是BOOTP的正式規(guī)范，RFC 1542 [Wimer 1993]則對(duì)它作了說明。
16.2 BOOTP的分組格式
BOOTP 請(qǐng)求和應(yīng)答均被封裝在UDP數(shù)據(jù)報(bào)中，如圖16-1所示。
圖16-2顯示了長度為300字節(jié)的BOOTP請(qǐng)求和應(yīng)答的格式。
“操作碼”字段為1表示請(qǐng)求，為2表示應(yīng)答。硬件類型字段為1表示10 Mb/s的以太網(wǎng)，這和ARP請(qǐng)求或應(yīng)答（圖4-3）中同名字段表示的含義相同。類似地，對(duì)于以太網(wǎng)，硬件地址長度字段為6字節(jié)。
“跳數(shù)”字段由客戶設(shè)置為0，但也能被一個(gè)代理服務(wù)器設(shè)置（參見16.5節(jié)）。
“事務(wù)標(biāo)識(shí)”字段是一個(gè)由客戶設(shè)置并由服務(wù)器返回的32 bit整數(shù)。客戶用它對(duì)請(qǐng)求和應(yīng)答進(jìn)行匹配。對(duì)每個(gè)請(qǐng)求，客戶應(yīng)該將該字段設(shè)置為一個(gè)隨機(jī)數(shù)。
客戶開始進(jìn)行引導(dǎo)時(shí)，將“秒數(shù)”字段設(shè)置為一個(gè)時(shí)間值。服務(wù)器能夠看到這個(gè)時(shí)間值，備用服務(wù)器在等待時(shí)間超過這個(gè)時(shí)間值后才會(huì)響應(yīng)客戶的請(qǐng)求，這意味著主服務(wù)器沒有啟動(dòng)。
如果該客戶已經(jīng)知道自身的IP地址，它將寫入“客戶IP地址”字段。否則，它將該字段設(shè)置為0。對(duì)于后面這種情況，服務(wù)器用該客戶的IP地址寫入“你的IP地址”字段。“服務(wù)器IP地址”字段則由服務(wù)器填寫。如果使用了某個(gè)代理服務(wù)器（見16.5節(jié)），則該代理服務(wù)器就填寫“網(wǎng)關(guān)IP地址”字段。
客戶必須設(shè)置它的“客戶硬件地址”字段。盡管這個(gè)值與以太網(wǎng)數(shù)據(jù)幀頭中的值相同，UDP數(shù)據(jù)報(bào)中也設(shè)置這個(gè)字段，但任何接收這個(gè)數(shù)據(jù)報(bào)的用戶進(jìn)程能很容易地獲得它（例如一個(gè)BOOTP服務(wù)器）。一個(gè)進(jìn)程通過查看UDP數(shù)據(jù)報(bào)來確定以太網(wǎng)幀首部中的該字段通常是很困難的（或者說是不可能的）。
“服務(wù)器主機(jī)名”字段是一個(gè)空值終止串，由服務(wù)器填寫。服務(wù)器還將在“引導(dǎo)文件名字段”填入包括用于系統(tǒng)引導(dǎo)的文件名及其所在位置的路徑全名。
“特定廠商區(qū)域”字段用于對(duì)BOOTP進(jìn)行不同的擴(kuò)展。16.6節(jié)將介紹這些擴(kuò)展中的一些。
當(dāng)一個(gè)客戶使用BOOTP（操作碼為1）進(jìn)行系統(tǒng)引導(dǎo)時(shí)，引導(dǎo)請(qǐng)求通常是采用鏈路層廣播，IP首部中的目的IP地址為255.255.255.255（受限的廣播，12.2節(jié)）。源IP地址通常是0.0.0.0，因?yàn)榇藭r(shí)客戶還不知道它本身的IP地址。回顧圖3-9，在系統(tǒng)進(jìn)行自引導(dǎo)時(shí)，0.0.0.0是一個(gè)有效的IP地址。
端口號(hào)
BOOTP有兩個(gè)熟知端口：BOOTP服務(wù)器為67，BOOTP客戶為68。這意味著BOOTP客戶不會(huì)選擇未用的臨時(shí)端口，而只用端口68。選擇兩個(gè)端口而不是僅選擇一個(gè)端口為BOOTP服務(wù)器用的原因是：服務(wù)器的應(yīng)答可以進(jìn)行廣播（但通常是不用廣播的）。
如果服務(wù)器的應(yīng)答是通過廣播傳送的，同時(shí)客戶又選擇未用的臨時(shí)端口，那么這些廣播也能被其他的主機(jī)中碰巧使用相同臨時(shí)端口的應(yīng)用進(jìn)程接收到。因此，采用隨機(jī)端口（即臨時(shí)端口）對(duì)廣播來說是一個(gè)不好的選擇。
如果客戶也使用服務(wù)器的知名端口（67）作為它的端口，那么網(wǎng)絡(luò)內(nèi)的所有服務(wù)器會(huì)被喚醒來查看每個(gè)廣播應(yīng)答（如果所有的服務(wù)器都被喚醒，它們將檢查操作碼，如果是一個(gè)應(yīng)答而不是請(qǐng)求，就不作處理）。因此可以讓所有的客戶使用與服務(wù)器知名端口不同的同一知名端口。
如果多個(gè)客戶同時(shí)進(jìn)行系統(tǒng)引導(dǎo)，并且服務(wù)器廣播所有應(yīng)答，這樣每個(gè)客戶都會(huì)收到其他客戶的應(yīng)答。客戶可以通過BOOTP首部中的事務(wù)標(biāo)識(shí)字段來確認(rèn)應(yīng)答是否與請(qǐng)求匹配，或者可以通過檢查返回的客戶硬件地址加以區(qū)分。
16.3 一個(gè)例子
讓我們看一個(gè)用BOOTP引導(dǎo)一個(gè)X終端的例子。圖16-3顯示了tcpdump的輸出結(jié)果（例中客戶名為proteus，服務(wù)器名為mercury。這個(gè)tcpdump的輸出是在不同的網(wǎng)絡(luò)上獲得的，這個(gè)應(yīng)用程序是其他例子中一直使用的）。
在第1行中，我們看到客戶請(qǐng)求來自0.0.0.0.68，發(fā)送目的站是255.255.255.255.67。該客戶已經(jīng)填寫的字段是秒數(shù)和自身的以太網(wǎng)地址。我們看到客戶通常將秒數(shù)設(shè)置為1 0 0。tcpdump沒有顯示跳數(shù)和事務(wù)標(biāo)識(shí)，因?yàn)樗鼈兙鶠?(事務(wù)標(biāo)識(shí)為0表示該客戶忽略這個(gè)字段，因?yàn)槿绻蛩銓?duì)返回響應(yīng)進(jìn)行驗(yàn)證，它將把這個(gè)字段設(shè)置為一個(gè)隨機(jī)數(shù)值)。
第2行是服務(wù)器返回的應(yīng)答。由服務(wù)器填寫的字段是該客戶的IP地址（tcpdump顯示為名字proteus）、服務(wù)器的IP地址（顯示為名字mercury）、網(wǎng)關(guān)的IP地址（顯示為名字mercury）和引導(dǎo)文件名。
在收到BOOTP應(yīng)答后，該客戶立即發(fā)送一個(gè)ARP請(qǐng)求來了解網(wǎng)絡(luò)中其他主機(jī)是否有IP地址。跟在who-has后的名字proteus對(duì)應(yīng)目的IP地址（圖4-3），發(fā)送者的IP地址被設(shè)置為0.0.0.0。它在0.5秒后再發(fā)一個(gè)相同的ARP請(qǐng)求，之后再過0.5秒又發(fā)一個(gè)。在第3個(gè)ARP請(qǐng)求（第5行）中，它將發(fā)送者的IP地址改變?yōu)樗约旱腎P地址。這是一個(gè)沒有意義的ARP請(qǐng)求（見4.7節(jié)）。
第6行顯示該客戶在等待另一個(gè)0.5秒后，廣播另一個(gè)BOOTP請(qǐng)求。這個(gè)請(qǐng)求與第1行的唯一不同是此時(shí)客戶將它的IP地址寫入IP首部中。它收到來自同一個(gè)服務(wù)器的相同應(yīng)答（第7行）。該客戶在等待2秒后，又廣播一個(gè)BOOTP請(qǐng)求（第8行），同樣收到來自同一服務(wù)器的相同應(yīng)答。
該客戶等待2秒后，向它的服務(wù)器mercury發(fā)送一個(gè)ARP請(qǐng)求（第10行）。收到這個(gè)ARP應(yīng)答后，它立即發(fā)送一個(gè)TFTP讀請(qǐng)求，請(qǐng)求讀取它的引導(dǎo)文件（第12行）。文件傳送過程包括2464個(gè)TFTP數(shù)據(jù)分組和確認(rèn)，傳送的數(shù)據(jù)量為512×2463+224=1261 280字節(jié)。這將操作系統(tǒng)調(diào)入X終端。我們已在圖16-3中刪除了大多數(shù)TFTP行。
當(dāng)和圖15-2比較TFTP的數(shù)據(jù)交換過程時(shí)，要注意的是這兒的客戶在整個(gè)傳輸過程中使用TFTP的知名端口（69）。既然通信雙方中的一方使用了端口69，tcpdump就知道這些分組是TFTP報(bào)文，因此它能用TFTP協(xié)議來解釋每個(gè)分組。這就是為什么圖16-3能指明哪些包含有數(shù)據(jù)，哪些包含有確認(rèn)，以及每個(gè)分組的塊編號(hào)。在圖15-2中我們并不能獲得這些額外的信息，因?yàn)橥ㄐ烹p方均沒有使用TFTP的知名端口進(jìn)行數(shù)據(jù)傳送。由于TFTP服務(wù)器作為一個(gè)多用戶系統(tǒng)，且使用TFTP的知名端口，因此通常TFTP客戶不能使用那個(gè)端口。但這里的系統(tǒng)處于正被引導(dǎo)的過程中，無法提供一個(gè)TFTP服務(wù)器，因此允許該客戶在傳輸期間使用TFTP的知名端口。這也暗示在mercury上的TFTP服務(wù)器并不關(guān)心客戶的端口號(hào)是什么—它只將數(shù)據(jù)傳送到客戶的端口上，而不管發(fā)生了什么。
從圖16-3可以看出在9秒內(nèi)共傳送了1261 280字節(jié)。數(shù)據(jù)速率大約為140 000 bps。這比大多數(shù)以FTP文件傳送形式訪問一個(gè)以太網(wǎng)要慢，但對(duì)于一個(gè)簡單的停止等待協(xié)議如TFTP來說已經(jīng)很好了。
X終端系統(tǒng)引導(dǎo)后，還需使用TFTP傳送終端的字體文件、某些DNS名字服務(wù)器查詢，然后進(jìn)行X協(xié)議的初始化。圖16-3中的所有步驟大概需要15秒鐘，其余的步驟需要6秒鐘，這樣無盤X終端系統(tǒng)引導(dǎo)的總時(shí)間是21秒。
16.4 BOOTP服務(wù)器的設(shè)計(jì)
BOOTP客戶通常固化在無盤系統(tǒng)只讀存儲(chǔ)器中，因此了解BOOTP服務(wù)器的實(shí)現(xiàn)將更有意義。
首先，BOOTP服務(wù)器將從它的熟知端口（67）讀取UDP數(shù)據(jù)報(bào)。這沒有特別的地方。它不同于RARP服務(wù)器（5.4節(jié)），它必須讀取類型字段為“RARP請(qǐng)求”的以太網(wǎng)幀。BOOTP協(xié)議通過將客戶的硬件地址放入BOOTP分組中，使得服務(wù)器很容易獲取客戶的硬件地址(圖16-2)。
這里出現(xiàn)了一個(gè)有趣的問題：TFTP服務(wù)器如何能將一個(gè)響應(yīng)直接送回BOOTP客戶？這個(gè)響應(yīng)是一個(gè)UDP數(shù)據(jù)報(bào)，而服務(wù)器知道該客戶的IP地址（可能通過讀取服務(wù)器上的配置文件）。但如果這個(gè)客戶向那個(gè)IP地址發(fā)送一個(gè)UDP數(shù)據(jù)報(bào)（正常情況下會(huì)處理UDP的輸出），BOOTP服務(wù)器的主機(jī)就可能向那個(gè)IP地址發(fā)送一個(gè)ARP請(qǐng)求。但這個(gè)客戶不能響應(yīng)這個(gè)ARP請(qǐng)求，因?yàn)樗€不知道它自己的IP地址！（這就是在RFC951中被稱作“雞和蛋”的問題。）
有兩種解決辦法：第一種，通常被Unix服務(wù)器采用，是服務(wù)器發(fā)一個(gè)ioctl(2)請(qǐng)求給內(nèi)核，為該客戶在ARP高速緩存中設(shè)置一個(gè)條目（這就是命令arp-s所做的工作，見4.8節(jié)）。服務(wù)器能一直這么做直到它知道客戶的硬件地址和IP地址。這意味著當(dāng)服務(wù)器發(fā)送UDP數(shù)據(jù)報(bào)（即BOOTP應(yīng)答）時(shí)，服務(wù)器的ARP將在ARP高速緩存中找到該客戶的IP地址。
另一種可選的解決辦法是服務(wù)器廣播這個(gè)BOOTP應(yīng)答而不直接將應(yīng)答發(fā)回該客戶。既然通常期望網(wǎng)絡(luò)廣播越少越好，因此這種解決方案應(yīng)該只在服務(wù)器無法在它的ARP高速緩存設(shè)置一個(gè)條目的情況下使用。通常只有擁有超級(jí)用戶權(quán)限才能在ARP高速緩存設(shè)置一個(gè)條目，如果沒有這種權(quán)限就只能廣播BOOTP應(yīng)答。
16.5 BOOTP穿越路由器
我們?cè)?.4節(jié)中提到RARP的一個(gè)缺點(diǎn)就是它使用鏈路層廣播，這種廣播通常不會(huì)由路由器轉(zhuǎn)發(fā)。這就需要在每個(gè)物理網(wǎng)絡(luò)內(nèi)設(shè)置一個(gè)RARP服務(wù)器。如果路由器支持BOOTP協(xié)議，那么BOOTP能夠由路由器轉(zhuǎn)發(fā)（絕大多數(shù)路由器廠商的產(chǎn)品都支持這個(gè)功能）。
這個(gè)功能主要用于無盤路由器，因?yàn)槿绻诖疟P的多用戶系統(tǒng)被用作路由器，它就能夠自己運(yùn)行BOOTP服務(wù)器。此外，常用的Unix BOOTP服務(wù)器（附錄F）支持這種中繼模式（relay mode）。但如果在這個(gè)物理網(wǎng)絡(luò)內(nèi)運(yùn)行一個(gè)BOOTP服務(wù)器，通常沒有必要將BOOTP請(qǐng)求轉(zhuǎn)發(fā)到在另外網(wǎng)絡(luò)中的另一個(gè)服務(wù)器。
研究一下當(dāng)路由器（也稱作“BOOTP中繼代理”）在服務(wù)器的熟知端口（67）接收到BOOTP請(qǐng)求時(shí)將會(huì)發(fā)生什么。當(dāng)收到一個(gè)BOOTP請(qǐng)求時(shí)，中繼代理將它的IP地址填入收到BOOTP請(qǐng)求中的“網(wǎng)關(guān)IP地址字段”，然后將該請(qǐng)求發(fā)送到真正的BOOTP服務(wù)器（由中繼代理填入網(wǎng)關(guān)字段的地址是收到的BOOTP請(qǐng)求接口的IP地址）。該代理中繼還將跳數(shù)字段值加1（這是為防止請(qǐng)求被無限地在網(wǎng)絡(luò)內(nèi)轉(zhuǎn)發(fā)。RFC 951認(rèn)為如果跳數(shù)值到達(dá)3就可以丟棄該請(qǐng)求）。既然發(fā)出的請(qǐng)求是一個(gè)單播的數(shù)據(jù)報(bào)（與發(fā)起的客戶的請(qǐng)求是廣播的相反），它能按照一定的路由通過其他的路由器到達(dá)真正的BOOTP服務(wù)器。真正的BOOTP服務(wù)器收到這個(gè)請(qǐng)求后，產(chǎn)生BOOTP應(yīng)答，并將它發(fā)回中繼代理，而不是請(qǐng)求的客戶。既然請(qǐng)求網(wǎng)關(guān)字段不為零，真正的BOOTP服務(wù)器知道這個(gè)請(qǐng)求是經(jīng)過轉(zhuǎn)發(fā)的。中繼代理收到應(yīng)答后將它發(fā)給請(qǐng)求的客戶。
16.6 特定廠商信息
在圖16-2中我們看到了64字節(jié)的“特定廠商區(qū)域”。RFC 1533 [Alexander and Droms 1993]定義了這個(gè)區(qū)域的格式。這個(gè)區(qū)域含有服務(wù)器返回客戶的可選信息。
如果有信息要提供，這個(gè)區(qū)域的前4個(gè)字節(jié)被設(shè)置為IP地址99.130.83.99。這可稱作魔術(shù)甜餅(magic cookie)，表示該區(qū)域內(nèi)包含信息。
這個(gè)區(qū)域的其余部分是一個(gè)條目表。每個(gè)條目的開始是1字節(jié)標(biāo)志字段。其中的兩個(gè)條目僅有標(biāo)志字段：標(biāo)志為0的條目作為填充字節(jié)（為使后面的條目有更好的字節(jié)邊界），標(biāo)志為255的條目表示結(jié)尾條目。第一個(gè)結(jié)尾條目后剩余的字節(jié)都應(yīng)設(shè)置為這個(gè)數(shù)值（255）。
除了這兩個(gè)1字節(jié)的條目，其他的條目還包含一個(gè)單字節(jié)的長度字段，后面是相應(yīng)的信息。圖16-4顯示了廠商說明區(qū)域中一些條目的格式。
子網(wǎng)掩碼條目和時(shí)間值條目都是定長條目，因?yàn)樗鼈兊闹悼偸钦?個(gè)字節(jié)。時(shí)間偏移值是從1900年1月1日0時(shí)以來的秒數(shù)（UTC）。
網(wǎng)關(guān)條目是變長條目。長度通常是4的倍數(shù)，這個(gè)值是一個(gè)或多個(gè)供客戶使用的網(wǎng)關(guān)（路由器）的IP地址。返回的第一個(gè)必須是首選的網(wǎng)關(guān)。
RFC 1533還定義了其他14個(gè)條目。其中最重要的可能是DNS名字服務(wù)器的IP地址條目，條目的志為6。其他的條目包括打印服務(wù)器、時(shí)間服務(wù)器等的IP地址。詳細(xì)情況可參考RFC文檔。
回到在圖16-3中的例子，我們從未看到客戶廣播一個(gè)ICMP地址掩碼請(qǐng)求（6.3節(jié)）來獲取它的子網(wǎng)掩碼。盡管tcpdump不能顯示出來，但我們可認(rèn)為客戶所在網(wǎng)絡(luò)的子網(wǎng)掩碼在返回的BOOTP應(yīng)答的廠商說明區(qū)域內(nèi)。
Host Requirements RFC文檔推薦一個(gè)系統(tǒng)使用BOOTP來獲悉它的子網(wǎng)掩碼，而不是采用ICMP。
廠商說明區(qū)域的大小被限制為64字節(jié)。這對(duì)某些應(yīng)用是個(gè)約束。一個(gè)新的稱為動(dòng)態(tài)主機(jī)配置協(xié)議DHCP（Dynamic Host Configuration Protocol）已經(jīng)出現(xiàn)，但它不是替代BOOTP的。DHCP將這個(gè)區(qū)域的長度擴(kuò)展到312字節(jié)，它在RFC 1541 [Droms 1993] 中定義。
16.7 小結(jié)
BOOTP使用UDP，它為引導(dǎo)無盤系統(tǒng)獲得它的IP地址提供了除RARP外的另外一種選擇。BOOTP還能返回其他的信息，如路由器的IP地址、客戶的子網(wǎng)掩碼和名字服務(wù)器的IP地址。
既然BOOTP用于系統(tǒng)引導(dǎo)過程，一個(gè)無盤系統(tǒng)需要下列協(xié)議才能在只讀存儲(chǔ)器中完成：BOOTP、TFTP、UDP、IP和一個(gè)局域網(wǎng)的驅(qū)動(dòng)程序。
BOOTP服務(wù)器比RARP服務(wù)器更易于實(shí)現(xiàn)，因?yàn)锽OOTP請(qǐng)求和應(yīng)答是在UDP數(shù)據(jù)報(bào)中，而不是特殊的數(shù)據(jù)鏈路層幀。一個(gè)路由器還能作為真正BOOTP服務(wù)器的代理，向位于不同網(wǎng)絡(luò)的真正BOOTP服務(wù)器轉(zhuǎn)發(fā)客戶的BOOTP請(qǐng)求。
