TCP/IP基礎(chǔ)：DNSDHCPICMP和ARP 協(xié)議DNS 的來由如果您為您的機器設(shè)定過 internet 連線﹐那么您一定接觸過 DNS 了﹐但 DNS 又是什么東東呢﹖說穿了﹐DNS 是用來幫助

TCP/IP基礎(chǔ)：DNSDHCPICMP和ARP 協(xié)議

DNS 的來由

如果您為您的機器設(shè)定過 internet 連線﹐那么您一定接觸過 DNS 了﹐但 DNS 又是什么東東呢﹖說穿了﹐DNS 是用來幫助記憶網(wǎng)路位址的﹐完全是為了遷就人類的記憶思維而設(shè)的。

DNS 的全稱是 Domain Name System(或 Service) ﹐當(dāng)您連上一個網(wǎng)址﹐在URL 打上﹕www.google.com 的時候﹐可以說就是使用了 DNS 的服務(wù)了。但如果您知道這個 www.google.com 的 IP 位址﹐直接輸入 216.239.53.101 也同樣可以到達(dá)這個網(wǎng)址。其實﹐電腦使用的只是 IP 位址而已(最終也是 0 和 1 啦) ﹐這個 www.google.com 只是讓人們?nèi)菀子洃浂O(shè)的。因為我們?nèi)祟惄o對一些比較有意義的文字記憶(如﹕www.google.com) ﹐比記憶那些毫無頭緒的號碼(如﹕216.239.53.101) ﹐往往容易得多。DNS 的作用就是為我們在文字和 IP 之間擔(dān)當(dāng)了翻譯﹐而免除了強記號碼的痛苦。

假如您的電話有名字記憶功能﹐您只需知道對方的名字﹐就可以撥號給友人了﹐我們可以說﹐這電話也具備如 DNS 的功能了呢﹗但是﹐我們在網(wǎng)路中使用的 DNS 系統(tǒng)﹐就是這么簡單嗎﹖非也﹐復(fù)雜得很呢﹗下面﹐就讓我們一起去探索一下 DNS 的奧秘﹕

在早期的 IP 網(wǎng)路世界里面﹐每臺電腦都只用 IP 位址來表示﹐不久人們就發(fā)現(xiàn)這樣很難記憶﹐于是﹐一些Unix 的管理者﹐就建立一個 HOSTS 對應(yīng)表﹐將 IP 和主機名字對應(yīng)起來﹐這樣﹐用戶只需輸入電腦名字﹐就可以代替 IP 來進(jìn)行溝通了。如果你安裝了 Linux 系統(tǒng)﹐在 /etc下面就可以找到這個 hosts 檔案﹔在 NT 的系統(tǒng)里﹐你也可以在 winntsystem32driversetc下面找到它。不過這個 HOSTS 檔是要由管理者手工維護(hù)的﹐最大的問題是無法適用于大型網(wǎng)路﹐而且更新也是件非常頭痛的事情。這就是 DNS 大派用場的時候了。 DNS 的結(jié)構(gòu)

DNS 是一個分層級的分散式名稱對應(yīng)系統(tǒng)﹐有點像電腦的目錄樹結(jié)構(gòu)﹕在最頂端的是一個“root”﹐然后其下分為好幾個基本類別名稱﹐如﹕com ﹑org ﹑edu 等﹔再下面是組織名稱﹐如﹕IBM ﹑Microsoft ﹑intel 等﹔繼而是主機名稱﹐如﹕www ﹑mail ﹑ftp 等。因為當(dāng)初 internet 是從美國發(fā)展起的﹐所以當(dāng)時并沒有國域名稱﹐但隨著后來 internet 的蓬勃發(fā)展﹐DNS 也加進(jìn)了諸如tw ﹑hk ﹑cn 等國域名稱。所以一個完整的dns 名稱就好象是這樣的﹕www.xyz.com.tw ﹐而整個名稱對應(yīng)的就是一個(或多個) IP 位址了。 在早期的設(shè)計下﹐root 下面只有六個組織類別﹕

不過﹐自從組織類別名稱開放以后﹐各種各樣五花八門的名稱也相繼涌現(xiàn)出來了﹐但無論如何﹐取名的規(guī)則最好盡量適合網(wǎng)站性質(zhì)。除了原來的類別資料由美國本土的 NIC(Network Information Center) 管理之外﹐其它在國域以下的類別分別由該國的 NIC 管理(比方說臺灣的 DNS 將授權(quán)給twnic 來管理) 。這樣的結(jié)構(gòu)看起來就像這樣﹕

