Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2484625
  • 博文数量: 609
  • 博客积分: 10061
  • 博客等级: 上将
  • 技术积分: 5920
  • 用 户 组: 普通用户
  • 注册时间: 2008-06-25 08:30
文章分类

全部博文(609)

文章存档

2010年(13)

2009年(39)

2008年(558)

我的朋友

分类: 系统运维

2008-08-14 10:37:19

DHCP协议概述
 

经过了前面的学习,相信您不再认为设定与管理 TCP/IP网路是件轻松的事情。要成功的将您的网路用TCP/IP连接起来,您就得为每台电脑设定IP、mask、gateway、等等繁琐的事情。要是您想管理好一个比较大的网路﹐或是电脑节点经常改变(如手提电脑或拨接)﹐这样的工作可以说是非常令人讨厌的﹐而且出错的机会也比较多。要是,万一日后要进行IP重新规划﹐其工作量也是相当惊人的。
面对这些情形﹐DHCP可以说您的菩萨了﹕它不但救苦救难﹐而且神通广大。
什么是DHCP?
DHCP 是DynamicHostConfigurationProtocol之缩写﹐它的前身是BOOTP。BOOTP原本是用于无磁碟主机连接的网路上面的﹕ 网路主机使用BOOTROM而不是磁碟起动并连接上网路﹐BOOTP则可以自动地为那些主机设定TCP/IP环境。但BOOTP有一个缺点:您在设定前须事先获得客户端的硬体位址,而且,与IP的对应是静态的。换而言之,BOOTP非常缺乏"动态性",若在有限的IP资源环境中,BOOTP的一对一对应会造成非常可观的浪费。

DHCP可以说是BOOTP的增强版本﹐它分为两个部份﹕一个是伺服器端﹐而另一个是客户端。所有的IP网路设定资料都由DHCP伺服器集中管理﹐并负责处理客户端的DHCP要求﹔而客户端则会使用从伺服器分配下来的IP环境资料。比较起BOOTP,DHCP透过"租约"的概念,有效且动态的分配客户端的TCP/IP设定,而且,作为兼容考量,DHCP也完全照顾了BOOTPClient的需求。
DHCP的分配形式
首先﹐必须至少有一台DHCP工作在网路上面﹐它会监听网路的DHCP请求﹐并与客户端搓商TCP/IP的设定环境。它提供两种IP定位方式﹕
AutomaticAllocation
自动分配﹐其情形是﹕一旦DHCP客户端第一次成功的从DHCP伺服器端租用到IP位址之后﹐就永远使用这个位址。
DynamicAllocation
动态分配﹐当DHCP第一次从HDCP伺服器端租用到IP位址之后﹐并非永久的使用该位址﹐只要租约到期﹐客户端就得释放(release)这个IP位址﹐以给其它工作站使用。当然﹐客户端可以比其它主机更优先的延续(renew)租约﹐或是租用其它的IP位址。


动态分配显然比自动分配更加灵活﹐尤其是当您的实际IP位址不足的时候﹐例如﹕您是一家ISP﹐只能提供200个IP位址用来给拨接客户﹐但并不意味着您的客户最多只能有200个。因为要知道﹐您的客户们不可能全部同一时间上网的﹐除了他们各自的行为习惯的不同﹐也有可能是电话线路的限制。这样﹐您就可以将这200个位址﹐轮流的租用给拨接上来的客户使用了。这也是为什么当您查看IP位址的时候﹐会因每次拨接而不同的原因了(除非您申请的是一个固定IP﹐通常的ISP都可以满足这样的要求﹐这或许要另外收费)。当然﹐ISP不一定使用DHCP来分配位址﹐但这个概念和使用IPPool的原理是一样的。
DHCP 除了能动态的设定IP位址之外﹐还可以将一些IP保留下来给一些特殊用途的机器使用﹐它可以按照硬体位址来固定的分配IP位址﹐这样可以给您更大的设计空间。同时﹐DHCP还可以帮客户端指定router﹑netmask﹑DNSServer﹑WINSServer﹑等等项目﹐您在客户端上面﹐除了将 DHCP选项打勾之外﹐几乎无需做任何的IP环境设定。

DHCP的工作原理
视乎客户端是否第一次登录网路﹐DHCP的工作形式会有所不同。
第一次登录的时候﹕
1. 寻找Server。当DHCP客户端第一次登录网路的时候﹐也就是客户发现本机上没有任何IP资料设定﹐它会向网路发出一个DHCPDISCOVER封包。因为客户端还不知道自己属于哪一个网路﹐所以封包的来源位址会为0.0.0.0﹐而目的位址则为255.255.255.255﹐然后再附上 Dhcpdiscover的信息﹐向网路进行广播。
在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主机必须自己具有路由能力,且能将双方的封包互传对方。
若不使用Proxy,您也可以在每一个网路之中安装DHCP伺服器﹐但这样的话﹐一来设备成本会增加﹐而且﹐管理上面也比较分散。当然啰﹐如果在一个十分大型的网路中﹐这样的均衡式架构还是可取的。端视您的实际情况而定了。
DHCP封包格式


以下为各栏位的简要说明:
OP
若是client送给server的封包,设为1,反向为2。
HTYPE
硬体类别,Ethernet为1。
HLEN
硬体位址长度,Ethernet为6。
HOPS
若封包需经过router传送,每站加1,若在同一网内,为0。
TRANSACTIONID
DHCPREQUEST时产生的数值,以作DHCPREPLY时的依据。
SECONDS
Client端启动时间(秒)。
FLAGS
从0到15共16bits,最左一bit为1时表示server将以广播方式传送封包给client,其余尚未使用。
ciaddr
要是client端想继续使用之前取得之IP位址,则列于这里。
yiaddr
从server送回client之DHCPOFFER与DHCPACK封包中,此栏填写分配给client的IP位址。
siaddr
若client需要透过网路开机,从server送出之DHCPOFFER、DHCPACK、DHCPNACK封包中,此栏填写开机程式码所在server之位址。
giaddr
若需跨网域进行DHCP发放,此栏为relayagent的位址,否则为0。
chaddr
Client之硬体位址。
sname
Server之名称字串,以0x00结尾。
file
若client需要透过网路开机,此栏将指出开机程式名称,稍后以TFTP传送。
options
允许厂商定议选项(Vendor-SpecificArea),以提供更多的设定资讯(如:Netmask、Gateway、DNS、等等)。其长度可变,同时可携带多个选项,每一选项之第一个byte为资讯代码,其后一个byte为该项资料长度,最后为项目内容。


DHCP的选项非常多,有空请查阅RFC或相关文献,并好好理解,这里不再叙述了。
DHCP协定之RFC文件
RFC-951﹑RFC-1084﹑RFC-1123﹑RFC-1533﹑RFC-1534﹑RFC-1497﹑RFC-1541


阅读(577) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~