DHCP报文协议

最新推荐文章于 2024-05-02 16:38:19 发布

有梦想的hello kitty

最新推荐文章于 2024-05-02 16:38:19 发布

阅读量4.5k

点赞数 2

文章标签：网络协议

本文链接：https://blog.csdn.net/geyggye/article/details/124399278

版权

Ipv4

单播，即点对点的通信，目的地址为单一目标的一种传输方式。

源IP、源MAC为发送者的IP和mac地址，目的IP、目的MAC为接收者的IP和mac地址。

广播，是指封包在计算机网络中传输时，目的地址为网络中所有设备的一种传输方式。实际上，这里所说的“所有设备”也是限定在一个范围之中，称为“广播域”。

源IP、源MAC为发送者的IP和mac地址，目的IP、目的MAC为全0，例如arp报文

其中c0 a8 97 17为源IP，c0 a8 97 fd为目的IP

组播，也叫多播，指把信息同时传递给一组目的地址。它使用策略是最高效的，因为消息在每条网络链路上只需传递一次，而且只有在链路分叉的时候，消息才会被复制。

源IP为组播源服务器的IP地址，源MAC为

IANA把D类地址空间分配给IP组播，其范围是从224.0.0.0到239.255.255.255。组播MAC地址的高24bit为0x01005e，第25bit为0，即高25bit为固定值。MAC地址的低23bit为组播IP地址的低23bit。由于 IP组播地址的前4bit 是1110，代表组播标识，而后28bit 中只有23bit 被映射到MAC 地址，这样IP 地址中就有5bit 信息丢失，导致的结果是出现了32 个IP 组播地址映射到同一MAC 地址上。

DHCP报文的结构

op，报文类型，1表示请求报文，2表示回应报文。

htype，硬件地址类型，1表示10Mb/s的以太网的硬件地址。

hlen，硬件地址长度，以太网中该值为6。

hops，跳数。客户端设置为0，也能被一个代理服务器设置。

xid，事务ID，由客户端选择的一个随机数，被服务器和客户端用来在它们之间交流请求和响应，客户端用它对请求和应答进行匹配。该ID由客户端设置并由服务器返回，为32位整数。

secs，由客户端填充，表示从客户端开始获得IP地址或IP地址续借后所使用了的秒数。

flags，标志字段。这个16比特的字段，目前只有最左边的一个比特有用，该位为0，表示单播，为1表示广播。

ciaddr，客户端的IP地址。只有客户端是Bound、Renew、Rebinding状态，并且能响应ARP请求时，才能被填充。

yiaddr，"你自己的"或客户端的IP地址。

siaddr，表明DHCP协议流程的下一个阶段要使用的服务器的IP地址。

giaddr，DHCP中继器的IP地址。//注意：不是地址池中定义的网关

chaddr，客户端硬件地址。客户端必须设置它的"chaddr"字段。UDP数据包中的以太网帧首部也有该字段，但通常通过查看UDP数据包来确定以太网帧首部中的该字段获取该值比较困难或者说不可能，而在UDP协议承载的DHCP报文中设置该字段，用户进程就可以很容易地获取该值。

sname，可选的服务器主机名，该字段是空结尾的字符串，由服务器填写。

file，启动文件名，是一个空结尾的字符串。DHCP Discover报文中是"generic"名字或空字符，DHCP Offer报文中提供有效的目录路径全名。

options，可选参数域，格式为"代码+长度+数据"。

原理图：

在Wireshark中抓包并进行协议解析，注意：其中Bootp flags为客户端对服务器端回复报文形式的标志，并不是客户端发送报文的形式，也就是在DHCP DISCOVER报文中的bootp flags为由服务器向客户端作出回应发出的DHCP OFFER报文的形式，DHCP REQUEST报文中的bootp flags为由服务器向客户端作出回应发出的DHCP ACK报文的形式，并且若Bootp flags为0x0000（Unicast）则为单播，0x8000（Broadcast）为广播，这也就说明了DHCP OFFER报文和DHCP ACK报文既可以以广播形式发送，也可以以单播形式发送给客户端。

DHCP Release报文（单播） 由客户端发出

用来释放客户端IP地址，并且在IP地址释放后客户端源IP地址变为0.0.0.0

DHCP DISCOVER报文（广播） client-------->server

用来向服务器发送IP请求报文，将自己的MAC地址封装在报文里广播寻找IP。

注意：在DHCP DISCOVER报文发出后，会随机生成一个Transaction ID，如果在DHCP OFFER报文中的Transaction ID和DHCP DISCOVER的不一样时，会将DHCP OFFER报文直接丢弃，也就是PC只会认可第一个发送来的DHCP OFFER报文，一个完整的DHCP过程中，Transaction ID保持不变。

DHCP OFFER报文 server-------->client

服务器从地址池中分配一个可用IP给客户端

DHCP REQUEST报文 client-------->server

客户端一般只处理一个最先到达客户端的DHCP OFFER报文，然后在选项字段中会加入选中的DHCP Server的IP地址和需要的IP地址

确认在DHCP OFFER阶段获得的IP地址能否分配给client，如果可以，则发送DHCP ACK报文，如果IP不可用，则发送DHCP NAK报文：

DHCP ACK报文 server -------->client

服务器判断选项字段中的IP是否在自己的分配记录中，如果有则响应DHCP ACK报文

注意：此时客户端仍然不能使用该IP，需要在接收到ACK报文后需要检查该 IP是否被使用（比如发送一条目的IP为该IP的arp报文，看是否有回应），如果被使用，则需要向server发出DHCP DECLINE报文，通知DHCP Server禁用这个IP地址，然后DHCP Client开始新的地址申请过程。

DHCP Client在成功获取IP地址后，随时可以通过发送DHCP RELEASE报文释放自己的IP地址，DHCP Server收到DHCP RELEASE报文后，会回收相应的IP地址并重新分配。

DHCP NAK报文 server --------> client

服务器对客户端的REQUEST报文的拒绝响应报文，表示分配IP地址失败，此时DHCP客户端需要重新发送DHCP DISCOVER报文重新申请IP地址。