在結(jié)構(gòu)中﹐各組織的 DNS 經(jīng)過申請后由該組織或其委托主機管理(通常當(dāng)您申請注冊一個 domain 域名稱的時候﹐都要指定兩臺 DNS 主機負(fù)責(zé)該域名的 DNS 管理) 。

DNS 的運作

在我們設(shè)定 IP 網(wǎng)路環(huán)境的時候﹐都要告訴每臺主機關(guān)于 DNS 伺服器的位址(我們可以手動的在每一臺主機上面設(shè)置﹐也可以使用 DHCP 來指定) 。但這設(shè)定的義意何在呢? 從前面的介紹我們或可知道：其目的就是請 DNS 幫忙解析主機名稱與 IP 位址啦。在這個設(shè)定過程中，DNS 被稱為 resolver (也就是負(fù)責(zé)解析的 DNS Server)，而被設(shè)定主機，則只是單純的 DNS Client 了，也就是提出解析請求的主機。

下面讓我們看看 DNS 是怎樣運作的﹕

1. 當(dāng)被詢問到有關(guān)本域名之內(nèi)的主機名稱的時候﹐DNS 伺服器會直接做出回答﹔

2. 客戶端向伺服器提出查詢項目﹔

3. 當(dāng)被詢問到有關(guān)本域名之內(nèi)的主機名稱的時候﹐DNS 伺服器會直接做出回答﹔

4. 如果所查詢的主機名稱屬于其它域名的話﹐會檢查快取記憶體(Cache)﹐看看有沒有相關(guān)資料﹔

5. 如果沒有發(fā)現(xiàn)﹐則會轉(zhuǎn)向 root 伺服器查詢﹔

6. 然后 root 伺服器會將該域名之下一層授權(quán)(authoritative)伺服器的位址告知(可能會超過一臺) ﹔

7. 本地伺服器然后會向其中的一臺伺服器查詢﹐并將這些伺服器名單存到記憶體中﹐以備將來之需(省卻再向 root 查詢的步驟) ﹔

8. 遠(yuǎn)方伺服器回應(yīng)查詢﹔

9. 若該回應(yīng)并非最后一層的答案，則繼續(xù)往下一層查詢，直到獲的客戶端所查詢的結(jié)果為止﹔

10. 將查詢結(jié)果回應(yīng)給客戶端﹐并同時將結(jié)果儲存一個備份在自己的快取記憶里面﹔

11. 如果在存放時間尚未過時之前再接到相同的查詢﹐則以存放于快取記憶里面的資料來做回應(yīng)。

從這個過程我們可以看出﹐沒有任何一臺 DNS 主機會包含所有域名的 DNS 資料﹐資料都是分散在全部的 DNS 伺服器中﹐而 NIC 只需知道各 DNS 伺服器位址就可以了。

為了更好地理解一下 DNS 的運作﹐讓我們用下圖看看查詢

www.home.netman.com.tw 這臺主機位址的過程﹕

在這個例子中﹐www.home.netman.com.tw 臺主機的 DNS 對應(yīng)資料﹐是由負(fù)責(zé) home.netman.com.tw 這個域名的 DNS 伺服器管理的。(在 DNS 術(shù)語中﹐我們稱一個域名為“zone”﹐這個 zone 可以是您從 NIC 申請回來的域名﹐也可以是從該域名之下延伸出來的“sub-zone”)。在這臺 DNS 伺服器上面﹐必須有一個關(guān)于 home.netman.com.tw 這個 zone 的檔案﹐而這檔案里面必須有一筆關(guān)于 www 的記錄(任何主機都是以“記錄”來表示，稱為 Resource Record) 。這個記錄可以為一個 IP 位址﹐也可以以別名形式來對應(yīng)一臺主機名稱﹐但無論如何﹐所對應(yīng)的主機名稱最終是要被一個 IP 位址所對應(yīng)著就是了。 同時﹐DNS 還能提供“反查詢”(reverse lookup) 功能﹐也就是以 IP 來查詢主機名稱。網(wǎng)路上面的許多服務(wù)﹐如﹕FTP, SMTP﹑等等﹐都需要到這個功能。其實﹐DNS 服務(wù)本身就必須要使用反查詢功能﹐而且在設(shè)定上﹐也必須要為每個網(wǎng)路建立起 reverse zone。雖然有些人發(fā)覺即使沒有 reverse zone 也可以使用到 DNS 服務(wù)﹐但其中弊端卻不容易被察覺到﹐在這個(中文) 網(wǎng)頁﹕

