网络安全 on 云雾海的博客

蓝牙协议HCI抓包实验

Mon, 17 Nov 2025 18:31:28 +0800

蓝牙协议HCI抓包实验

实验准备

实验硬件

一台电脑
一台安卓手机（以VIVO手机为例）
一个蓝牙设备（以小米手环为例）
一根手机数据线

实验软件

安卓调试桥（ADB工具）

实验步骤

软件安装

下载ADB工具

访问链接后，根据电脑平台选择软件包

解压文件

下载得到一个压缩包，将其解压缩到一个文件夹中，并打开该文件夹

检查下载

在该目录下右键选择在终端中打开，或可以先行打开终端然后跳转到该目录。

输入.\adb.exe --version来检查是否可用，如果正常，应该会显示版本号。

手机设置

打开开发者模式

现在的安卓手机，开发者选项是隐藏的，需要手动打开开发者模式才能看到。

根据不同手机，可能有不同打开开发者模式的方法，vivo手机的方式是进入设置-关于手机-版本信息，连续点击软件版本号，即可开启开发者模式。大部分手机应该也是类似的方式，如果该操作不行，请自行搜索自己手机的开启方式。

开启日志功能

进入设置中，选择开发者选项，并将启用蓝牙HCI信息收集日志选项设置为启用。注意：如果此时蓝牙已经启动，应该将其关闭后重启，然后蓝牙日志就将开始记录。

开启USB调试功能

为了电脑能够读取日志，需要开启USB调试功能。

完成一次数据传输

正常情况下，手环只要是用过的，在手机蓝牙开启后都会自动连接到手机上，不过为了测试，我们可以手动打开手环软件，比如小米的运动健康，然后刷新手环数据。此时理论上我们的手机和手环会进行如下通信：手机告知手环自己需要的数据，手环将数据传输给手机，当然它们可能还会参杂一些其他相关的认证消息，但是总体内容应该差不多就是这些。

在完成了这个操作后，为了数据干净，就可以选择关闭蓝牙了，我们的通信日志已经被记录下来了。

开始调试

连接电脑

我们现在需要的工作就是将通信日志保存到电脑中，此时就需要用到我们的ADB调试工具了。首先将手机通过数据线连接电脑。

因为开启了USB调试模式，此时会弹窗问是否允许该电脑进行调试，选择允许即可。

然后选择传输模式为管理文件。

此时，我们的电脑已经可以对其进行调试了。

ADB读取报告

通过.\adb.exe bugreport然后加压缩包文件名的方式，可以将日志下载到一个压缩包中，该过程需要一两分钟。

下载完成后就可以解压缩该压缩包，然后通过访问这个路径，可以找到蓝牙日志。如果是其他手机，不确定是不是一样的，但是可以通过搜索hci和log两个关键字来查找。

其中btsnoop_hci.log.last就是我们的目标文件了，当然根据实际情况可能没有.last文件，此时只有.log文件大概率也是对的。

查看抓包内容

找到连接

打开WireShark，将btsnoop_hci.log.last拖拽进去打开。

现在我们关注Source和Destination，只要其中出现了我们的设备名，就说明抓包成功了。

可以发现，我们的手机先给手环发送了一个L2CAP发送包，然后手环回了一个L2CAP的接收包。我们知道L2CAP是用于蓝牙协议中建立连接的，故此可以知道我们的通信成功了。

观察数据

我们继续往下观察，可以发现RFCOMM协议的几个包，我们知道RFCOMM协议是用于构建虚拟串口的，显然这里是在构建通信连接。

而后我们继续观察，可以发现过了一段时间后，突然出现了大量的SPP包，我们知道这个包适用于规范RFCOMM传输内容的，而且通过数据包长度也可以知晓，这显然就是在传输我们的手环数据给手机。

让我们点开其中的一个看一下里面的数据：

这部分数据是data部分的内容，而具体内容则是非常杂乱的，我们在此可以猜测这个数据大概率是加密的数据，需要在手机软件中才会解密，防止被中间截获。

WireShark抓包实验

Wed, 15 Oct 2025 22:49:58 +0800

WireShark抓包实验

目标

掌握TCP/IP网络体系结构的网络接口层、网络层、传输层和应用层典型协议（Ethernet II、IP、TCP、ICMP、HTTP）的分析。
分析常用即时通讯软件的通信过程。

