DHCP协议实例化分析

用wireshark抓取DHCP客户端和DHCP服务器之间动态分配IP地址和配置参数的完整过程，如下图所示：

整个过程分析

- 报文1

这是一条客户端发送的DHCP Discover消息。DHCP Discover消息是所有主机通过DHCP协议配置IP地址和参数，发送的第一条消息。它的目的是发现DHCP服务器，并请求参数。由于客户端还没有分配IP地址，所以源IP地址为0.0.0.0。由于客户端不知道DHCP服务器的IP地址，但是又需要发送给局域网内的服务器，所以就只能通过广播的方式把DHCP Discover消息发出去，目的IP地址为255.255.255.255。DHCP是应用层协议，必须基于传输层协议传输，传输层协议要么是TCP、要么是UDP。广播方式只能使用UDP协议，所以，DHCP Discover消息肯定使用UDP协议传输。这条消息的Transaction ID是0xe9afd0f3，它其实是DHCP协议字段xid，事务ID，这是客户端随机选择的数字，用它来关联这条消息触发的所有的后续DHCP消息，也就是说后续的不管是客户端发的DHCP消息，还是服务器发的DHCP消息，这个Transaction ID都是相同的

- 报文2、3、4

这是三条相同的广播ARP请求报文，请求主机119的MAC地址，发出这三条报文的主机是188。通过后面的报文可知，119是DHCP服务器给客户端分配的IP地址，188是DHCP服务器的IP地址。那么也就是说，DHCP服务器向119请求MAC地址，但是此时119并没有分配给客户端，那为什么要向119请求MAC地址呢？我们知道ARP请求除了能显性地请求MAC地址，也能隐性地检查广播域内是否有目标IP地址。只要有ARP响应，就说明存在目标IP地址，没有ARP响应，说明不存在目标IP地址。所以，这里是DHCP服务器在收到客户端的DHCP Discover消息后，首先需要确认分配给客户端的IP地址是否已经被子网中的其他主机所使用，由此发送了三条ARP请求报文，刺探这个IP地址的使用情况。在rfc 2131描述中，这里是使用ICMP Echo Request报文探测的。也可以，但是必须是广播的方式

- 报文5

这也是客户端发送的DHCP Discover消息，从它的Transaction ID 0xc7e5f40b看出，它是另一条DHCP Discover消息。那为什么客户端又重新发一条呢？一般重发都是由于超时，从前后两条消息的时间间隔相差了3秒以上判断，肯定是由于之前的DHCP Discover消息没有收到DHCP offer响应消息而超时，所以就重发了一条DHCP Discover消息

- 报文6

这是服务器发送的DHCP offer消息，从它的Transaction ID为0xe9afd0f3可知，它是对客户端发送的第一条DHCP Discover消息的响应。由于客户端此时还没有IP地址，所以服务器必须通过广播方式把DHCP offer消息发送出去，以使客户端能够接收。所以DHCP offer的目的IP地址是限制广播地址，源地址是服务器IP地址，它是一条UDP报文。DHCP offer消息是服务器告知客户端它能够提供的配置参数是多少

- 报文7

这也是服务器发送的DHCP offer消息。从它的Transaction ID为0xc7e5f40b看出，它是对客户端重发的DHCP Discover消息的响应。由此看出，不管客户端重复发了多少条DHCP Discover，DHCP服务器都会响应

- 报文8、9

报文8是客户端发送给服务器的DHCP Request消息，还是以广播方式。从这里看出，虽然前面服务器发送的DHCP offer已经携带了服务器的IP地址，但是客户端并没有想办法获取这个IP地址后，用单播的方式发送DHCP Request。这里猜测可能是因为客户端收到DHCP offer消息时，只在网络层对比了目标IP地址，然后就把数据发到上层，应用层DHCP拿到的数据里并没有包含源IP，也就是DHCP服务器的IP地址。通过DHCP Request消息的Transaction ID为0xc7e5f40b可知，客户端虽然收到了第一条DHCP Discover消息的响应消息DHCP offer，但是并没有发送它们的关联的DHCP Request消息。其实这也很好理解，从客户端的角度来说，它发送的第一条DHCP Discover消息已经超时，那么这条线就已经失效了，即使后面接收到了超时的DHCP Discover消息的响应消息DHCP offer，它也不会继续处理这条线了。DHCP Request消息是客户端请求服务器分配IP地址和参数的请求消息，同时也是隐式地选择服务器

