ARP逆过程——RARP协议流程

ARP逆过程——RARP协议流程

RARP协议是ARP协议相反的流程操作。那么它的具体规则我们在这里也来为大家呈现一下，希望能和ARP协议的流程做个对比学习，肯定会对您有所帮助的。刚才介绍的 ARP协议是透过向网路查询而找出实体地址﹐那我们接下来探讨的 RARP协议则相反﹕它是籍由查询网路上其它主机而得到自己的 IP协议地址。

通常﹐我们使用的乙太网卡﹐在出厂的时候就有生产厂家把网卡的实体地址烧在 ROM 里面﹐这个地址是不能改变的(某些型号的网路卡﹐或是透过其它技术手段﹐是允许您修改实体地址的)。不管系统是否起来﹐这个地址都会存在﹐而且要让系统获得它也很容易。然而，在一些无磁碟(diskless)工作站上面﹐系统档案都存放在远端的伺服器﹐当它在启动的时候﹐因为本身没有 IP协议地址﹐也就无法和伺服器沟通﹐更不能将系统档案载入。那么﹐我们就必须要有一个办法﹐让这样的无磁碟工作站在和伺服器沟通之前获得自己的 IP协议地址。RAPR 协定就是为解决此问题而设计出来的。

和ARP协议一样﹐RARP也是用广播的形式来进行查询﹐只不过这时候问的 IP协议地址不是别人﹐而是自己的 IP协议地址而已。我们可以从下图看出RARP协议的运作﹐其实和 ARP是极其相似的：

RARP的查询过

RARP的查询过程

首先是查询主机向网路送出一个 RARPRequest 广播封包﹐向别的主机查询自己的 IP。在时候﹐网路上的 RARP伺服器就会将发送端的 IP协议地址用 RARPReply 封包回应给查询者。这样查询主机就获得自己的 IP协议地址了。

然而不像 ARP﹐查询主机将 RARPRequest 封包丢出去之后﹐可能得到的 RARPReply 会不止一个 (在 ARP查询中﹐我们可以确定只会获得一个回应而已)。因为网路上可能存在不止一台 RARP伺服器(基于备份和分担考量﹐极有可能如此设计)﹐那么﹐所有收到 RARP请求的伺服器都会尝试向查询主机作出 RARPReply 回应。如果这样的话﹐网路上将充斥这种 RARP回应﹐做成额外的负荷。这时候﹐我们有两种方法来解决RARP的回应问题。

第一种方法﹐为每一个做 RARP请求的主机分配一主伺服器﹐正常来说﹐只有主伺服器才回做出 RARP回应﹐其它主机只是记录下接收到 RARP请求的时间而已。假如主伺服器不能顺利作出回应﹐那么查询主机在等待逾时再次用广播方式发送RARP协议请求﹐其它非主伺服器假如在接到第一个请求后很短时间内再收到相同请求的话﹐才会作出回应动作。

第二种方法也很类似﹕正常来说﹐主伺服器当收到RARP协议请求之后﹐会直接作出回应﹔为避免所有非主伺服器同时传回 RARP回应﹐每台非主伺服器都会随机等待一段时间再作出回应。如果主伺服器未能作出回应的话﹐查询主机会延迟一段时间才会进行第二次请求﹐以确保这段时间内获得非主伺服器的回应。当然﹐设计者可以精心的设计延迟时间至一个合理的间隔。

PROXY ARP

代理 (Proxy) ARP通常用来在路由器上代为回答。