实验内容

抓包PING

Ping命令是一种常用的网络诊断工具，用于测试两台计算机之间的连通性。本次实验中我们通过Ping命令访问百度的网址，并对整个过程进行抓包分析。

我们打开WireShark然后进入抓包界面，并开始抓包。
我们打开命令行，然后输入指令ping www.baidu.com。

分析DNS

DNS查询报文：因为我们不知道百度的IP地址，所以我们使用域名进行访问，而这个过程中，Ping会向DNS服务器寻求百度的IP地址，然后DNS服务器会返回它的IP地址。我们可以在WireShark中可以发现这两个包。

首先让我们分析一下请求包，首先我们可以从统计表中得知数据是从172.20.*.*这个网址发出去的，这个就是我们的IP地址，根据网段不难得知这是一个私网网址。根据Protocol可以得知这是一个DNS包，而通过Info可以得知本次DNS查询是一次标准查询，通讯ID号是0x1c2d，而其中的A表示查询记录类型是IPv4地址（因为我这里的网络没有通IPv6，如果是IPv6，则应该为AAAA)，而后面跟的就是我们想要查询IP的网址www.baidu.com。让我们看看报文内容。

首先让我们看看Ethernet II，即以太网帧（其中不重要的内容还有隐私内容已被我打码，下同）：

我们可以在其中找到我们的以太网帧的帧头，这其中包含了目标MAC地址和源MAC地址，以及帧里面的数据包类型。在WireShark中，我们可以看到右边是实际发送的数据，左边是其解析的含义。

接着我们观察IPv4报头，这是属于网络层的内容：

其中重要的就是我们的源IP地址和目标IP地址，这里我的主机也就是源IP是172.20.*.*，目标IP是DNS服务器61.139.2.69。不过我们也可以关注一下其它部分，首先开头的45中4代表IPv4，5代表IP首部长度为5x4=20字节。*Differentiated Services Field（区分服务字段）*则是用于改善流量转发效果的，此处DSCP=00(CS0)让路由器默认处理该数据包，不改变其优先级，而ECN=00(Not-ECT)则代表不支持ECN显式拥塞通知功能。而后的3b代表IP数据包的总长度为59字节。而后4c f8代表其标识符ID。再后面的0000则依次代表Flag(3bit)=0(可以分片但是没有分)，Fragment Offset(13bit)=0(片偏移量为0)。而后80代表该报文生存时间为128跳。后面的11代表报文所用协议为UDP。然后又是个0000，代表首部校验和为0，用于校验IP头部的完整性。再然后就是源IP地址和目标IP地址了，前面已经说过。

再往下则是UDP的报文内容。

UDP报文的内容包括源端口号（2byte）、目的端口号（2byte）、UDP报文长度（2byte）、校验和（2byte）。

然后后面就是我们的DNS报文了，这一部分根本目的是为了顺利获取到域名对应的IP地址：

其事务ID（Transaction ID）为0x1c2d，代表该查询的唯一标识，这个查询报文对应的响应报文其事务ID也会是这个。Flags的值为0x0100，则代表了这是一个标准（Opcode=0)查询（Response=0）且授权应答位（Authoritative，在左侧未标注，但是可以观察到Opcode和Truncated中间有一个0，这一位只有在响应报文中有用）和截断位（Truncated）均未设置（=0），期望递归位已设置（Recursion desire=1，这个可以递归解析器，而不需要客户端自己去遍历根、TLD等服务器）、可递归位未设置（Recursion available，在Recursion desire和Z中间有一个0，这一位只有在响应报文中有用），保留位为0（Z=0），应答认证位（Answer authenticated，在Z和Non-authenticated data中间有一个0，表示服务器已经验证了DNSSEC签名，并确认数据是经过认证的，即来自权威源且未被篡改，这个只在响应报文中有用），禁用DNSSEC验证位（CD，即是否需要禁用前面的AD验证，0表示没有禁用，不过因为这里是查询报文，所以WireShark中显示的是Non-Authenticated data）。之后是连续4个2字节的计数字段分析，Questions=1代表报文中包含一个查询问题，后续三个都是在响应报文中才会出现的数据。至于Queries中的数据其实就是查询部分了，域名占用了13个字节（包括点号），不过我们仔细查看报文其实可以发现，这里的点号是用计数的方式来表示实现的，例如最开始的03 77 77 77其实代表了www，而03其实代表的接下来的一个标签（也就是www）长度为3，后续的baidu是05，com 是 03也是同理，而最后面还需要跟一个00作为结束符表示后面没有标签了。再后面的00 01代表希望查询的IP类型是A，即IPv4。最后的00 01则代表Class是Internet类，即互联网，这是最常用的类别。至此我们对于DNS查询报文的分析完成。
DNS响应报文：关于响应报文，前面的以太网帧头、IP报头、UDP协议包头都没有什么继续分析的必要了，因为本质上和查询报文没有区别，只是方向反过来而已。我们重点关注最后的DNS部分：

