linux和windows服務端dhcp報文對比研究

1、<p>　　Linux和Windows服務端DHCP報文對比研究</p><p>　　摘 要 DHCP（Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議）屬于一種常規(guī)網(wǎng)絡服務，在配置DHCP服務中，整個過程會產(chǎn)生4種DHCP報文，雖然DHCP協(xié)議的工作過程都是一致的，但在由不同系統(tǒng)所提供的DHCP服務中，這4種DHCP報文在服務端與客戶端之間的傳輸方式卻不盡相同。

2、本文利用WireShark抓包工具，分別就Linux和Windows系統(tǒng)提供的DHCP服務所產(chǎn)生的DHCP報文進行了對比研究，分析了不同報文傳輸方式的優(yōu)劣，并給出了相應的建議。其中Linux系統(tǒng)采用的是版本是RedHat Enterprise Linux 6，Windows系統(tǒng)采用的版本是Windows Server 2008 R2。 </p><p>　　【關鍵詞】DHCP 網(wǎng)絡環(huán)境 服務端配置 報文對比 &l

3、t;/p><p>　　DHCP（Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議）提供了動態(tài)配置IP地址的功能。在DHCP客戶端首次啟動時，會自動執(zhí)行初始化過程以便從DHCP服務端處獲得IP地址。在整個過程中會產(chǎn)生4種DHCP報文，分別是：“DHCP Discover”、“DHCP Offer”、“DHCP Request”、“DHCP ACK”。在DHCP協(xié)議工作過程中的不同

4、階段所產(chǎn)生的DHCP報文，如何才能保證準確而又高效地送達服務端或是客戶端？采用何種通信方式？下面分別在以Linux系統(tǒng)和Windows系統(tǒng)作為服務端的實驗環(huán)境中來進行抓包分析。 </p><p>　　1 Linux服務端DHCP報文抓包分析 </p><p>　　1.1 在服務端配置DHCP服務 </p><p>　　實驗環(huán)境中Linux系統(tǒng)的IP地址為“192.1

5、68.150.10”，在系統(tǒng)中安裝了dhcp服務，并在配置文件“/etc/dhcp/dhcpd.conf”中配置了DHCP作用域，定義作用域的地址池范圍是“192.168.150.101～192.168.150.200”，默認網(wǎng)關“192.168.150.254”，DNS服務器“8.8.8.8”，默認租期86400秒，最長租期172800秒。 </p><p>　　1.2 在客戶端抓包分析 </p>

6、<p>　　實驗中，在一臺Windows客戶端上安裝并運行網(wǎng)絡分析工具Wireshark來捕捉網(wǎng)絡中的數(shù)據(jù)，并將IP地址設置為自動獲得。 </p><p>　　首先執(zhí)行“ipconfig/release”命令釋放之前的IP地址，然后再執(zhí)行“ipconfig/renew”命令重新申請IP地址，此時在客戶端與服務端之間就開始了DHCP協(xié)議的工作過程。當客戶端成功獲得IP地址之后，在WireShark中可以

7、看到已經(jīng)抓取到的4個DHCP報文，如圖1所示。 </p><p>　　可以發(fā)現(xiàn)，在4個DHCP報文中，“DHCP Discover”和“DHCP Request”采用了廣播方式，“DHCP Offer”和“DHCP ACK”采用了單播方式。 </p><p>　　1.2.1 DHCP Discover報文分析 </p><p>　　作為DHCP協(xié)議工作過程中產(chǎn)生的第

8、一個報文，“DHCP Discover”報文必然要采用廣播的通信方式。查看該報文的封裝結構，可以看到其在封裝二層數(shù)據(jù)幀時，源MAC地址為客戶端地址“00：0c：29：0a：1c：ec”，目的MAC地址則采用了廣播地址“ff：ff：ff：ff：ff：ff”。在封裝三層數(shù)據(jù)包時，源IP地址是“0.0.0.0”，目的IP地址同樣采用了廣播地址“255.255.255.255”?！癉HCP Discover”報文封裝結構如圖2所示。 </

9、p><p>　　客戶端通過“DHCP Discover”報文向整個網(wǎng)絡發(fā)出廣播，以尋找DHCP服務端。 </p><p>　　1.2.2 DHCP Offer報文分析 </p><p>　　從圖1中可看出，“DHCP Offer”報文采用了單播的通信方式。查看該報文的封裝結構，在封裝二層數(shù)據(jù)幀時，源MAC地址為服務端地址“00：0c：29：98：19：94”，目的MAC

