为何DHCP Request消息是广播出去的?

来自:车小胖谈网络 (微信号:chexiaopangnetwork),作者:车小胖谈网络

为什么DHCP中,client在接收到dhcp discovery的响应后,第二次request是以广播而不是单播的形式发出去的呢?



如图,第一次广播是因为client不知道dhcp的ip,这个我理解,而dhcp的广播回应是因为现在client还没有ip,我也理解。

但是第三次为什么还要广播出去呢?我理解必然还需要两次握手client才能确定这个ip是可用的,因为dhcp要确认当前那些ip是分配出去的,client应当作出回应,告知dhcp这个ip将被租用,transactionid则确保dhcp能够维持session,识别到来的这种request,而client之所以需要ack的到来才真正开始使用这个ip则因为要确保dhcp服务器收到了他的request,防止丢包dhcp并没有被告知ip的租用,必要时超时重传。

但是为什么这个request需要广播呢?我的理解是多个dhcp可能同时响应第一次的discover,同时每个dhcp维持一个类似session的记录,也预留出一个等待request的ip,而request的广播则是为了告知这些没有被选择的dhcp服务器删掉这个记录,释放预留的ip,这个过程是通过transaction id来identify的。但我觉得这个理解有问题,一方面书上并没有提到client需要等待这些未被选择的dhcp的ACK,那这个广播岂不是只是一次best effort?另一方面难道只是为了释放ip吗,是否还有其他考虑?

 


高效的学习方法是不断地产生疑问,然后努力地找到问题的答案。如果实在找不到答案,那就放一放,随着学习的深入,过去的遗留的问题可能一下子就消失了。学习方法可以参考这篇文章:


如何看待思科取消CCIE Routing& Switching?

 

这个问题的产生,是由于提问者对于DHCP服务器的部署方法不是很熟悉。在任何一个网络里,都无法做到一个网段(广播域)一个DHCP服务器。如果真是那样,一个有1000个广播域的大型网络,需要1000DHCP服务器,光配置管理那么多的DHCP服务器就能把管理员累的半死。

 

任何一个公司,其实两台DHCP服务器就足够了,一台做主服务器,用于给全网络的客户端分配IP参数。另一台做冗余备份,只有当主服务器无法正常工作时,才能登台表演。

 

问题来了,既然不是每个广播域都有DHCP服务器,客户端如何发现DHCP服务器在哪里呢?


客户端无法发现,但不要着急,每一个广播域至少潜藏着一个DHCP Relay代理,代理知道DHCP服务器的IP

 

代理不仅可以收到客户端DHCP Discovery的广播消息,同时还知道DHCP服务器的IP,代理就可以将DHCP Discovery消息,以单播的方式Relay到数据中心的DHCP服务器上。经过代理的暗中撮合,客户端与DHCP服务器就勾搭上了。。。

 

但是不要忘记,在四次消息交互完成之前,客户端的TCP/IP协议栈一直是空的。换句话说,客户端没有IP地址、没有网络掩码、没有网关地址,它如何和不在一个网段的DHCP服务器通信呢?

 

如果它要用DHCP服务器的IP通信,它如何知道DHCP服务器是否和自己在一个广播域?

 

DHCP 客户端可以通过DHCP Offer报文里的客户端的IP、网络掩码、DHCP服务器来判断在或不在。

 

假设不在,客户端需要通过网关转发给DHCP服务器,问题是不知道网关的地址,所以无法使用单播通信。

 

假设在,既然是在一个广播域,广播方式和单播方式都可以找到DHCP服务器,用什么方式都可以通信。

 

为何要优先使用广播而不是单播呢?

一个广播域有多个DHCP服务器,当收到DHCP Discovery消息时,都会发送一个DHCP Offer消息,同时为即将分配的IP维持一个“待分配”的状态,这个状态一直会维持到IP地址成功分配、或者听到客户端没有选择自己的DHCP Request消息、或者超时释放。

 

如果客户端使用单播与幸运的DHCP服务器通信,其它落榜的DHCP服务器自然听不到它们窃窃私语的对话,只有被动等待状态的超时释放,在释放之前的这段时间,该IP地址无法被分配出去。

 

如果使用广播通信,其它DHCP服务器听到DHCP Request消息,会立马将状态释放掉,这当然是最合理的选择。

推荐↓↓↓
程序员的那点事
上一篇:新版IE认证有感 下一篇:如何看待思科取消CCIE Routing& Switching?