首先事务ID和查询报文是一样的。其次，它的Flags中Response变为了1，代表是响应报文。Opcode为0000，则仍代表该查询是标准查询。授权应答位Authoritative=0，代表该服务器不是该域名的权威服务器。Truncated为0代表报文没有截断，完整返回。Recursion Desire为1代表客户端希望递归查询。Recursion Desire为1代表服务器支持递归查询，提供递归服务。Z是保留位为0。Answer Authenticated为0表示该答案部分没自由经过DNSSEC认证，Checking Disabled为0代表没有禁用DNSSEC认证。Questions为1表示查询部分包含1个问问题，Answer RRs为3表示有三个资源记录，剩下两个都是0代表没有授权服务器信息和没有附加信息，全是字面意思。Queries和查询报文一样。我们重点还是看Answers部分，这是这个响应报文的核心部分。我们从Answer RRs中可以知道，我们有三个答案记录，而第一个记录的Name是www.baidu.com，Type是CNAME，Class是Internet。我们应当注意的是，这里的Name在报文中显示的数据是c0 0c，这里其实是代表的一个类似于指针的设置，用于指示重复的域名以缩减报文传输量，c的二进制是1100，其中11其实代表的就是这是个指针，而后的00以及后面的12bit，共同组成了偏移量，这样它就指示到了从DNS报文的0字节开始，往后第12字节开始的那个域名，正是wwww.baidu.com，后面出现类似情况也是同理。然后我们注意这里的Type是CNAME，也就是说它其实是检测到一个别名了，而这个别名的值是www.a.shifen.com，这个是百度以前的一个广告系统的网址，看来百度是直接把它的www.baidu.com域名连接到这个域名上了，它还可以将其它域名的别名也设置成这个，这样未来如果需要迁移地址，只需要迁移这个域名的地址就可以了。然后我们可以查看下面这个域名，检测到两个IP，分别是183.2.172.177和183.2.172.17，看样子百度用了多IP轮询机制来实现负载均衡或者容灾备份。最终从我们的Ping命令效果来看，我们最终应该是选用了第一个，或者说当时第一个就可以联通，不需要使用第二个备用IP了。

分析ICMP

ICMP报文：在获取到DNS响应报文后，程序即获得了IP地址，此时即可以通过ICMP报文与服务器通信。PING命令会连续发送四条ICMP报文，并根据返回报文计算连通性性和通信时间，我们只需要分析其中一对即可。

ICMP报文由三部分组成：以太网帧头、IP报头和ICMP协议数据部分。其中前两者和DNS相比差不多，只是内容存在部分差异，我们就不重复详细分析了。重点针对ICMP协议数据部分进行讨论：

我们首先观察Type=8，其代表了这是一个回显请求，即ping的发送端。而Code=0则代表了无特殊错误码，正常请求。Checksum=0x4d2c是一个校验字段，用于验证报文完整性，已校验通过。Identifier(BE)=1表示发送大端格式的进程标识符，通常是进程的ID或者PID，此处为1。Identifier(LE)=256表示小端格式的进程标识符，对应了BE的值，本质上其实就是同一个值。Sequence Number(BE)=47表示大端格式的序列号，LE=12032表示小端格式的序列号，本质上就是同一个值。而后的Data部分有32个字节，根据ASCII码不难发现，其实发送的内容本质就是abcdefghijklmnopqrstuvwabcdefghi，其目的其实就是为了填充数据，没有实际含义。接下来让我们查看响应报文：

