深入解析DHCP带来了什么功能，服务器回应到底是用广播还是单播呢？

前言

不知道大家在看到这个图的时候第一时间想到的是什么，【好复杂】【看不懂】【终端数好多】，这里不看整体的结构怎么样，来看看终端数量都非常的多，终端要与网络中进行通信，势必需要IP地址，从最开始学习到现在好像都是手动去设置的终端IP地址，如果一个网络中有几百台、几千台的终端设备，难道需要IT维护人员一个一个去设置吗，那工作量太大了，并且如果涉及到整改，比如换了一个新的网段，那岂不是之前设置的又需要重新修改，那估计TCP/IP的体系也没人使用了，使用起来太麻烦，不方便维护跟扩展，所以呢，出了一个应用层协议---DHCP。

DHCP带来了什么功能？

回想下自己平时电脑、手机、平板在接入无线路由器后是不是直接就可以上网了，并没有说去设置IP、掩码、网关等参数，这正式因为家用路由器默认是开了DHCP，而使用的终端设备也处于DHCP模式下，所以接上去就可以自动从家用路由器获取对应的参数信息，然后进行上网，是不是就简化了操作，因为实际中不可能指望普通用户还懂什么IP地址设置，所以DHCP出来解决了这个问题。

• 终端跟DHCP是如何交互的呢？

刚开机的终端由于是自动获取模式，那它本身是没有IP地址等参数的，那它怎么跟服务器去进行沟通呢？搭建一个环境，来看看整个过程。

DHCP服务器配置还没有讲解，这个提前做好了，该环境会直接发出，大家直接打开就可以。

客户端点击应用后，抓包就显示报文了，4个包。

（1）DHCP Discover

从上面能得到什么信息呢？

• 客户端由于没有地址，它会以0.0.0.0作为源，这里0.0.0.0的意思表示没有地址的意思，目的地址255.255.255.255 广播地址，包括二层地址也是，源是终端的MAC，目的全F，表示广播，为什么需要广播呢？这是因为终端它并不知道这个DHCP在哪，跟之前学过的二层封装一样，想要在以太网中找到某一个具体的设备，必须知道MAC地址，事先不知道的情况下，只能通过广播的形式询问，DHCP也是这样，它并不知道DHCP在哪，所以它也通过广播的方式找DHCP服务器。
• 消息类型为Request（请求），还标识了终端的硬件类型（二层以太网），终端地址0.0.0.0，表示目前没有地址，请求分配，告诉服务器自己的MAC地址是多少。
• 除了请求地址以外，终端还会请求其他的参数，通常最少会去请求子网掩码、默认网关、DNS，少了这些参数就上不了网了。
• 还值得注意的是，DHCP使用的是UDP的传输层协议，客户端使用68端口号，服务器使用67，那又说明一个问题，UDP是支持广播报文的，TCP是不支持。

简化总结：终端默认没有地址，以Discover广播寻找DHCP服务器，请求地址、掩码、网关、DNS等参数

（2）DHCP Offer

从上面能得到什么信息呢？

• Offer用于回应，从二层与三层的地址来看是不是单播了，没有关于全F跟255.255.255.255的了，二层好理解，因为请求的时候已经知道了客户端的MAC，但是三层这目的地址为192.168.255.253是怎么来的呢？
• 内容里面继续看，有一个Your（Client）IP adress：192.168.255.253，表示分配给客户端使用的，但是目前客户端并没有使用，只是服务端分配给它。上面三层目的地址192.168.255.253就是这样来的，其实这个时候客户端还是没有地址的，还是0.0.0.0。
• 服务端还会推送之前客户端请求的内容，包括子网掩码、默认网关、DNS、时间周期等，但是明显比客户端请求的少，这是因为服务器不支持或者是没有配置对应的内容，所以只会推送自己已经有的参数给客户端（说白了就是管理人员配置了什么就推送什么）
• 还有一个重要的信息，就是option 54，会告诉客户的DHCP的服务器信息是多少（通常就是IP地址）。

简化总结：服务端收到以后，从自己的地址池中分配可用地址，以及自己知道的其他参数一起推送给客户端，以单播回应客户端。（简单理解【服务器】：我这边给你这个地址，以及我知道的参数，看行不行。）

（3）DHCP Request

从上面能得到什么信息呢？

• 从第三个包 Request里面可以发现，客户端是并没有真正获取到地址的，还是0.0.0.0，并且还是广播包进行请求。
• 请求的内容就是在Offer里面服务端告诉客户端的，包括地址、掩码、网关、DNS这些，你会发现比第一个包要少了很多，因为服务端在第二个包已经明确告诉客户端，我这边只支持这些。

