DHCP协议概述( 二 )


在Windows的预设情形下,Dhcpdiscover的等待时间预设为1秒﹐也就是当客户端将第一个Dhcpdiscover封包送出去之后﹐在1秒之内没有得到回应的话﹐就会进行第二次Dhcpdiscover广播 。若一直得不到回应的情况下﹐客户端一共会有四次Dhcpdiscover广播(包括第一次在内)﹐除了第一次会等待1秒之外﹐其余三次的等待时间分别是9﹑13﹑16秒 。假如都没有得到DHCP伺服器的回应﹐客户端则会显示错误信息﹐宣告Dhcpdiscover的失败 。之后﹐基于使用者的选择﹐系统会继续在5分钟之后再重复一次Dhcpdiscover的过程 。
2.提供IP租用位址 。当DHCP伺服器监听到客户端发出的Dhcpdiscover广播后﹐它会从那些还没有租出的位址范围内﹐选择最前面的的空置IP,连同其它TCP/IP设定,回应给客户端一个DHCPOFFER封包 。
由于客户端在开始的时候还没有IP位址﹐所以在其Dhcpdiscover封包内会带有其MAC位址信息﹐并且有一个XID编号来辨别该封包﹐DHCP伺服器回应的Dhcpoffer封包则会根据这些资料传递给要求租约的客户 。根据伺服器端的设定﹐Dhcpoffer封包会包含一个租约期限的信息 。
3.接受IP租约 。假如客户端收到网路上多台DHCP伺服器的回应﹐只会挑选其中一个Dhcpoffer而已(通常是最先抵达的那个)﹐并且会向网路发送一个Dhcprequest广播封包﹐告诉所有DHCP伺服器它将指定接受哪一台伺服器提供的IP位址 。
同时﹐客户端还会向网路发送一个ARP封包﹐查询网路上面有没有其它机器使用该IP位址﹔假如发现该IP已经被占用﹐客户端则会送出一个DHCPDECLINE封包给DHCP伺服器﹐拒绝接受其Dhcpoffer﹐并重新发送Dhcpdiscover信息 。
事实上﹐并不是所有DHCP客户端都会无条件接受DHCP伺服器的offer﹐尤其这些主机安装有其它TCP/IP相关的客户软体 。客户端也可以用Dhcprequest向伺服器提出DHCP选择﹐而这些选择会以不同的号码填写在DHCPOptionField里面﹕
换一句话说﹐在DHCP伺服器上面的设定﹐未必是客户端全都接受﹐客户端可以保留自己的一些TCP/IP设定 。而主动权永远在客户端这边 。
4.租约确认 。当DHCP伺服器接收到客户端的Dhcprequest之后﹐会向客户端发出一个DHCPACK回应﹐以确认IP租约的正式生效﹐也就结束了一个完整的DHCP工作过程 。
如上的工作流程如下图:


DHCP发放流程
第一次登录之后﹕
一旦DHCP客户端成功地从伺服器哪里取得DHCP租约之后﹐除非其租约已经失效并且IP位址也重新设定回0.0.0.0﹐否则就无需再发送Dhcpdiscover信息了﹐而会直接使用已经租用到的IP位址向之前之DHCP伺服器发出Dhcprequest信息﹐DHCP伺服器会尽量让客户端使用原来的IP位址﹐假如没问题的话﹐直接回应Dhcpack来确认则可 。假如该位址已经失效或已经被其它机器使用了﹐伺服器则会回应一个DHCPNACK封包给客户端﹐要求其从新执行Dhcpdiscover 。
至于IP的租约期限却是非常考究的﹐并非如我们租房子那样简单﹐以NT为例子﹕DHCP工作站除了在开机的时候发出dhcprequest请求之外﹐在租约期限一半的时候也会发出dhcprequest﹐假如此时得不到DHCP伺服器的确认的话﹐工作站还可以继续使用该IP﹔然后在剩下的租约期限的再一半的时候(即租约的75%)﹐还得不到确认的话﹐那么工作站就不能拥有这个IP了 。至于为什么不是到租约期限完全结束才放弃IP呢﹖﹐对不起﹐小弟也是不学无术之人﹐没有去深究了﹐只知道要回答MCSE题目的时候﹐您一定要记得NT是这么工作的就是了 。
要是您想退租,可以随时送出DHCPLEREASE命令解约﹐就算您的租约在前一秒钟才获得的 。
跨网路的DHCP运作
从前面描述的过程中,我们不难发现:DHCDISCOVER是以广播方式进行的,其情形只能在同一网路之内进行﹐因为router是不会将广播传送出去的 。但假如DHCP伺服器安设在其它的网路上面呢﹖由于DHCP客户端还没有IP环境设定﹐所以也不知道Router位址﹐而且有些Router也不会将DHCP广播封包传递出去﹐因此这情形下DHCPDISCOVER是永远没办法抵达DHCP伺服器那端的,当然也不会发生OFFER及其他动作了 。要解决这个问题,我们可以用DHCPAgent(或DHCPProxy)主机来接管客户的DHCP请求﹐然后将此请求传递给真正的DHCP伺服器﹐然后将伺服器的回复传给客户 。这里﹐Proxy主机必须自己具有路由能力,且能将双方的封包互传对方 。

推荐阅读