不难发现，其实内容也没有什么区别，只有Type变为了0，代表这是回显应答，即ping的响应端。校验和在值上发生了改变但是结果仍然正确没有问题。并且我们可以看到Response time=35.251ms，与我们在终端看到的35ms是对应的，这其实是抓包工具计算出的时间，并不在报文之中。

分析HTTP

HTTP报文：现在让我们分析一下方法百度的三次握手包。因为只是初次尝试，我们选择访问HTTP的百度。通过在命令行中运行nslookup baidu.com这个代码获取百度网页的ip地址。

应答中出现了两个地址，我们选择访问第一个试试，在此之前记得打开Wireshark：

看来没问题，然后我们在Wireshark中添加过滤来找到这个访问，输入ip.host == 39.156.70.37然后回车即可：

然后我们就可以查看显示结果了：

可以发现，不知道为何，我们这里出现了两个三次握手，不过下面有一个HTTP报文，可以通过它来分析哪一个才是我们需要的。其中关于以太网帧和IP数据包的部分仍然可以忽略，让我们观察TCP部分：

TCP部分可以注意到其Source Port是59049，Destination Port是80，说明我们只需要找到上方同样通信Port是59049和80的报文就可以了，刚好有三个，可以组成三次握手。其它的都是一些传输信息，我们不需要太关注。HTTP报文中在TCP后面还有一个HTTP部分，这一部分其实就是该网页的一些基础信息，不同网页内容也不一样，这里我们也同样不关注。

分析三次握手

三次握手报文：在三次握手中，我们主要需要关注的还是TCP部分。

这是第一次握手的内容：

我们可以注意到其Flags的SYN标志被置为1了，这是而ACK仍为0，所以这显然是第一次握手的内容。而Sequence Number初始为0，因为这是当前客户端的第一个报文。Acknowledgment Number被设置为0，因为这是第一次握手。Options中则设置了包括分块等一系列设置，这会在前两次握手中出现。

现在我们观察第二次握手的报文：

这一次我们可以看到Flags中的ACK被置为1了，而Syn也仍然为1，可以判断这是第二次握手。Sequence Number也仍然为0，因为这是服务器的第一个报文。而Acknowledgment Number则为1，因为已经接收到一次报文了。Options仍然有一些反馈设置。

我们观察第三次握手报文：

在这一次中，Flags中只有ACK被置为1，同时Sequence Number变成了1，Acknowledgment Number也变成了1，符合我们的发送接收情况。同时我们可以注意这一次没有Options了。

至此，我们的三次握手分析完毕。

分析微信

接下来我们简单分析一下微信的数据传输，首先我们需要确定微信通信的IP地址，这个过程非常简单，我们只需要打开资源管理器并选中网络部分，接着给文件传输助手发送一个比较大的文件，然后观察资源管理器中的变化就可以了。

显然，我们获知了微信的IP地址，现在让我们在筛选器中填入ip.addr == 219.153.153.110就好了，接着我们会发现一大堆GQUIC报文：

关于QUIC的介绍可以参考《QUIC协议详解》，而gQUIC则是谷歌的版本，与其相对的是IETF版本的iQUIC。

我们通过前面的介绍还有名字不难发现微信使用的QUIC协议本质上其实就是一种UDP的传输层协议，在协议中通过QUIC将实际需要发送的UDP数据加密打包发送。

总结

通过本次实验，我们完成了包括针对PING、三次握手、微信传输三个大流程中使用到的各个报文的抓包和协议解析，基本掌握了WireShark的操作方法和筛选技巧，以及针对具体应用（如微信）如何通过资源管理器进行限位，以快速找到通信IP地址实现抓包。

使用IIS组件搭建服务器（HTTPs）

Sun, 05 Oct 2025 19:28:38 +0800

使用IIS组件搭建服务器（HTTPs）

目标

根据《使用IIS组件搭建服务器（Web）》，将原本HTTP网站改为HTTPS网站，注意你应该已经完成了该文章所述的所有步骤。

步骤

创建签名

因为HTTPS需要安全签名，所以我们要创建一个，如果你需要将其应用于公网，也可以自行申请一个。不过我们只是实验，创建一个本地用就够了。