DNS 的名稱記錄

事實上﹐DNS 不僅僅是用來解釋位址用的﹐而且還可以回答更多關(guān)于網(wǎng)路和主機的其它信息﹐其中很重要的一個功能就是可以供郵件系統(tǒng)進(jìn)行路由。這些資料﹐通常會以不同的“記錄”名稱出現(xiàn)在DNS 的資料檔案中。下面讓我們參考一個 Linux 的 DNS 檔案﹐看看這些記錄是如何表示的﹕

;; Zone file for siyongc.domain;; Then full zone file;$TTL 86400@ IN SOA RedHat 52.siyongc.domain. netman.siyongc.domain. (1999092801 ;

serial8H ; refresh2H ; retry1W ; expire1D ) ; minimun;IN TXT "A test domain, created by Netman"IN NS RedHat 52IN NS debian.homeIN MX 10

redhat52.siyongc.domain.IN MX 20 debian.home;localhost IN A 127.0.0.1﹔gw IN A 192.168.0.17IN HINFO "Redhat" "MASQ"IN TXT "The masquerade

gateway to internet"﹔redhat52 IN A 192.168.0.17IN MX 10 redhat52IN MX 20 debian.homeIN HINFO "Dell PII 266" "Linux RedHat"www IN CNAME

redhat52mail IN CNAME redhat52ftp IN CNAME redhat52news IN CNAME redhat52smtp IN CNAME redhat52﹔pii266 IN A 192.168.0.15IN MX 10 redhat52.siyongc.domain.IN MX 20 debian.home.﹔slware36 IN A

192.168.0.18IN MX 10 redhat52.siyongc.domain.IN MX 20 debian.home.﹔rhroute IN A 192.168.0.4IN MX 10 redhat52.siyongc.domain.IN MX 20

debian.home. ﹔home IN ns debian.home.siyongc.domain.debian.home IN A 10.0.2.101

我們姑且不理會開頭那幾行的意思﹐那是給 DNS 系統(tǒng)本身使用的(我將會在“學(xué)習(xí) Linux”文章里面再詳細(xì)討論) ﹐這里我們只是看看幾個記錄名稱而已﹕

分擔(dān) DNS 工作

由於 DNS 的重要性日益顯著，為提高其容錯能力及查詢效能，我們在架設(shè)某一單一 zone 的時侯，常以多臺伺服器來負(fù)責(zé)該 zone 的服務(wù)。其中，我們必需指定一臺 Primary(master) DNS 伺服器，它是架設(shè)在某一個網(wǎng)域下被主要授權(quán)並控制所有名稱記錄的主控伺服器﹐管轄著該網(wǎng)域的所有記錄資料﹐這些記錄資料只有 primary(master) 可以修改。

但如果在一個比較大型的網(wǎng)路中﹐DNS 伺服器就會變得很繁忙﹐所以您可以設(shè)定多個 DNS 來分擔(dān) master 的工作﹐但您或許不願意到每一個 DNS 伺服器去更新資料吧﹖而且就算您願意這樣做﹐也容易出現(xiàn)錯誤或資料不同步的情形。這樣您可以設(shè)定其它的伺服器為 secondary (slave) DNS 來複製 master 上面的記錄資料﹐這樣﹐其它的電腦可以被分派到不同的 DNS 做查詢﹐既可以分擔(dān) master 的工作﹐而且資料也可以自動進(jìn)行同步工作。為確保資料的一致性，master 每次更新過資料後會以 notify 機制主動通知 slave 前來同步。此外，您可以設(shè)定 DNS 資料同步的時間間隔﹐在dns 檔案中的 Refresh 設(shè)定就是了。 經(jīng)過了前面的學(xué)習(xí)，相信您不再認(rèn)為設(shè)定與管理 TCP/IP 網(wǎng)路是件輕松的事情。要成功的將您的網(wǎng)路用 TCP/IP 連接起來，您就得為每臺電腦設(shè)定 IP 、mask 、gateway 、等等繁瑣的事情。

