DHCP协议的有限状态机及相关问题

大家好，欢迎来到IT知识分享网。

DHCP的有限状态机如下;

该有限状态机包括了大部分的状态跳转。

INIT-REBOOT状态到REBOOTING的转变是当客户端机器重启之后，想要重新确认正在使用的IP的有效性的发送的。客户端广播DHCPREQUEST报文，若收到了服务器的DHCPACK响应，那么则直接进入BOUND状态，若收到的是DHCPNAK报文，那么则进入INIT状态。

在INIT状态，客户端广播发送DHCPDISCOVER，进入SELECTING状态。在服务器收到DHCPDISCOVER报文之后，选择合适的IP地址放入DHCPOFFER报文进行单播发送，发送目的IP地址填入分配给其的IP(这里在发送之前，要使用PING命令来探测该IP地址的可用性，若可用则发送)。若该网段中存在多个DHCP服务器，那么客户端可能会收到多个DHCPOFFER，一般客户端会现在第一个收到的DHCPOFFER进行回应即广播发送DHCPREQUEST报文(该报文包含了它选择的IP地址信息，这样服务器才能够以此判断客户端是否选择了咱提供的IP)。服务器在收到DHCPREQUEST之后，会响应DHCPACK报文，同样使用的是单播。客户端这边若收到了DHCPACK报文，则会使用ARP命令来探测该IP地址的可用性，若可用则，设置定时器T1、T2，并进入BOUND状态；若不可用，那么则发送给服务器DHCPDECLINE，指示该IP地址不可用，这样服务器会删除自身租约表里面该ip地址的租约条目。客户端这期间收到其他的报文比如DHCPOFFER，统统丢弃。在BOUND中，随着时间的流逝，当T1计时器超时时(T1一般被设置为租约时间的一半)，会向向其提供IP地址的服务器单播发送DHCPREQUEST报文，若收到了服务器的DHCPACK回应，那么则跳转如BOUND状态，重新记录租约和设置T1、T2计时器；若收到的是DHCPNAK，那么则直接转到INIT状态了。若单播了发送了DHCPREQUEST报文之后，直到T2计时器超时(T2设置为租约时间的3/4)都没有收到回应，则会广播DHCPREQUEST报文，与之前类似，收到服务器的DHCPACK报文则回到BOUND状态，否则直接转入INIT，进入下一轮循环。

一般常见的关于DHCP的问题总结如下：

1、  客户端发送dhcpdiscover报文为广播，服务器应答dhcpoffer为单播。此时客户端并没有ip地址，服务器单播的ip地址如何发送个客户端的呢？

以下，考虑的是服务器和客户端在同一个子网段时的情况：

服务器通过接受dhcpdiscover报文记录了客户端的MAC地址，但是并不知道IP地址，因为这时候客户端自身是没有IP地址的。在这样的情况下，服务器要向客户端单播DHCPOFFER报文，却又不知道IP地址，那该怎么办呢？使用MAC地址进行发送。服务端这边通常是调用原始套接字，直接发送数据链路层报文将报文发送给客户端。

当然这是客户端和服务器在同一个子网段时的情况。当它们不在同一个子网段时，要使用DHCP reply agent，由DHCP reply agent来中转报文。

2、  在客户端和服务器的一次交互之后，客户端已经知道了服务器的ip地址，那么在客户端在发送dhcp-request报文时，为什么还要广播呢，而不直接单播？

考虑，有多台DHCP服务器的情况。客户端广播DHCPDISCOVER报文，有多个服务器进行响应，服务器，挑选自身的可用IP地址封装到DHCPOFFER报文中，同时将该IP地址和客户端的MAC地址写入租约表中。如果客户端不广播而是单播(目的IP为提供IP的服务器)DHCPREQUEST报文，告知其选择了谁的IP，那么其他IP地址落选的服务器不可能知道其落选，这样客户端没有使用其IP，但是其在租约表中却又记录，这样造成了IP地址的极大浪费。客户端广播DHCPREQUEST报文(该报文包含了客户端选用的IP地址)的话，服务器接受该报文，提取客户端选用的IP地址和服务器提供的IP地址，若一致，就表明客户端选择了该服务器提供的IP地址，否则没选中。没选中的话，就可以消除服务器租约表里面的该IP的租约信息了。

本人享有博客文章的版权，转载请标明出处http://blog.csdn.net/baidu20008