网络协议 on 云雾海的博客

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地址实现抓包。

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。