网络：在启动时确定Internet地址(RARP)

青旅半醒 2022-10-05 00:59 94阅读 0赞

# 为什么需要RARP #

物理网络地址即依赖于底层协议又依赖于硬件，并且给每台使用TCP/IP的机器都分配了一个或者多个独立于硬件地址(即MAC地址)的32比特IP地址。当指定一个目的地时，应用程序总是使用IP地址。因为主机和路由器必须使用物理地址在底层硬件网络上传输数据报，它们依赖于ARP之类的地址转换协议完成在IP地址和相应硬件地址之间的映射。

通常，机器的IP地址保存在硬盘中，操作系统在启动时找到它。但是：“没有硬件的机器是如何确定自己的IP地址的？”（在使用网络协议之前，必须知道自己的IP地址）

寻找IP地址的思路很简单：需要知道自己地址的机器向另一台机器上的服务器发出请求(在发出的请求中必须唯一的标识自己，这样服务器才能做出正确的响应)，并等待服务器响应。我们假定服务器访问了存放互联网地址数据库的磁盘。发出请求的机器和相应的服务器在这个简短的通信中都使用了物理网络地址。请求放怎样才能知道对方的物理地址呢？通常它并不知道。它只简单的向本地网上所有机器广播这个请求。一个或者多个服务器会响应这个请求。

一旦某台机器广播了一个对地址的请求，它就必须唯一的标识自己。那么，在请求中包含什么样的信息才能达到这个目的呢？任何唯一的硬件标识(机器的物理网络地址)都可以。而且我们必须设计这样一个服务器：它能使用同一格式来接受物理网络上的所有机器的请求。

机器的物理网络地址唯一的标识自己的优势：这个地址总是可用的，而且不必放在人为启动代码中。于是，问题转换为：给出一个物理网络地址，设计一种方法使服务器把它映射成互联网地址。

允许计算机从服务器获得IP地址的TCP/IPP协议被称为方向地址转换协议RARP。

# RARP分组格式 #

RARP分组与[ARP分组][ARP]基本一致。它们之间的主要差别是RARP请求或者应答的帧类型为0x8035，而RARP请求的操作代码为3，应答操作代码为5、

RARP请求以广播方式传输，应答一般是单播传输的。

## 一般的例子 ##

![在这里插入图片描述][20210608150205548.png]

在第1行中，

*  源端主机（b s d i）的硬件地址是 8:0::20:3:FD:42 。
 *  目的端主机的硬件地址是ff : ff : ff : ff : ff : ff，这是一个以太网广播地址。电缆上的每个以太网接口都要接收这个数据帧并对它进行处理
 *  rarp who is … 表示请求将 8:0::20:3:FD:42 的IP地址告知8:0::20:3:FD:42

第2行：

*  ARP应答直接将应答发送到8:0::20:3:FD:42 ，而不是广播
 *  rarp reply…回答了响应者的主机名(可以通过DSN找到IP地址1 4 0 . 2 5 2 . 1 3 . 3 3)和硬件地址

第3行：

*  可以看出，一旦收到IP地址，它就发送一个TFTP读请求(RRQ)给文件8 C F C0D21.SUN4C（TFTP表示简单文件传送协议。）文件中的8个十六进制数字表示主机的IP地址140.252.13.33。这个IP地址在RARP应答中返回。文件名的后缀SUN4C表示被引导系统的类型
 *  tcpdump在第三行中指出了IP数据报的长度是65个字节。

从这个例子可以看出，当无盘系统从RARP应答中收到它的IP地址之后，它将发送FTFP请求来读取引导映像。

## 网络上没有RARP服务时的例子 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

*  每个分组的目的地址都是以太网广播地址。在who- 后面的以太网地址是目的硬件地址，跟在t e l l后面的以太网地址是发送端的硬件地址。
 *  请注意重发的频度。第一次重发是在 6.55秒以后，然后增加到 42 .80秒，然后又减到5.34秒和6.55秒，然后又回到 42.79秒。这种不确定的情况一直继续下去。如果计算一下两次重发之间的时间间隔，我们发现存在一种双倍的关系：从5.34到6.55是1.21秒，从6.55到8.97是2.42秒，从8.97到13.80是4.83秒，一直这样继续下去。当时间间隔达到某个阈值时（大于42.80秒），它又重新置为5.34秒。超时间隔采用这样的递增方法比每次都采用相同值的方法要好。

# RARP服务器的设计 #