在IIS管理器中，选择计算机名称（不是某个网站），然后在中间的功能视图中，双击服务器证书。
在右侧选择“创建自签名证书”。
输入证书名称，然后确定。

绑定HTTPS

右键点击你原本的HTTP网站，然后选择编辑绑定。
点击添加。
类型选择https，SSL证书选择刚刚创建的证书，其它全部保持默认即可。然后点击确定。你网站的https就配置好了。

测试

直接访问https://localhost，你可能收到浏览器的警告，这是因为我们的SSL是自己创建的，并不被公共认可，浏览器认为其可能不安全。此时强制访问即可。

使用IIS组件搭建服务器（FTP）

Sun, 05 Oct 2025 19:28:30 +0800

使用IIS组件搭建服务器（FTP）

目标

使用IIS组件搭建一个Web服务器。

步骤

启用IIS功能

IIS在Windows中是默认关闭的，需要手动启用。

打开控制面板，选择“程序”
进入程序界面，选择“程序和功能”。
进入程序和功能界面，选择“启用或关闭Windows功能”
展开“Internet Information Services”，将“FTP服务器”中的所有选项勾上。

点击确定后等待系统自动安装所需文件，完成后点击关闭即可。

添加FTP站点

按Win+R，输入inetmgr，然后打开“IIS管理器”。在左侧连接框中展开计算机，然后右键点击站点，选择“添加FTP站点”。
在信息填写界面，根据你的喜好输入一个网站名称，物理路径你可以根据需要在一个地址创建一个文件夹并选中，这会是你的FTP根目录，例如我的C:\Workspace\Test\FTPService。你可以在这个路径下创建一些文件，你可以随意在文件中写一些东西，以便于等会测试用。之后点击下一页。
IP地址选择“全部未分配”（这样我们可以直接使用环回地址127.0.0.1来进行测试），端口使用默认的21端口，SSL选择“无SSL”（因为我们没有SSL，而且只是测试用，没必要设置）。点击下一页。
身份验证我们选择基本，这样需要输入用户名和密码，然后再授权中选择所有用户，并给他们权限。这里其实无所谓如何设置，因为只是我们自己测试使用。设置完成后点击完成即可。
如无意外，你可以看到你左侧网站界面多了一个你刚才创建的FTP网站，点击它，中间的界面就会变成FTP的管理界面。

使用命令行访问FTP

现在你已经可以访问FTP了，打开一个命令行，例如Powershell，然后导航到一个你希望下载文件的路径。例如C:\Workspace\Test\FTPDownload。使用指令ftp 127.0.0.1访问FTP服务器。然后输入用户名和密码，这个用户名和密码就是你当前登录的Windows账户的用户名和登录密码。此时你就可以登录到FTP服务器中了，此时输入ls即可查看当前FTP服务器中的文件，使用get "文件名" ["重命名"]即可将获取文件。使用完毕后，输入quit即可退出访问。

此时我们的路径下就获得了FTP中的文件。

使用IIS组件搭建服务器（Web）

Sun, 05 Oct 2025 19:28:13 +0800

使用IIS组件搭建服务器（Web）

目标

使用IIS组件搭建一个Web服务器。

步骤

启用IIS功能

IIS在Windows中是默认关闭的，需要手动启用。

打开控制面板，选择“程序”
进入程序界面，选择“程序和功能”。
进入程序和功能界面，选择“启用或关闭Windows功能”
勾选“Internet Information Services”旁边的复选框，这会默认勾选大部分子项，我们只需要这些默认的子项即可，不过你也可以检查一下是否和我的一样。注意下面的“可承载的Web核心”不需要勾选，这部分更加类似于一个可被编程调用的库，并非我们本次实验的目的。

点击确定后等待系统自动安装所需文件，完成后点击关闭即可。

创建网站文件夹和内容

在合适的地方创建一个文件夹用于管理你的网站，例如我的C:\Workspace\Test\WebService。

创建首页文件：在你创建的文件夹中创建一个名为index.html的文件，使用记事本或你的文本编辑器打开它并修改内容。你可以在其中添加一些简单的HTML内容，例如：

<!DOCTYPE html>
<html>

<head>
 <title>IIS Web服务测试</title>
 <meta charset="UTF-8">
 <meta lang="zh-CN">
</head>