要是您想管理好一個比較大的網(wǎng)路﹐或是電腦節(jié)點經(jīng)常改變(如手提電腦或撥接) ﹐這樣的工作可以說是非常令人討厭的﹐而且出錯的機會也比較多。要是，萬一日后要進(jìn)行 IP 重新規(guī)劃﹐其工作量也是相當(dāng)驚人的。

面對這些情形﹐DHCP 可以說您的菩薩了﹕它不但救苦救難﹐而且神通廣大。

什么是 DHCP?

DHCP 是 Dynamic Host Configuration Protocol 之縮寫﹐它的前身是 BOOTP 。BOOTP 原本是用于無磁碟主機連接的網(wǎng)路上面的﹕網(wǎng)路主機使用 BOOT ROM 而不是磁碟起動并連接上網(wǎng)路﹐BOOTP 則可以自動地為那些主機設(shè)定 TCP/IP 環(huán)境。但 BOOTP 有一個缺點：您在設(shè)定前須事先獲得客戶端的硬體位址，而且，與 IP 的對應(yīng)是靜態(tài)的。換而言之，BOOTP 非常缺乏 " 動態(tài)性" ，若在有限的 IP 資源環(huán)境中，BOOTP 的一對一對應(yīng)會造成非?？捎^的浪費。

DHCP 可以說是 BOOTP 的增強版本﹐它分為兩個部份﹕一個是伺服器端﹐而另一個是客戶端。所有的 IP 網(wǎng)路設(shè)定資料都由 DHCP 伺服器集中管理﹐并負(fù)責(zé)處理客戶端的 DHCP 要求﹔而客戶端則會使用從伺服器分配下來的IP 環(huán)境資料。比較起 BOOTP ，DHCP 透過 " 租約" 的概念，有效且動態(tài)的分配客戶端的 TCP/IP 設(shè)定，而且，作為兼容考量，DHCP 也完全照顧了 BOOTP Client 的需求。

DHCP 的分配形式

首先﹐必須至少有一臺 DHCP 工作在網(wǎng)路上面﹐它會監(jiān)聽網(wǎng)路的 DHCP 請求﹐并與客戶端搓商 TCP/IP 的設(shè)定環(huán)境。它提供兩種 IP 定位方式﹕ Automatic Allocation

自動分配﹐其情形是﹕一旦 DHCP 客戶端第一次成功的從 DHCP 伺服器端租用到 IP 位址之后﹐就永遠(yuǎn)使用這個位址。

Dynamic Allocation

動態(tài)分配﹐當(dāng) DHCP 第一次從 HDCP 伺服器端租用到 IP 位址之后﹐并非永久的使用該位址﹐只要租約到期﹐客戶端就得釋放(release)這個 IP 位址﹐以給其它工作站使用。當(dāng)然﹐客戶端可以比其它主機更優(yōu)先的延續(xù)(renew)租約﹐或是租用其它的 IP 位址。

動態(tài)分配顯然比自動分配更加靈活﹐尤其是當(dāng)您的實際 IP 位址不足的時候﹐例如﹕您是一家 ISP ﹐只能提供 200 個IP 位址用來給撥接客戶﹐但并不意味著您的客戶最多只能有 200 個。因為要知道﹐您的客戶們不可能全部同一時間上網(wǎng)的﹐除了他們各自的行為習(xí)慣的不同﹐也有可能是電話線路的限制。這樣﹐您就可以將這 200 個位址﹐輪流的租用給撥接上來的客戶使用了。這也是為什么當(dāng)您查看 IP 位址的時候﹐會因每次撥接而不同的原因了(除非您申請的是一個固定 IP ﹐通常的 ISP 都可以滿足這樣的要求﹐這或許要另外收費) 。當(dāng)然﹐ISP 不一定使用 DHCP 來分配位址﹐但這個概念和使用 IP Pool 的原理是一樣的。

DHCP 除了能動態(tài)的設(shè)定 IP 位址之外﹐還可以將一些 IP 保留下來給一些特殊用途的機器使用﹐它可以按照硬體位址來固定的分配 IP 位址﹐這樣可以給您更大的設(shè)計空間。同時﹐DHCP 還可以幫客戶端指定 router ﹑netmask ﹑DNS Server﹑WINS Server﹑等等項目﹐您在客戶端上面﹐除了將 DHCP 選項打勾之外﹐幾乎無需做任何的 IP 環(huán)境設(shè)定。