简化总结：第三个用于向服务端请求对应的信息，这个地址跟对应的参数信息都挺喜欢的，给我吧

（4）DHCP ACK

简化总结：告诉客户端，没问题，你用吧，这些参数收好，至此客户端就获取到地址了。

几个疑惑的地方,不知道整体抓包下来细心的你有没有发现几个疑惑的地方

• 客户端请求的都是以广播发送，这个能理解，因为客户端这个时候并没有获取到地址，只能广播
• 服务器按正常情况下，客户的并没有实际的地址，也只能以广播回应，但是抓包确实单播，按照我们之前学过的内容，TCP/IP协议栈在没有IP地址的情况下，当解封装到三层的时候发现目标地址不是广播地址，找到是255.253，则会丢弃，不会处理，但这里显然不是，抓包服务端回应的是单播的，说明TCP/IP协议栈处理了这个数据包。

（1）DHCP offer跟ACK到底用广播还是单播呢？

其实这个完全取决于客户端，不知道注意到没有，在客户端发送的Discovery/Requeset里面有这样一个字段。

（2）TCP/IP协议栈没地址前的处理问题？

在之前学习的理论中是没有获取到IP的时候，是只能处理广播报文，destination =255.255.255.255，但是在随着系统的优化，有的系统使用的TCP/IP协议栈，改变了一下规则，只要二层的目的MAC是自己或者是全F广播，三层的destination = Any的IP报文，也会进行处理，DHCP兼容这两种方式，使用哪种方式取决于客户端来决定，如果客户端支持destination =Any的则Bootpflagds=0，如果不支持则=1（大部分Windows7开始就已经支持，抓包可以发现Bootp flagds是=0的）

（3）服务端单播回复有什么好处呢？

我们在二层以及三层中都学过广播的概念，那广播跟单播有什么区别呢？

• 单播的特点是：点对点的方式，不会影响到广播域的其他主机。
• 广播的特点是：点到所有点方式，会影响到广播域的其他主机。

那广播有什么坏处呢？假设一个局域网内有200台终端（同一个网段），一个终端在请求地址，发送的是广播报文来找服务端，那该局域网内的其他所有主机都会收到这个广播报文，除了DHCP服务端以外，其余终端解封装后发现跟自己没关系，就丢弃了，可以看到广播其实对于一个局域网来说会消耗不必要的带宽资源，并且浪费主机的CPU资源，所以协议的设计跟优化中，会尽力的去避免使用广播。

回过头在来看DHCP offer与ACK为什么使用单播，因为客户端支持这个功能特性，只要Bootp flags=0，服务端会用单播回复客户端的请求，这样可以不影响到其他的主机，这是一种优化。

（4）服务端是怎么知道客户的MAC地址的呢？

之前学过要知道客户的MAC地址必须使用ARP，但是这里客户端连地址都没有，不可能使用ARP了，如果仔细看过报文字段内容的话，里面有一个Client HardwareAddress内容，里面就包含了客户端的MAC，服务端自然就知道客户端的MAC地址是多少了。

（5）假设网络中有多个DHCP服务器存在，那么客户端会使用哪个呢？

如果网络中有多个DHCP存在，客户端会以先收到的谁的offer就使用哪个，所以这样很容易出现问题，比如一个网络中接入了一个小路由器，那么可能导致下面主机获取到错误的参数，导致无法上网，这个后面会讲解决办法。

（6）那这地址是永久的吗？假设该终端获取地址后，过一会就离开回家了，DHCP服务器会怎么处理？

在服务端回应的Offer与ACK中携带了参数的，就是红色框框中，有三个，分别有什么作用呢？

• IP Aaadress lease Time：该参数表明这个地址最大的租期为86400s（一天），这个取决于服务端的配置，不同服务器默认不太一样。
• Rebinding Time Value与Renewal Time Value：表示续约时间，DHCP中规定，客户端在租期到一半的时候（12小时），会进行第一次续期，在租期到了87.5%的时候会进行第二次续期，有两次续期的存在，是担心中途在第一次续期的时候，恰巧DHCP服务器出现了某些故障，没法收到这个包，导致续期失败。
• 三个时间的作用相信大家就明白了，当一个客户端获取到地址后，如果正常使用租期50%或者87.5%会进行续期，成功后该地址可以继续使用，如果获取地址后，使用了一会就走了，在Lease Time时间后，该地址会被服务器释放掉，分配给其他用户。