10、地址為客戶端地址“00：0c：29：0a：1c：ec”，目的MAC地址可從之前的“DHCP Discover”報文中獲得。在封裝三層數(shù)據(jù)包時，源IP地址為服務端地址“192.168.150.10”，目的IP地址為地址池中的第一個地址“192.168.150.101”?！癉HCP Offer”報文封裝結構如圖3所示。 </p><p>　　雖然此時IP地址“192.168.150.101”尚未分配給客戶端使用，但L

11、inux服務端已經(jīng)利用它來封裝報文了。由于有目的MAC地址的引導，因而“DHCP Offer”報文完全可以準確送達客戶端。 </p><p>　　1.2.3 DHCP Request報文分析 </p><p>　　“DHCP Request”報文采用了與“DHCP Discover”報文相同的封裝結構，目的MAC地址和目的IP地址全部是廣播地址。由于客戶端可能會從多個DHCP服務端處收到“

12、DHCP Offer”報文，因而它必須將自己的選擇通告給所有服務端，所以“DHCP Request”報文必然也得采用廣播通信方式。 </p><p>　　1.2.4 DHCP ACK報文分析 </p><p>　　“DHCP ACK”報文采用了與“DHCP Offer”報文相同的封裝結構，報文采用單播方式，直接在服務端與客戶端之間傳送。雖然IP地址仍未正式分配給客戶端使用，但通過目的MAC

13、地址同樣可以將報文準確送達客戶端。 </p><p>　　2 Windows系統(tǒng)下DHCP報文抓包分析 </p><p>　　2.1 在服務端配置DHCP服務 </p><p>　　實驗環(huán)境中Windows服務端的IP地址為“192.168.150.20”，系統(tǒng)中安裝了“DHCP服務器”角色，并創(chuàng)建了名為“test”的作用域。 </p><p&g

14、t;　　2.2 在客戶端抓包分析 </p><p>　　在Windows客戶端上仍是先執(zhí)行“ipconfig/release”命令釋放之前的IP地址，然后再執(zhí)行“ipconfig /renew”命令重新申請IP地址，此時WireShark就會抓取在Windows服務端與客戶端之間所產(chǎn)生的DHCP報文，如圖4所示?？梢园l(fā)現(xiàn)這4個報文全部采用了廣播通信方式。 </p><p>　　對于由客戶端

15、所產(chǎn)生的“DHCP Discover”和“DHCP Request”報文，根據(jù)DHCP協(xié)議工作原理，其必然要采用廣播方式。但是這里由Windows服務端所產(chǎn)生的“DHCP Offer”和“DHCP ACK”報文也同樣采用了廣播方式，在這兩個報文的封裝結構中，目的MAC地址和目的IP地址也都是廣播地址?！癉HCP Offer”報文和“DHCP ACK”報文封裝結構如圖5所示。 </p><p>　　Windows服

16、務端所采用這種廣播通信方式，會導致同一廣播域中的所有主機都將接收到“DHCP Offer”和“DHCP ACK”這兩個報文，這些主機要對報文依次解封，一直處理到應用層才會確認這些報文與己無關，從而浪費主機資源。因而，Windows服務端所采用廣播通信方式急需改進。 </p><p><b>　　3 結束語 </b></p><p>　　通過對Linux服務端和Wind

17、ows服務端的DHCP報文抓包對比分析，很容易可以得出結論，即Linux服務端所采用的“DHCP Offer”和“DHCP ACK”報文單播通信方式，更有利于網(wǎng)絡性能的整體優(yōu)化。所以微軟公司如果也能將Windows服務端中的這兩個報文也改換成單播通信方式，或許更能提高工作效率。 </p><p><b>　　參考文獻 </b></p><p>　　[1]張伍榮.Win

18、dows Server服務端架設與管理[M].北京：清華大學出版社，2011. </p><p>　　[2]曹茸.DHCP網(wǎng)絡環(huán)境的構建與實現(xiàn)[J].電子科技，2011，24（7）：106-108. </p><p><b>　　作者單位 </b></p><p>　　柳州鐵道職業(yè)技術學院 廣西壯族自治區(qū)柳州市 545616</p>