Linux和Windows服務端DHCP報文對比研究

胡玲

摘 要 DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）屬于一種常規網絡服務，在配置DHCP服務中，整個過程會產生4種DHCP報文，雖然DHCP協議的工作過程都是一致的，但在由不同系統所提供的DHCP服務中，這4種DHCP報文在服務端與客戶端之間的傳輸方式卻不盡相同。本文利用WireShark抓包工具，分別就Linux和Windows系統提供的DHCP服務所產生的DHCP報文進行了對比研究，分析了不同報文傳輸方式的優劣，并給出了相應的建議。其中Linux系統采用的是版本是RedHat Enterprise Linux 6，Windows系統采用的版本是Windows Server 2008 R2。

【關鍵詞】DHCP 網絡環境 服務端配置 報文對比

DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）提供了動態配置IP地址的功能。在DHCP客戶端首次啟動時，會自動執行初始化過程以便從DHCP服務端處獲得IP地址。在整個過程中會產生4種DHCP報文，分別是：“DHCP Discover”、“DHCP Offer”、“DHCP Request”、“DHCP ACK”。在DHCP協議工作過程中的不同階段所產生的DHCP報文，如何才能保證準確而又高效地送達服務端或是客戶端？采用何種通信方式？下面分別在以Linux系統和Windows系統作為服務端的實驗環境中來進行抓包分析。

1 Linux服務端DHCP報文抓包分析

1.1 在服務端配置DHCP服務

實驗環境中Linux系統的IP地址為“192.168.150.10”，在系統中安裝了dhcp服務，并在配置文件“/etc/dhcp/dhcpd.conf”中配置了DHCP作用域，定義作用域的地址池范圍是“192.168.150.101～192.168.150.200”，默認網關“192.168.150.254”，DNS服務器“8.8.8.8”，默認租期86400秒，最長租期172800秒。

1.2 在客戶端抓包分析

實驗中，在一臺Windows客戶端上安裝并運行網絡分析工具Wireshark來捕捉網絡中的數據，并將IP地址設置為自動獲得。

首先執行“ipconfig/release”命令釋放之前的IP地址，然后再執行“ipconfig/renew”命令重新申請IP地址，此時在客戶端與服務端之間就開始了DHCP協議的工作過程。當客戶端成功獲得IP地址之后，在WireShark中可以看到已經抓取到的4個DHCP報文，如圖1所示。

可以發現，在4個DHCP報文中，“DHCP Discover”和“DHCP Request”采用了廣播方式，“DHCP Offer”和“DHCP ACK”采用了單播方式。

1.2.1 DHCP Discover報文分析

作為DHCP協議工作過程中產生的第一個報文，“DHCP Discover”報文必然要采用廣播的通信方式。查看該報文的封裝結構，可以看到其在封裝二層數據幀時，源MAC地址為客戶端地址“00：0c：29：0a：1c：ec”，目的MAC地址則采用了廣播地址“ff：ff：ff：ff：ff：ff”。在封裝三層數據包時，源IP地址是“0.0.0.0”，目的IP地址同樣采用了廣播地址“255.255.255.255”。“DHCP Discover”報文封裝結構如圖2所示。

客戶端通過“DHCP Discover”報文向整個網絡發出廣播，以尋找DHCP服務端。

1.2.2 DHCP Offer報文分析

從圖1中可看出，“DHCP Offer”報文采用了單播的通信方式。查看該報文的封裝結構，在封裝二層數據幀時，源MAC地址為服務端地址“00：0c：29：98：19：94”，目的MAC地址為客戶端地址“00：0c：29：0a：1c：ec”，目的MAC地址可從之前的“DHCP Discover”報文中獲得。在封裝三層數據包時，源IP地址為服務端地址“192.168.150.10”，目的IP地址為地址池中的第一個地址“192.168.150.101”。“DHCP Offer”報文封裝結構如圖3所示。

雖然此時IP地址“192.168.150.101”尚未分配給客戶端使用，但Linux服務端已經利用它來封裝報文了。由于有目的MAC地址的引導，因而“DHCP Offer”報文完全可以準確送達客戶端。

1.2.3 DHCP Request報文分析

“DHCP Request”報文采用了與“DHCP Discover”報文相同的封裝結構，目的MAC地址和目的IP地址全部是廣播地址。由于客戶端可能會從多個DHCP服務端處收到“DHCP Offer”報文，因而它必須將自己的選擇通告給所有服務端，所以“DHCP Request”報文必然也得采用廣播通信方式。

1.2.4 DHCP ACK報文分析

“DHCP ACK”報文采用了與“DHCP Offer”報文相同的封裝結構，報文采用單播方式，直接在服務端與客戶端之間傳送。雖然IP地址仍未正式分配給客戶端使用，但通過目的MAC地址同樣可以將報文準確送達客戶端。

2 Windows系統下DHCP報文抓包分析

2.1 在服務端配置DHCP服務

實驗環境中Windows服務端的IP地址為“192.168.150.20”，系統中安裝了“DHCP服務器”角色，并創建了名為“test”的作用域。

2.2 在客戶端抓包分析

在Windows客戶端上仍是先執行“ipconfig/release”命令釋放之前的IP地址，然后再執行“ipconfig /renew”命令重新申請IP地址，此時WireShark就會抓取在Windows服務端與客戶端之間所產生的DHCP報文，如圖4所示。可以發現這4個報文全部采用了廣播通信方式。

對于由客戶端所產生的“DHCP Discover”和“DHCP Request”報文，根據DHCP協議工作原理，其必然要采用廣播方式。但是這里由Windows服務端所產生的“DHCP Offer”和“DHCP ACK”報文也同樣采用了廣播方式，在這兩個報文的封裝結構中，目的MAC地址和目的IP地址也都是廣播地址。“DHCP Offer”報文和“DHCP ACK”報文封裝結構如圖5所示。

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

3 結束語

通過對Linux服務端和Windows服務端的DHCP報文抓包對比分析，很容易可以得出結論，即Linux服務端所采用的“DHCP Offer”和“DHCP ACK”報文單播通信方式，更有利于網絡性能的整體優化。所以微軟公司如果也能將Windows服務端中的這兩個報文也改換成單播通信方式，或許更能提高工作效率。

參考文獻

[1]張伍榮.Windows Server服務端架設與管理[M].北京：清華大學出版社，2011.

[2]曹茸.DHCP網絡環境的構建與實現[J].電子科技，2011，24（7）：106-108.

作者單位

柳州鐵道職業技術學院 廣西壯族自治區柳州市 545616