<body>
 <h1>这是IIS Web服务测试</h1>
 <p>欢迎使用IIS Web服务</p>
</body>

</html>

在IIS管理器中创建网站

现在使用IIS管理器来配置网站。按住Win+R，输入inetmgr，然后回车。也可以在开始菜单搜索“IIS”或“Internet Information Services(IIS)管理器”。
展开左侧“连接”面板中计算机名称，然后右键点击站点，选择“添加网站”。
接下来在打开的网站信息填写界面，根据你的喜好输入一个网站名称，物理路径选择你刚才创建的文件夹。其他的暂时可以默认不变。不过需要注意你的端口可能会冲突，此时可以修改你的端口为8080或其它未被占用的端口。点击确定。你可以参考我的填写内容。
如无意外，你可以看到你的左侧网站界面多了一个你刚才创建的网站。点击它，中间的界面就会变成该网站的管理界面。

测试网站

现在我们可以测试这个网站了，打开一个浏览器，输入地址并在其后添加你刚刚选择的端口号，例如http://localhost:8080，你就可以打开刚才你的index.html网站。实验成功。

IPv4和IPv6比较

Sun, 05 Oct 2025 19:07:56 +0800

IPv4和IPv6比较

前言

IPv4和IPv6是当前互联网协议的两个主要版本，并基于它们的不同特点进行对比。

特点

兼容性

IPv4：IPv4是互联网的基础，已经应用数十年，几乎所有现有网络设备、操作系统、应用程序都完美支持IPv4，兼容性极佳。
IPv6：尽管IPv6是未来趋势，但其普及率仍不及IPv4，部分老旧设备、操作系统或应用程序可能不完全支持IPv6，存在兼容性问题。

此外，兼容性也带来了过度成本问题，包括设备升级改造成本和技术学习成本。

易用性

IPv4：地址采用点分十进制表示，格式简单，便于人类记忆、输入和配置。
IPv6：地址采用冒号分隔的十六进制表示，长度较长且复杂，不便于人类记忆和手动输入。

地址空间

IPv4：采用32位地址，理论地址总数约43亿个，但由于互联网高速发展，这点地址空间根本不够，甚至不足以全世界每人一个IP地址。这是IPv4最大的缺陷。尽管通过NAT技术可以缓解这一问题，但是这本质上破坏了端到端的通信原则，增加了网络复杂性，可能导致连接延迟，并使得网络故障排查和安全溯源更加困难。
IPv6：采用128位地址，理论上地址数量高达2的128次方个，足以满足未来物联网、智能设备等海量终端接入的需求，从根本上解决了地址枯竭问题，且无需NAT转换，保证了互联网端到端通信的特性，简化了网络结构，提高了通信效率和可靠性。

路由效率

IPv4：地址分配不均，导致路由表庞大且难以聚合，路由器查找路由的负担较重，影响数据转发效率。
IPv6：地址层次结构清晰，具有良好的可聚合性，能有效压缩路由表规模，减轻路由器负担，加快路由查找和数据包转发速度。

安全性

IPv4：协议本身设计时未充分考虑安全性，其安全机制（如IPsec）是可选的附加功能，而非强制内置，使得网络更容易受到攻击。
将IPsec（IP安全协议）作为强制性标准集成在协议中，为数据传输提供端到端的加密和认证，大大增强了网络通信的安全性。

自动配置

IPv4：依赖于DHCP服务器，需要单独进行配置DHCP服务器。
IPv6：支持无状态地址自动配置（SLAAC），设备接入网络后可以自动获取IP地址，无需依赖DHCP服务器，简化了网络管理，尤其适合大规模设备部署。

总结

IPv4凭借其成熟和兼容性仍是当前的主流，但其地址枯竭和安全性的根本缺陷使其难以适应未来发展。IPv6则通过巨大的地址空间、内置安全、高效路由和自动配置等优势，成为解决当前互联网瓶颈的必然选择，是未来互联网发展的方向。目前，两者正处于长期共存的过渡阶段，最终IPv6将逐步取代IPv4成为主流。

ARP协议分析

Sat, 27 Sep 2025 15:07:00 +0800

ARP协议分析

ARP协议简介

