百科解釋
英文原義:Bootstrap Protocol 中文釋義:自舉協(xié)議 注解:該協(xié)議是一個基于TCP/IP協(xié)議的協(xié)議,它可以讓無盤站從一個中心服務器上獲得IP地址,為局域網中的無盤工作站分配動態(tài)IP地址,并不需要每個用戶去設置靜態(tài)IP地址。使用BOOTP協(xié)議的時候,一般包括Bootstrap Protocol Server(自舉協(xié)議服務端)和Bootstrap Protocol Client(自舉協(xié)議客戶端)兩部分。 應 用:該協(xié)議主要用于有無盤工作站的局域網中,客戶端獲取IP地址的過程如下:首先,由BOOTP啟動代碼啟動客戶端,這個時候客戶端還沒有IP地址,使用廣播形式以IP地址0.0.0.0向網絡中發(fā)出IP地址查詢要求。接著,運行BOOTP協(xié)議的服務器接收到這個請求,會根據(jù)請求中提供的MAC地址找到客戶端,并發(fā)送一個含有IP地址、服務器IP地址、網關等信息的FOUND幀。最后,客戶端會根據(jù)該FOUND幀來通過專用TFTP服務器下載啟動鏡像文件,模擬成磁盤啟動。 本RFC描述一種IP/UDP引導協(xié)議(BOOTP),允許一個無盤客戶端發(fā)現(xiàn)自己的IP地址, 服務器主機的地址,和裝入一個指定名稱的文件到內存并且運行。引導操作有兩階段組成。 本RFC描述第一個階段:'分配地址和選擇引導文件'。 在獲得地址和文件名信息后,就進入引導的第二個階段:文件傳送。 文件傳送一般使用TFTP協(xié)議[9],因為兩個階段均駐留在客戶端的PROM中。 但BOOTP也能夠與其它協(xié)議如SFTP或FTP一起工作。 我們建議客戶端的PROM軟件提供一種無須用戶交互的完整的引導方式。 這是一種無人值守的上電啟動方式。 必須提供一種機制來讓用戶手工提供地址和文件名信息旁路BOOTP協(xié)議直接進入文件傳送 階段。 如果提供非可變存儲,我們建議在那里保存設置以旁路BOOTP協(xié)議直到這些設置導致文件 傳送階段失敗。 如果緩存的信息失敗,引導后退到第一階段并使用BOOTP。 協(xié)議的要點: 1.使用了一個單獨的包交換(信息)。使用超時機制直到收到應答。 雙向使用相同的包字段結構。使用(最大可能長度的)固定長度的字段來簡化結構定義 和分析。 2.一個'opcode'字段包含兩個值?蛻舳藦V播一個'引導請求(bootrequest)'包。 服務器應答一個'引導應答(bootreply)'包。'bootrequest'包含客戶端的硬件地址,如果知道, 還包含它的IP地址。 3.請求可以包含客戶端指定的響應服務器的名稱。 這樣客戶端可以強制從一個指定的主機引導。(如果一個相同的引導文件存在多種版本 或服務器在一個遠距離的網絡/域。) 客戶端不必處理名稱/域服務,這個功能推到了BOOTP服務器。 4.請求可以包含'通用(generic)'引導文件名。例如'unix'或'ethertip'。但服務器發(fā)送 引導應答時,它使用對應的引導文件的確切的路徑名稱來取代這個字段。 服務器查詢客戶端的地址和請求文件名相關的數(shù)據(jù)庫,以使用客戶端自定義的特定引導 文件確定這個文件名稱。 如果引導請求文件名是空字符串,服務器返回一個帶有客戶端加載的默認文件的文件名 字段。 5.客戶端不知道它們的IP地址的情況下, 服務器必須有一個硬件地址和IP地址對應的數(shù)據(jù)庫。 這個客戶端IP地址被放在引導應答的(對應)字段中。 6.某些網絡拓樸(如斯坦福的網絡)可能在一個物理網上沒有一個直接可以訪問的TFTP 服務器 (例如在某些網上的所有的網關和主機都可能是無盤的)。 BOOTP允許客戶端通過使用相鄰的網關從幾跳外的服務器上引導。請看下面'通過網關 引導'的章節(jié)。 這部分協(xié)議不需求客戶端部分做特定的動作。 實現(xiàn)是可選的,網關和服務器需要一些額外的代碼。 2 包格式 除非另外指出,所有顯示的數(shù)字都是十進制的。 簡化起見,假設BOOTP包不會被分片。 所有數(shù)字的字段使用標準網絡字節(jié)順序。即,先傳送高位比特。 在引導請求的IP頭中,客戶端如果知道就填自己的IP源地址,否則填0。當服務器地址不知 道時, IP目的地址將是廣播地址255.255.255.255。這個地址意味著'在本地網上廣播,我不知道我的 網絡號'[4]。 UDP頭包含源和目的端口號。BOOTP協(xié)議使用兩個保留的端口號,'BOOTP客戶端'(68) 和'BOOTP服務器'(67)。 客戶使用'BOOTP服務器'做為目的端口發(fā)送請求;這通常是廣播。 服務器使用'BOOTP客戶端'做為目的端口發(fā)送應答;取決于服務器的核心或驅動設備,這可 能是也可能不是廣播 (在下面'雞和蛋的問題'標題的章節(jié)中深入解釋)。 使用兩個保留的端口的原因是當引導應答必須廣播到客戶端避免'叫醒'并且調度BOOTP服 務器進程。 因為服務器和其它主機都不會偵聽'BOOTP客戶端'端口, 所有進入的廣播報文將在核心級別過濾掉。 我們不能簡單地允許客戶端找一個隨機端口號做為UDP源端口字段;因為服務器應答可能 是廣播, 一個隨機選擇的端口號可能搞亂其它恰巧在偵聽那個端口的主機。 UDP長度字段設置成UDP長度加BOOTP部分的包。 UDP校驗和可以由客戶端(或服務器)按照需要設置成0,以避免PROM實現(xiàn)中額外的費用。 在下面的'包處理'章節(jié)中'[UDP校驗和]'短語用來表示校驗和可能被驗證/計算。 字段 字節(jié)數(shù) 描述 ----- ----- ----------- op 1 packet op code / message type. 包操作碼/消息類型 1 = BOOTREQUEST(引導請求), 2 = BOOTREPLY(引導應答) htype 1 hardware address type, 硬件地址類型 see ARP section in "Assigned Numbers" RFC. 請看"Assigned Numbers" RFC中的ARP章節(jié) '1' = 10mb ethernet 10M以太網 hlen 1 hardware address length 硬件地址長度 (eg '6' for 10mb ethernet). 例如'6'是10M以太網 hops 1 client sets to zero, 客戶端設置成0 optionally used by gateways 在跨越網關引導時網關可選擇使用 in cross-gateway booting. xid 4 transaction ID, a random number, used to match this boot request with the responses it generates. 事務ID,一個隨機數(shù),用來匹配引用請求和應答 secs 2 filled in by client, seconds elapsed since client started trying to boot. 由客戶端填寫,客戶端引導開始后的過去的秒數(shù) -- 2 unused未使用 ciaddr 4 client IP address;客戶端IP地址, filled in by client in bootrequest if known.如果客戶端知道就在引導請求中填入 yiaddr 4 'your' (client) IP address;'你的'(客戶端)IP地址 filled by server if client doesn't know its own address (ciaddr was 0).如果客戶端不知道它的地址(ciaddr是0),服務器填入 siaddr 4 server IP address;服務器IP地址 returned in bootreply by server.由服務器在引導應答返回 giaddr 4 gateway IP address,網關IP地址 used in optional cross-gateway booting.在跨越網關引導中可以選擇使用 chaddr 16 client hardware address,客戶端硬件地址 filled in by client.由客戶端填寫 sname 64 optional server host name,可選的服務器主機名 null terminated string. 空結束的字符串 file 128 boot file name, null terminated string; 引導文件名,空結束的字符串 'generic' name or null in bootrequest, 在引導請求中使用'通用'名稱或空 fully qualified directory-path 是引導應答中使用確切的目錄路徑名稱 name in bootreply. vend 64 optional vendor-specific area, 可選的賣主指定的區(qū)域, e.g. could be hardware type/serial on request, 例如,可以是請求硬件類型/序列, or 'capability' / remote file system handle 或應答的性能/遠端文件系統(tǒng)句柄。 on reply. This info may be set aside for use 這些信息留給第三方分析引導或核心(程序)使用。 by a third phase bootstrap or kernel. 3 雞和蛋的問題 如果客戶端不知道自己IP地址,服務器怎么發(fā)送IP報文到客戶端。 無論何時一條引導應答被發(fā)送,發(fā)送設備執(zhí)行下列操作: 1.如果客戶端知道自己的IP地址('ciaddr'字段非零), 因為客戶端能夠回應ARPs[5],那么IP能夠正常發(fā)送。 2.如果客戶端還不知道自己的IP地址(ciaddr是零), 客戶端就不能回應引導應答發(fā)送程序回的ARPs。這時有兩種選擇: a.如果發(fā)送程序有必需的核心或驅動鉤子程序來人工建立ARP地址緩沖條目, 就可以使用'chaddr'和'yiaddr'字段填入一個條目。當然,這個條目象正常ARP建立的 其它條目一樣有一個生命時間, 引導應答的發(fā)送程序就能夠簡單地發(fā)送引導應答到客戶端的IP地址了。UNIX(4.2 BSD)有這種功能。 b.如果發(fā)送程序缺少這些核心鉤子程序,就只能簡單發(fā)送引導應答到相應接口的廣播 地址。 這只是在前面情況外的額外的廣播。 4 ARP在客戶端使用 客戶端PROM必須包含一個ARP的簡單實現(xiàn),例如,地址緩沖能夠容納一個條目。 這將允許客戶端在知道IP地址和引導文件名后執(zhí)行第二階段引導(TFTP)。 任何時候客戶端應該準備回應一個自己IP到硬件地址映射的ARP請求(如果知道)以接收 TFTP或BOOTP應答。 因為引導應答將包含服務器/網關的硬件源地址(在硬件中封裝),客戶端可以 避免發(fā)送一條ARP請求來申請后續(xù)的TFTP階段使用的服務器/網關IP地址。 但這應該只是一種特殊情況,因為上面描述的只有第二階段的引導仍然允許。 5 與RARP對照 提議客戶端使用一個早先的協(xié)議,反向地址解析協(xié)議(RARP)[1]來通過它的硬件地址確定自 己的IP地址。 但RARP的劣勢是它是一個硬件鏈路層的協(xié)議(不是基于IP/UDP)。 這意味著RARP只能在包含特殊的為訪問原始報文修改的核心和驅動的主機上實現(xiàn)。 因為現(xiàn)在存在不同組織維護的許多網絡核心,一個不要求修改核心的引導協(xié)議是一個確定 的優(yōu)勢。 BOOTP除了上述章節(jié)描述的有用的特性外,還提供硬件到IP地址的查詢功能。 6 包處理 6.1客戶端傳送 在第一次建立包前,最好把整個包的緩沖區(qū)清零; 這將所有的字段設置成默認狀態(tài)。任何客戶端建立包中的下列字段。 IP目的地址被設置成255.255.255.255(廣播地址)或服務器的IP地址(如果知道)。 IP源地址和'ciaddr'設置成客戶端IP地址(如果知道),或者0。UDP頭使用適當?shù)拈L度設 置; 源端口='BOOTP客戶端'端口,目標端口='BOOTP服務器'端口。 'op'設置成'1',BOOTREQUEST(引導請求)。'htype'設置成在"Assigned Numbers"RFCARP章節(jié)中分配的硬件地址類型。 'hlen'設置成硬件地址長度,例如,10M以太網是'6'。 'xid'設置成一個'隨機'事務ID。'secs'設置成客戶端引導開始后過去的秒數(shù)。 這個讓服務器知道客戶端已經試了多長時間了。 當數(shù)字變大,某些服務器可能更多注意這個客戶端提供不同的服務。 如果客戶端缺少一個適當?shù)臅r鐘,它可以使用循環(huán)定時器建立一個粗略的估計值。 或者它可以選擇簡單發(fā)送使用一個固定值如100秒的字段。 如果客戶端知道IP地址,'ciaddr'(和IP源地址)設置成這個值。 'chaddr'使用客戶端硬件地址填寫。 如果客戶端希望限制從一個特定服務器名引導,就可以在'sname'中放一個空結束的字符 串。 使用的名字應該是對應的主機的正當?shù)拿只騽e名。 客戶端在填寫'file'文件名字段是有許多選擇。 如果設置成空,意味著'我向使用默認的文件來引導我的機器'。一個空文件名也意味著 '我只對找到客戶端/服務器/網關的IP地址感興趣,我不在乎文件名'。 這個字段也可以是一個'通用'名字入'unix'或'gateway';這意味著 '使用命名的程序配置來引導我的機器'。最后這個字段可以是確切的目錄路徑名字。 'vend'字段可以由客戶端填寫賣主的字符串或結構。例如可以填寫機器硬件類型或序列 號。 但BOOTP服務器的操作應該不依賴與這些存在的信息。 如果使用了'vend',推薦在'vend'中第一個項目為一個4字節(jié)的'魔術字(magicnumber)'。 這讓服務器確定在這個字段中它看到什么類型的信息。 數(shù)值可以由通常的'魔術字'過程分配,你挑一個,它就成為魔術字。 引導應答使用一個與引導請求不同的魔術字以允許客戶端按照應答信息進行特殊的動 作。 [UDP校驗和] 6.2客戶端重傳策略 在一長段時間內沒有收到應答,客戶端應該重傳請求。 時間間隔必須仔細選擇不要引起網絡風暴。 可以考慮一個包含100臺機器的網絡在電源故障后發(fā)生的情況。 簡單的每四秒重傳請求將淹沒網絡。 一個可能的策略,你可能考慮指數(shù)級的補償,象以太網在碰撞時那樣。 例如第一個包在0:00,第二個在:04,接著:08,接著:16,:32,:64。 你應該隨機化每個時間;這就象以太網規(guī)格那樣以一個掩碼'與'一個隨機數(shù)進入第一次補 償。 在每次后續(xù)的補償中,掩碼增長一個比特。 這樣在每次補償中平均延遲加倍。 在'平均'補償?shù)竭_60秒后,就不再增長了,但仍然隨機化。 在每次重傳前,客戶端應該修改'secs'字段。[UDP校驗和] 6.3服務器接收BOOTREQUEST(引導請求) [UDP校驗和]如果UDP目的端口不匹配'BOOTP服務器'端口,丟棄這個包。 如果服務器名字字段(sname)是空(沒有指定特定的服務器),或者sname是指定的并且 匹配我們的名字或別名, 繼續(xù)包的處理。 如果sname字段是指定的,但不匹配'我們',那么有多種選擇: 1.你可以選擇簡單丟棄這個包。 2.如果查詢sname的名稱顯示它在一個網絡中,丟棄這個包。 3.如果sname在不同的網絡中,你可以選擇轉發(fā)這個包到那個地址。 如果這樣,檢查'giaddr'(網關地址)字段。如果'giaddr'是0,填入我的地址或可以用來 到達那個網絡的網關的地址。 然后轉發(fā)這個包。 如果客戶端IP地址(ciaddr)是0,那么客戶端不知道自己的IP地址。 嘗試在我們的數(shù)據(jù)庫中查找客戶端的硬件地址(chaddr,hlen,htype)。 如果沒有匹配,丟棄這個包。否則我們現(xiàn)在對這個客戶端有一個IP地址;填入'yiaddr'(你 的IP地址)字段。 我們現(xiàn)在檢查引導文件名字段(文件)。如果客戶端不關注文件名或想要默認引導文件, 這個字段是空。 如果這個字段非空,可以將它和客戶端的IP地址做為數(shù)據(jù)庫的查詢關鍵字。 如果有默認的文件或通用文件(可能由客戶端地址做為索引)或一個匹配的指定的路徑 名稱, 然后在'file'字段中填入選擇的引導文件的指定的路徑名稱。 如果字段是非空并且沒有匹配,那么客戶端要一個我們沒有的文件,丟棄這個包,也許 其它BOOTP服務器有這個文件。 賣主指定的數(shù)據(jù)字段'vend'現(xiàn)在應該檢查了。如果提供一種可識別類型的數(shù)據(jù), 應該進行客戶端指定的動作,并且回應要填入應答包中的'vend'數(shù)據(jù)字段。 例如,一個工作站客戶端可能提供一個驗證字,并從服務器接收一個訪問遠端文件的權 限, 或一套配置選項傳給馬上就要引導入的操作系統(tǒng)。 我的(服務器)IP地址填入'siaddr'字段。設置'op'字段為BOOTREPLY(引導應答)。 UDP目的端口設置成'BOOTP客戶端'。如果客戶端地址'ciaddr'非0,把包發(fā)送到那里; 否則如果網關地址'giaddr'非0,設置UDP目的端口為'BOOTP服務器'并把包發(fā)送到 'giaddr'。 否則客戶端在我們的一個網絡中但它還不知道自己的IP地址,使用在上面'蛋'章節(jié)中描述 的方法來傳送它到客戶端。 如果使用'蛋'并且我們在主機上有許多接口,使用'yiaddr'(你的IP地址)字段指出發(fā)送包 到哪個網絡(網絡/接口)。 [UDP校驗和] 6.4服務器/網關接收BOOTREPLY(引導應答) [UDP校驗和]如果'yiaddr'(你的[客戶端的]IP地址)指向我們的一個網絡,使用上述'蛋'方 法來將它轉發(fā)到客戶端。 確認將它傳送到'BOOTP客戶端'UDP目的端口。 6.5客戶端接收 不要忘記為我自己的IP地址(如果我知道)處理ARP請求。[UDP校驗和] 客戶端應該丟棄以下進入的包:不是定位到引導端口的IP/UDP;不是BOOTREPLY(引 導應答); 不匹配我的IP地址(如果我知道)或我的硬件地址;不匹配我的事務ID。 否則我們就收到一個成功的應答。如果我以前不知道的話,'yiaddr'包含我的IP地址。 'file'是TFTP'讀請求'的文件名。服務器地址在'siaddr'中。如果'giaddr'(網關地址)非0, 那么包應該先轉發(fā)到那里,然后到達服務器。 7 通過網關引導 這部分協(xié)議是可選的并要求許多網關和服務器配合的額外的代碼,但它允許跨越網關引導。 這主要在網關是無盤機器時有用。 帶盤網關(例如,一個做為網關的UNIX機器)可能運行它們自己的BOOTP/TFTP服務器。 偵聽BOOTREQUEST(引導請求)廣播的網關可能確定轉發(fā)還是適當?shù)卦購V播這些請求。 例如,做為配置表格的一部分,網關可以有一個接收任意BOOTREQUEST(引導請求)廣 播的其它網絡或主機的列表。 即使考慮有一個'hops'字段,簡單全部再廣播請求仍是一個差的方法,因為廣播循環(huán)幾乎肯 定會發(fā)生。 轉發(fā)可以立即開始,或等'secs'(客戶端嘗試的秒數(shù))字段超過某個閥值。 如果一個網關確定轉發(fā)請求,它應該查看'giaddr'(網關IP地址)字段。 如果是0,它就在這個字段中加入自己的IP地址(在接收的網絡中)。 也可以使用'hops'字段來可選控制包可以轉發(fā)多遠。每次轉發(fā)應該增加跳數(shù)。 例如,如果跳數(shù)超過'3',包應該被丟棄。 [UDP校驗和] 這里我們推薦在網關中增加這個特殊的轉發(fā)功能。 但不總是這樣子的。 在網上存在一些'BOOTP轉發(fā)代理'引導客戶端,這些代理可以適當?shù)剞D發(fā)。 這樣這些服務可以和網關在一起,也可以不在一起。 當轉發(fā)代理不和網關在一起時,代理可以通過在接收的引導請求中'giaddr'字段加上接口的廣 播地址節(jié)省一些工作。 這樣應答就可以使用普通的網關來轉發(fā),而不包含轉發(fā)代理。 當然劣勢是你失去了使用'蛋'非廣播方式來發(fā)送應答的能力,導致在客戶端網上的每個主機 的額外的花費。
移動通信網 | 通信人才網 | 更新日志 | 團隊博客 | 免責聲明 | 關于詞典 | 幫助