DHCP协议概述

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

DHCP协议概述
要成功的将您的网路用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。

相关文档
最新文档