ARP

lidnux

一、ARP协议简介
ARP，全称Address Resolution Protocol，中文名为地址解析协议，它工作在数据链路层，在本层和硬件接口联系，同时对上层提供服务。
IP数据包常通过以太网发送，以太网设备并不识别32位IP地址，它们是以48位以太网地址传输以太网数据包。因此，必须把IP目的地址转换成以太网目的地址。在以太网中，一个主机要和另一个主机进行直接通
信，必须要知道目标主机的MAC地址。但这个目标MAC地址是如何获得的呢？它就是通过地址解析协议获得的。ARP协议用于将网络中的IP地址解析为的硬件地址（MAC地址），以保证通信的顺利进行。
1.  ARP和RARP报头结构
ARP和RARP使用相同的报头结构，如图1所示。


（图1　ARP/RARP报头结构）
硬件类型字段：指明了发送方想知道的硬件接口类型，以太网的值为1；
协议类型字段：指明了发送方提供的高层协议类型，IP为0800（16进制）；
硬件地址长度和协议长度：指明了硬件地址和高层协议地址的长度，这样ARP报文就可以在任意硬件和任意协议的网络中使用；
        
操作字段：用来表示这个报文的类型，ARP请求为1，ARP响应为2，RARP请求为3，RARP响应为4；
        
发送方的硬件地址（0-3字节）：源主机硬件地址的前3个字节；
        
发送方的硬件地址（4-5字节）：源主机硬件地址的后3个字节；
        
发送方IP（0-1字节）：源主机硬件地址的前2个字节；
        
发送方IP（2-3字节）：源主机硬件地址的后2个字节；
        
目的硬件地址（0-1字节）：目的主机硬件地址的前2个字节；
        
目的硬件地址（2-5字节）：目的主机硬件地址的后4个字节；
        
目的IP（0-3字节）：目的主机的IP地址。
2.  ARP和RARP的工作原理
ARP的工作原理如下：
1.  首先，每台主机都会在自己的ARP缓冲区 (ARP Cache)中建立一个 ARP列表，以表示IP地址和MAC地址的对应关系。
2.  当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址，如果有﹐就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
3.  网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址；
4.        源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。
RARP的工作原理：
1.  发送主机发送一个本地的RARP广播，在此广播包中，声明自己的MAC地址并且请求任何收到此请求的RARP服务器分配一个IP地址；
2. 本地网段上的RARP服务器收到此请求后，检查其RARP列表，查找该MAC地址对应的IP地址；
3. 如果存在，RARP服务器就给源主机发送一个响应数据包并将此IP地址提供给对方主机使用；
4. 如果不存在，RARP服务器对此不做任何的响应；
5. 源主机收到从RARP服务器的响应信息，就利用得到的IP地址进行通讯；如果一直没有收到RARP服务器的响应信息，表示初始化失败。
二、解码详解
了解了ARP和RARP协议的报头结构和工作原理后，我们使用科来网络分析系统抓取ARP包，其详细解码，如图1，


图1显示是一个ARP的请求包的解码，下面我们来详细说明：
硬件类型：1，表示硬件借口类型为以太网类型
        
协议类型：0x0800，表示发送方提供的高层协议类型是IP
        
硬件地址长度：表示硬件地址长度为6字节=48位
        
协议地址长度：表示IP地址长度为4字节=32位
        
操作类型：1，表示ARP请求
        
源物理地址：00:14:85:CA:F5:22
        
源IP地址：192.168.0.92
        
目标物理地址：00:00:00:00:00:00
        
目标IP地址：192.168.0.208
ARP回应包和RARP的包类似，我们在这里就不再重复说明

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/17895/showart_199671.html