DHCP 的工作原理

視乎客戶端是否第一次登錄網(wǎng)路﹐DHCP 的工作形式會有所不同。 第一次登錄的時候﹕

1. 尋找 Server 。當(dāng) DHCP 客戶端第一次登錄網(wǎng)路的時候﹐也就是客戶發(fā)現(xiàn)本機上沒有任何 IP 資料設(shè)定﹐它會向網(wǎng)路發(fā)出一個 DHCPDISCOVER 封包。因為客戶端還不知道自己屬于哪一個網(wǎng)路﹐所以封包的來源位址會為 0.0.0.0 ﹐而目的位址則為 255.255.255.255 ﹐然后再附上Dhcpdiscover 的信息﹐向網(wǎng)路進(jìn)行廣播。

在Windows 的預(yù)設(shè)情形下，Dhcpdiscover 的等待時間預(yù)設(shè)為 1 秒﹐也就是當(dāng)客戶端將第一個Dhcpdiscover 封包送出去之后﹐在 1 秒之內(nèi)沒有得到回應(yīng)的話﹐就會進(jìn)行第二次Dhcpdiscover 廣播。若一直得不到回應(yīng)的情況下﹐客戶端一共會有四次Dhcpdiscover 廣播(包括第一次在內(nèi)) ﹐除了第一次會等待 1 秒之外﹐其余三次的等待時間分別是 9﹑13﹑16 秒。如果都沒有得到 DHCP 伺服器的回應(yīng)﹐客戶端則會顯示錯誤信息﹐宣告Dhcpdiscover 的失敗。之后﹐基于使用者的選擇﹐系統(tǒng)會繼續(xù)在 5 分鐘之后再重復(fù)一次Dhcpdiscover 的過程。

2. 提供 IP 租用位址。當(dāng) DHCP 伺服器監(jiān)聽到客戶端發(fā)出的Dhcpdiscover 廣播后﹐它會從那些還沒有租出的位址范圍內(nèi)﹐選擇最前面的的空置 IP ，連同其它 TCP/IP 設(shè)定，回應(yīng)給客戶端一個 DHCPOFFER 封包。

由于客戶端在開始的時候還沒有 IP 位址﹐所以在其Dhcpdiscover 封包內(nèi)會帶有其 MAC 位址信息﹐并且有一個 XID 編號來辨別該封包﹐DHCP 伺服器回應(yīng)的Dhcpoffer 封包則會根據(jù)這些資料傳遞給要求租約的客戶。根據(jù)伺服器端的設(shè)定﹐Dhcpoffer 封包會包含一個租約期限的信息。

3. 接受 IP 租約。如果客戶端收到網(wǎng)路上多臺 DHCP 伺服器的回應(yīng)﹐只會挑選其中一個Dhcpoffer 而已(通常是最先抵達(dá)的那個) ﹐并且會向網(wǎng)路發(fā)送一個Dhcprequest 廣播封包﹐告訴所有 DHCP 伺服器它將指定接受哪一臺伺服器提供的 IP 位址。

同時﹐客戶端還會向網(wǎng)路發(fā)送一個 ARP 封包﹐查詢網(wǎng)路上面有沒有其它機器使用該 IP 位址﹔如果發(fā)現(xiàn)該 IP 已經(jīng)被占用﹐客戶端則會送出一個 DHCPDECLINE 封包給 DHCP 伺服器﹐拒絕接受其Dhcpoffer ﹐并重新發(fā)送Dhcpdiscover 信息。

事實上﹐并不是所有 DHCP 客戶端都會無條件接受 DHCP 伺服器的 offer ﹐尤其這些主機安裝有其它 TCP/IP 相關(guān)的客戶軟體?？蛻舳艘部梢杂?/p>

Dhcprequest 向伺服器提出 DHCP 選擇﹐而這些選擇會以不同的號碼填寫在 DHCP Option Field 里面﹕

換一句話說﹐在 DHCP 伺服器上面的設(shè)定﹐未必是客戶端全都接受﹐客戶端可以保留自己的一些 TCP/IP 設(shè)定。而主動權(quán)永遠(yuǎn)在客戶端這邊。

