Spring中的aware接口详情
1123
2022-09-20
深入解析DHCP带来了什么功能,服务器回应到底是用广播还是单播呢?
前言
不知道大家在看到这个图的时候第一时间想到的是什么,【好复杂】【看不懂】【终端数好多】,这里不看整体的结构怎么样,来看看终端数量都非常的多,终端要与网络中进行通信,势必需要IP地址,从最开始学习到现在好像都是手动去设置的终端IP地址,如果一个网络中有几百台、几千台的终端设备,难道需要IT维护人员一个一个去设置吗,那工作量太大了,并且如果涉及到整改,比如换了一个新的网段,那岂不是之前设置的又需要重新修改,那估计TCP/IP的体系也没人使用了,使用起来太麻烦,不方便维护跟扩展,所以呢,出了一个应用层协议---DHCP。
DHCP带来了什么功能?
回想下自己平时电脑、手机、平板在接入无线路由器后是不是直接就可以上网了,并没有说去设置IP、掩码、网关等参数,这正式因为家用路由器默认是开了DHCP,而使用的终端设备也处于DHCP模式下,所以接上去就可以自动从家用路由器获取对应的参数信息,然后进行上网,是不是就简化了操作,因为实际中不可能指望普通用户还懂什么IP地址设置,所以DHCP出来解决了这个问题。
终端跟DHCP是如何交互的呢?
刚开机的终端由于是自动获取模式,那它本身是没有IP地址等参数的,那它怎么跟服务器去进行沟通呢?搭建一个环境,来看看整个过程。
DHCP服务器配置还没有讲解,这个提前做好了,该环境会直接发出,大家直接打开就可以。
(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小时),会进行第一次续期,在租期到了75%的时候会进行第二次续期,有两次续期的存在,是担心中途在第一次续期的时候,恰巧DHCP服务器出现了某些故障,没法收到这个包,导致续期失败。三个时间的作用相信大家就明白了,当一个客户端获取到地址后,如果正常使用租期50%或者75%会进行续期,成功后该地址可以继续使用,如果获取地址后,使用了一会就走了,在Lease Time时间后,该地址会被服务器释放掉,分配给其他用户。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~