ARP全称为“Address Resolution Protocol”（地址解析协议）。其功能是将IP地址解析转换为MAC地址。因为IP地址工作在网络层，MAC地址工作在数据链路层，通常IP地址用于局域网之外的数据转发，而MAC地址用于局域网内的数据通信。当一台主机需要向同一局域网内的另一台主机发送数据时，它虽然知道对方的IP地址，但是最终数据需要以帧的形式在物理网络上传输，这个传输过程依赖于MAC地址，故需要一种机制将目标IP地址翻译成的对应的MAC地址。

为什么不能只用MAC或IP

MAC地址工作在数据链路层，IP地址工作在网络层，它们其实负责的是不同板块的功能。MAC地址负责同一局域网内的数据定位，而IP则负责不同局域网之间的数据定位。如果只用MAC地址，因为MAC地址本身没有分层的结构，路由表将会变得极其庞大而难以管理。

而如果只用IP地址，因为IP地址已经包含了过多功能，在对IP数据包进行处理的时候会相对复杂，且路由器本身成本也更高，相比于使用一台路由器来管理，远不如用一台有硬件级MAC转发电路的交换机来得更为高效和划算，而且这也会导致路由器的角色混乱和性能下降。

ARP工作流程

ARP的工作流程简单讲就是先广播询问，后单播应答。

假设两台设备在同一局域网内，A设备知道B设备的IP地址，但不知道它的MAC地址，此时就可以启动ARP协议：

检查缓存表：主机A先检查自己的ARP缓存表（该缓存表可以避免重复广播），查看是否已有主机B的MAC地址。如果存在，则直接使用该地址构造数据帧。如果不存在，则进入ARP请求过程。
广播ARP请求：主机A在局域网内广播一个ARP请求报文，该报文包含主机A的IP和MAC，以及主机B的IP，而该报文的目标MAC地址设置为FF:FF:FF:FF:FF:FF用于广播，本地广播域内所有设备将会接收到这个请求。
单播ARP响应：只有主机B接收到广播并通过IP地址确定了该广播询问的是自己的MAC地址后，向主机A发送一个单播的ARP应答报文，里面包含了自己的MAC地址。
更新ARP缓存：主机B在接收到ARP请求后，就将主机A的MAC地址存入自己的ARP缓存。主机A在接受到主机B的应答报文后，也将主机B的MAC地址存入自己的ARP缓存。
正常通信：现在双方都知道了对方的MAC地址，就可以开始正常通信了，而在一段时间内，一因为双方ARP缓存都有对方的MAC地址，也无需要再次广播。

ARP报文格式

ARP时一个独立的三层协议，所以ARP报文在数据链路层不需要经过IP协议的封装，而是直接生成自己的报文。ARP报文可以分为ARP请求报文和ARP应答报文两种，但是它们的格式可以统一为同一种格式：

名称	大小（字节）	功能
硬件类型	2	表示ARP报文可以在哪种网络上传输，值为1时表示以太网地址。
上层协议类型	2	表示硬件地址要映射的协议地址类型，映射IP地址时的值为0x0800。
MAC地址长度	1	标识MAC地址长度，以字节为单位，此处为6。
IP地址长度	1	标识IP得知长度，以字节为单位，此处为4。
操作类型	2	指定本次ARP报文类型。1标识ARP请求报文，2标识ARP应答报文。
源MAC地址	6	发送方的MAC地址。
源IP地址	4	发送方的IP地址。
目的MAC地址	6	接收方的MAC地址。若为请求报文，因为当前不知道该地址，则此时全为0，即`00:00:00:00:00:00`，表示任意地址。
目的IP地址	4	接受方的IP地址。

ARP帧格式

ARP报文并非直接在网络层发送和使用的，还需要向下传输到数据链路层，此时需要再次封装。以以太网为例，ARP报文传输到以太网数据链路层后会形成ARP帧，ARP帧是在ARP报文前面添加了一个以太网帧头，以太网帧头如下表所示：

名称	大小（字节）	功能
目标MAC地址	6	接收方的MAC地址。若为请求报文，则为广播帧，设置为广播地址`FF:FF:FF:FF:FF:FF`。
源MAC地址	6	发送方的MAC地址。
帧类型	2	表示帧封装的上层协议，ARP帧封装的ARP报文，所以此处填ARP的协议号0x0806。