4. 租約確認(rèn)。當(dāng) DHCP 伺服器接收到客戶端的Dhcprequest 之后﹐會向客戶端發(fā)出一個 DHCPACK 回應(yīng)﹐以確認(rèn) IP 租約的正式生效﹐也就結(jié)束了一個完整的 DHCP 工作過程。

如上的工作流程如下圖：

DHCP 發(fā)放流程

第一次登錄之后﹕

一旦 DHCP 客戶端成功地從伺服器哪里取得 DHCP 租約之后﹐除非其租約已經(jīng)失效并且 IP 位址也重新設(shè)定回 0.0.0.0 ﹐否則就無需再發(fā)送

Dhcpdiscover 信息了﹐而會直接使用已經(jīng)租用到的 IP 位址向之前之 DHCP 伺服器發(fā)出Dhcprequest 信息﹐DHCP 伺服器會盡量讓客戶端使用原來的 IP 位址﹐如果沒問題的話﹐直接回應(yīng)Dhcpack 來確認(rèn)則可。如果該位址已經(jīng)失效或已經(jīng)被其它機器使用了﹐伺服器則會回應(yīng)一個 DHCPNACK 封包給客戶端﹐要求其從新執(zhí)行Dhcpdiscover 。

至于 IP 的租約期限卻是非常考究的﹐并非如我們租房子那樣簡單﹐以 NT 為例子﹕DHCP 工作站除了在開機的時候發(fā)出dhcprequest 請求之外﹐在租約期限一半的時候也會發(fā)出dhcprequest ﹐如果此時得不到 DHCP 伺服器的確認(rèn)的話﹐工作站還可以繼續(xù)使用該 IP ﹔然后在剩下的租約期限的再一半的時候(即租約的75)﹐還得不到確認(rèn)的話﹐那么工作站就不能擁有這個 IP 了。至于為什么不是到租約期限完全結(jié)束才放棄 IP 呢﹖﹐對不起﹐小弟也是不學(xué)無術(shù)之人﹐沒有去深究了﹐只知道要回答 MCSE 題目的時候﹐您一定要記得 NT 是這么工作的就是了。

要是您想退租，可以隨時送出 DHCPLEREASE 命令解約﹐就算您的租約在前一秒鐘才獲得的。

跨網(wǎng)路的 DHCP 運作

從前面描述的過程中，我們不難發(fā)現(xiàn)：DHCDISCOVER 是以廣播方式進(jìn)行的，其情形只能在同一網(wǎng)路之內(nèi)進(jìn)行﹐因為 router 是不會將廣播傳送出去的。但如果 DHCP 伺服器安設(shè)在其它的網(wǎng)路上面呢﹖由于 DHCP 客戶端還沒有 IP 環(huán)境設(shè)定﹐所以也不知道 Router 位址﹐而且有些 Router 也不會將 DHCP 廣播封包傳遞出去﹐因此這情形下 DHCPDISCOVER 是永遠(yuǎn)沒辦法抵達(dá) DHCP 伺服器那端的，當(dāng)然也不會發(fā)生 OFFER 及其他動作了。要解決這個問題，我們可以用 DHCP Agent (或 DHCP Proxy )主機來接管客戶的 DHCP

請求﹐然后將此請

求傳遞給真正的 DHCP 伺服器﹐然后將伺服器的回復(fù)傳給客戶。這里﹐Proxy 主機必須自己具有路由能力，且能將雙方的封包互傳對方。

若不使用 Proxy ，您也可以在每一個網(wǎng)路之中安裝 DHCP 伺服器﹐但這樣的話﹐一來設(shè)備成本會增加﹐而且﹐管理上面也比較分散。當(dāng)然啰﹐如果在一個十分大型的網(wǎng)路中﹐這樣的均衡式架構(gòu)還是可取的。端視您的實際情況而定了。 DHCP 封包格式

以下為各欄位的簡要說明：

OP

若是 client 送給 server 的封包，設(shè)為 1 ，反向為 2 。

HTYPE

硬體類別，Ethernet 為 1 。

HLEN

硬體位址長度， Ethernet 為 6 。

HOPS

若封包需經(jīng)過 router 傳送，每站加 1 ，若在同一網(wǎng)內(nèi)，為 0 。 TRANSACTION ID

DHCPREQUEST 時產(chǎn)生的數(shù)值，以作 DHCPREPLY 時的依據(jù)。

SECONDS