虽然RARP在概念上很简单，但是一个RARP服务器的设计与系统相关而且比较复杂。相反，提供一个ARP服务器很简单，通常是 TCP/IP在内核中实现的一部分。由于内核知道 IP地址和硬件地址，因此当它收到一个询问IP地址的ARP请求时，只需用相应的硬件地址来提供应答就可以了。

## 作为用户进程的RARP服务器 ##

RARP服务器的复杂性在于，服务器一般要为多个主机(网络上的所有无盘系统)提供硬件地址到IP地址的映射。该映射包含在一个磁盘文件中。由于内核一般不读取和分析磁盘文件，因此RARP服务器的功能就由用户进程来提供，而不是作为TCP/IP实现的一部分。

更为复杂的是，RARP请求是作为一个特殊类型的以太网数据帧来传输的（帧类型字段值为0x8035），这说明RARP服务器必须能够发送和接收这种类型的以太网数据帧。由于发送和接收这些数据帧与系统有关，因此RARP服务器的实现与系统捆绑在一起的

## 每个网络中有多个RARP服务器 ##

RARP服务器实现的一个复杂因素是RARP请求是在硬件层进行广播的。这意味着它们不经过路由器转发。为了让无盘系统在RARP服务器关机时也能引导，通过在一个网络上需要提供多个RARP服务器。

多台RARP服务器可以使得系统更加可靠。

*  如果一个服务器失效或者由于负载过重而来不及响应，另一个服务器就会响应请求。
 *  缺点是当一台服务器广播一个RARP请求时，如果所有服务器都试图响应，网络就会超载。

怎样组织RARP服务才能使它可靠可用又不会导致多个服务器同时应答呢？至少有两种解决方案，它们均采用延迟响应技术：

*  第一种方案：给每台发出RARP请求的机器都分配一个主服务器。正常情况下，只有主服务器响应RARP请求；备份服务器接收到请求后只记录它到达时间。如果主服务器不可用了，原来的机器会因为等待响应而超时，然后重新广播这个请求。一旦备份服务器在短时间内收到一个RARP请求的第二个副本时，就会响应
 *  第二种方案采用类似方法，但试图避免所有备份服务器同时响应。每台备份服务器收到请求后会等待一段随机时间后才响应。正常情况下，主服务器是立即响应。通过精心设计延迟时间，设计人员可以确保发出请求的机器在收到答复之间不会再次广播

# RARP详解 #

与ARP类似，RARP报文是封装在一个网络帧的数据部分中，并从一台机器发送到另一台机器的。

下图演示了主机是如何使用RARP：发送方广播一个指定它自己即是发送方又是接收方的RARP请求，并把它自己的物理网络地址放到目标硬件地址字段中。网络上的所有机器都接收到该请求，但只有被授权提供RARP服务的机器才能处理请求并做出应答。要成功使用RARP，网络中必须至少包含一个RARP服务器。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]  
服务器对请求的回答方式是：填写目标协议地址字段，并把报文类型从“请求”改为“应答”，然后直接把应答发回提出请求的机器。发出请求的机器收到了所有RAPR服务器的应答，但它只需要第一个。

注意：对于寻找自己IP地址的机器和提供这一地址的服务器，它们之间的所有机器都只能使用物理网络实施。另外，协议还允许主机询问任意目标主机的地址。因此，发送发分别提供自己和目标主机的硬件地址，而服务器要把应答发送到发送发的物理地址上。

# 处理RARP事务的时间 #

RARP请求和响应很容易丢失。因为RARP直接使用物理网络，所以没有其他协议软件限定响应时间或者重发请求，RARP软件必须承担这些任务。

某些依赖RARP启动的计算机，采用无限重试的方法知道收到一个响应；某些则在重试几次之后就宣布失败，以避免因为不必要的广播导致网络拥塞。因此，使用大的时延保证了服务器有足够时间响应RARP请求，并做出应答。

# 总结 #

启动系统时，没有硬盘的计算机在使用TCP/IPP通信之前必须与服务器联络，以找到自己的IP地址。RARP机器提供目标机器的物理硬件地址，以唯一的标识处理器并广播RAPR请求。网络上的服务器接收到请求后，在一个表(比如硬盘)中查找映射，并应答发送方。一旦机器获得它的IP地址，就把地址存储在主存中，知道重新启动之前都不再使用RARP。

[ARP]: https://blog.csdn.net/zhizhengguan/article/details/117401701
[20210608150205548.png]: /images/20221005/d61acf2db7724b11b51866f9a51d072d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221005/777cd3293057484cb972c653b1ad1521.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221005/841fa63d26c2423099040908fda304cb.png