报文9是服务器对收到的DHCP Request消息的响应消息DHCP Ack，也是使用的广播方式。DHCP Ack消息是被选择的服务器正式提供IP地址和分配配置参数给客户端

- 报文10、11

那么是不是客户端收到DHCP Ack消息后就立刻配置好IP地址了呢？并不是的。如果你学习过免费ARP，应该知道主机网卡在设置IP地址前，都需要发送免费ARP，确定这个IP地址是否在子网中被其他主机所使用。所以客户端网卡在设置IP地址前，会先发送ARP探针报文，确定没有冲突后，才会设置好此IP地址。设置完IP地址后，还会发送ARP公告消息，进一步确认设置好的IP地址是否有冲突

- 报文12、13

报文12是有了IP地址的客户端，向服务器发送的ARP请求，报文13是服务器回复的ARP响应。客户端并没有给服务器发送消息的需求，为什么要发送ARP请求消息来请求服务器的MAC地址呢？我猜测可以换个角度想，这个ARP请求其实是客户端想告诉服务器：我已经配置好了你分配的IP地址了。由此才会引出报文17服务器对客户端的询问

- 报文17、18

报文17是服务器向客户端发送ARP请求，报文18是客户端回复的ARP响应。就像上面说的，报文12可能是客户端想告诉服务器：我已经配置好了你分配的IP地址了。那么这里服务器接着发了一条ARP请求给客户端，目的是询问客户端你确定已经配置好了吗？当收到客户端的ARP响应后，服务器就知道它确实配置好了

具体消息分析

以下图片只截取了DHCP协议层的字段

- DHCP Discover

有几个重要的字段：

• Message type

这个字段表示DHCP消息的类型，它有两个值，1是Boot Request，2是Boot Reply

可是，DHCP有很多的消息类型，比如Discover、Offer、Request、Ack等等。要怎么用这两个值区分这么多的消息呢？我们知道DHCP协议采用C/S模式，一问一答，客户端的请求消息就是Boot Request，服务器的响应消息就是Boot Reply，然后具体的消息类型会在下面的options字段里携带，比如这里的DHCP Discover消息options字段里就携带了一个Option（53）DHCP Message Type（Discover）

• Transaction ID

这是客户端在DHCP通信开始时随机选择的数字，这次通信的后续所有的DHCP消息，都使用这个数字

• Bootp flags

这个字段有两个byte，最高位bit位是广播标志位，1表示广播，所以，0x8000表示广播

• Your(client) IP address

这是服务器给客户端提供的IP地址，客户端自己发的DHCP消息里这个字段是0

• Next server IP address

这个服务器的IP地址，由服务器提供，所以客户端发送的DHCP消息里这个字段为0

• Client MAC address

这是客户端的MAC地址，你会发现Discover、Offer、Request、Ack这几条消息，都把这个字段填上了客户端的MAC地址

• Server host name

服务器主机名称，你会发现Discover、Offer、Request、Ack这几条消息，都没有填写这个字段

• options

分析对比这几条DHCP消息，你会发现：所有的DHCP消息里options字段，都是以Option（53）开始，Option（255）结束

Option（53）表示DHCP消息类型，类型标识符是这个option下的某个字节

1表示Discover，2表示Offer，3表示Request，5表示Ack

Option（255）是结束符，当然如果DHCP长度不满足，后面有可能还有很多填充位

DHCP Discover消息还有一个参数请求列表Option（55），作为对服务器的配置参数的请求

- DHCP Offer

这是一条DHCP服务器发送的响应消息，所以Message type字段是2

服务器收到Discover后需要把自己能提供的IP地址和配置参数发给客户端，由客户端做选择，这是DHCP Offer消息的作用，所以提供的IP地址就放在了Your(client) IP address字段中

服务器还把自己的IP地址放在了Next server IP address字段中

服务器提供的配置参数信息放在了options字段中，具体内容如下：

- DHCP Request

这条消息是客户端根据多个服务器（这个例子中只有一个）发来的DHCP offer消息中提供的IP地址和配置参数，选择合适的服务器，发出的正式请求

所以这条消息中需要有请求的IP地址，请求的配置参数，还有选择的服务器的标识符，这样被选择的服务器可以根据这个标识符作出响应

- DHCP Ack

最终服务器通过DHCP Ack消息提供IP地址和配置参数，客户端根据收到的DHCP Ack消息设置它们

最后推荐一个DHCP Server工具：tftp64

---