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

DHCP协议实例化分析_tcp/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

DHCP协议实例化分析_网络协议_02

有几个重要的字段:

  • 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下的某个字节

DHCP协议实例化分析_客户端_03

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

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

DHCP协议实例化分析_DHCP协议_04

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

DHCP协议实例化分析_服务器_05

- DHCP Offer

DHCP协议实例化分析_服务器_06

DHCP协议实例化分析_tcp/ip_07

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

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

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

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

DHCP协议实例化分析_网络协议_08

DHCP协议实例化分析_DHCP协议_09

- DHCP Request

DHCP协议实例化分析_客户端_10

DHCP协议实例化分析_DHCP协议_11

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

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

- DHCP Ack

DHCP协议实例化分析_DHCP协议_12

DHCP协议实例化分析_网络协议_13

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

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