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