用Wireshark了解计算机网络的数据链路层、网络层、传输层以及应用层

准备

了解 Wireshark 的基本使用：

1.选择对哪块网卡进行数据包捕获
2.开始/停止捕获
3.了解 Wireshark 主要窗口区域
4.设置数据包的过滤
5.跟踪数据流
参考

1. 官方文档
2. Wireshark抓包新手使用教程.

数据链路层

一、熟悉 Ethernet 帧结构
使用 Wireshark 任意进行抓包，熟悉 Ethernet 帧的结构，如：目的 MAC、源 MAC、类型、字段等。
步骤：
1、打开Wireshark，勾选WLAN网卡，点击Start，启动抓包。
2、wireshark启动后，wireshark处于抓包状态中。
3、执行需要抓包的操作，如在cmd窗口下执行ping www.baidu.com。

4、操作完成后相关数据包就抓取到了。为避免其他无用的数据包影响分析，可以通过在过滤栏设置过滤条件进行数据包列表过滤，获取结果如下。说明：ip.addr == 14.215.177.39 and icmp 表示只显示ICPM协议且源主机IP或者目的主机IP为14.215.177.39的数据包

5、观察数据详细区中的Ethernet II一栏，了解数据链路层中帧的结构

分析：
Destination一行为目的mac地址，为00:74:9c:9f:40:13；Source一行为源mac地址，为d4:6d:6d:2d:65:22；
Type一行为类型，为0x0800，为IPv4类型，但缺少FCS校验字段。

问题
你会发现 Wireshark 展现给我们的帧中没有校验字段，请了解一下原因。
分析：这是因为有时校验和会由网卡计算，这时wireshark抓到的本机发送的数据包的校验和都是错误的，所以默认关闭了WireShark自己的校验。

二、了解子网内/外通信时的 MAC 地址
步骤：
1.在命令提示符中输入ipconfig -all

2.由图可知，本机的mac地址为d4:6d:6d:2d:65:22，ip地址为192.168.43.89。子网另一主机的mac地址为40-9f-38-aa-f5-df，ip地址为192.168.43.32。
3.Ping 192.168.43.32

4.用 Wireshark 抓取ip地址为192.168.43.32的包，记录发出帧的目的 MAC 地址以及返回帧的源MAC地址
5.Ping qige.io

6.用 Wireshark 抓取ip地址为104.18.40.82的包，记录发出帧的目的 MAC 地址以及返回帧的源MAC地址。
7.ping www.baidu.com

8.用 Wireshark 抓取ip地址为183.232.231.174的包，记录发出帧的目的 MAC 地址以及返回帧的源MAC地址。
分析：
1、访问本子网的计算机，目的mac为40-9f-38-aa-f5-df（为另一主机地址）

2、访问非本子网的计算机，目的mac为90:ad:f7:83:87:04（为网关地址）

通过以上的实验，你会发现：
访问本子网的计算机时，目的 MAC 就是该主机的
访问非本子网的计算机时，目的 MAC 是网关的
请问原因是什么？
分析：访问本子网的计算机时，目的 MAC 就是该主机的，访问非本子网的计算机时，目的 MAC 是网关的。这是因为本机接收到的本子网以外的信息必定经由网关发送给我，同理本机发送到本子往外信息的下个地址必定是网关的mac地址。而本子网内的可以直接到达。

三、掌握 ARP 解析过程
步骤：
1、先使用 arp -d * 命令清空 arp 缓存。
2、ping 旁边的计算机（同一子网）（192.168.43.32），用 Wireshark 抓这些包。
3、Ping qige.io ,用 Wireshark 抓这些包。
访问同一子网主机：

访问非同子网主机：

✎ 问题
通过以上的实验，你应该会发现，
ARP 请求都是使用广播方式发送的
如果访问的是本子网的 IP，那么 ARP 解析将直接得到该 IP 对应的 MAC；如果访问的非本子网的 IP， 那么 ARP 解析将得到网关的 MAC。
请问为什么？
分析：ARP 请求都是使用广播方式发送的 如果访问的是本子网的 IP，那么 ARP 解析将直接得到该 IP 对应的 MAC；如果访问的非本子网的IP， 那么 ARP 解析将得到网关的 MAC。这是因为ARP代理，访问非子网IP时是通过路由器访问的，路由器再把发出去，目标IP收到请求后，再通过路由器端口IP返回去，那么ARP解析将会得到网关的MAC。

网络层

一、熟悉 IP 包结构
使用 Wireshark 任意进行抓包（可用 ip 过滤），熟悉 IP 包的结构，如：版本、头部长度、总长度、TTL、协议类型等字段。
步骤：
1、打开命令提示符，ping www.baidu.com。
2、打开wireshark抓取ip地址为183.232.231.172的包，记录IP 包的结构，如：版本、头部长度、总长度、TTL、协议类型等字段。

其中IP包的具体数据为：

Version为版本号，为4；
Header Length 为报头长度，为20bytes；
Differentiated Services Field为服务类型；
Total Length为总长度，为60字节
Identification为标识；
Flags为标识字段；
Fragment offset为分片偏移；
Time to live（ttl）为生存时间，为64，即最多转发64个路由器；
Protocol为协议，为ICMP；
Header checksum status为头部校验和；
Source为源地址，即本机地址192.168.43.89；
Destination为目的地址，为183.232.231.172

问题
为提高效率，我们应该让 IP 的头部尽可能的精简。但在如此珍贵的 IP 头部你会发现既有头部长度字段，也有总长度字段。请问为什么？
分析：便于传输时的识别IP总长度，节省时间，当长度超过1500B时就会被返回链路层进行分段。

二、IP 包的分段与重组
根据规定，一个 IP 包最大可以有 64K 字节。但由于 Ethernet 帧的限制，当 IP 包的数据超过 1500 字节时就会被发送方的数据链路层分段，然后在接收方的网络层重组。

缺省的，ping 命令只会向对方发送 32 个字节的数据。我们可以使用 ping 202.202.240.16 -l 2000 命令指定要发送的数据长度。此时使用 Wireshark 抓包（用 ip.addr == 202.202.240.16 进行过滤），了解 IP 包如何进行分段，如：分段标志、偏移量以及每个包的大小等
步骤：
1、ping 202.202.240.16 -l 2000
2、抓202.202.240.16的包

由图可知：2000字节被分为了两个包进行发送，IP包1的总长度为1500，IP包2的总长度为548。
根据抓包结果可知，2000字节的包被分为了两个IP包进行发送，且以第1480字节作为分隔的结点，第二个包的分片偏移的值为1480，意思就是长分组在进行分片之后，分片偏移即该分包相对整个包的起点。

问题： 分段与重组是一个耗费资源的操作，特别是当分段由传送路径上的节点即路由器来完成的时候，所以 IPv6 已经不允许分段了。那么 IPv6 中，如果路由器遇到了一个大数据包该怎么办？
分析：
直接丢弃再通知发送端进行重传。
由于在 IPv6中分段只能在源与目的地上执行，不能在路由器上进行。因此当数据包过大时，路由器就会直接丢弃该数据包包，并向发送端发回一个"分组太大"的ICMP差错报文，之后发送端就会使用较小长度的IP数据报重发数据。

三、考察 TTL 事件
在 IP 包头中有一个 TTL 字段用来限定该包可以在 Internet上传输多少跳（hops），一般该值设置为 64、128等。

在验证性实验部分我们使用了 tracert 命令进行路由追踪。其原理是主动设置 IP 包的 TTL 值，从 1 开始逐渐增加，直至到达最终目的主机。

请使用 tracert www.baidu.com 命令进行追踪，此时使用 Wireshark 抓包（用 icmp 过滤），分析每个发送包的 TTL 是如何进行改变的，从而理解路由追踪原理。
步骤：
1、tracert www.baidu.com命令进行追踪。

2、使用ws抓包，抓取ip地址为183.232.231.174的包。
实验结果：分别抓取第6跳和第7跳的包。


由图可知，TTL字段指定IP包被路由器丢弃之前允许通过的最大网段数量，Tracert 先发送 TTL 为 1 的回应数据包，并随后的每次发送过程将 TTL 递增 1，直到目标响应或 TTL 达到最大值，从而确定路由。

问题：在 IPv4 中，TTL 虽然定义为生命期即 Time To Live，但现实中我们都以跳数/节点数进行设置。如果你收到一个包，其 TTL 的值为 50，推断这个包从源点到你之间有多少跳？
分析：
至少有50跳。

传输层

一、熟悉 TCP 和 UDP 段结构
用 Wireshark 任意抓包（可用 tcp 过滤），熟悉 TCP 段的结构，如：源端口、目的端口、序列号、确认号、各种标志位等字段。
用 Wireshark 任意抓包（可用 udp 过滤），熟悉 UDP 段的结构，如：源端口、目的端口、长度等。
步骤：
1、ping www.baidu.com
2、使用ws抓包，过滤为 tcp
3、使用ws抓包，过滤为 udp
结果：
1、过滤为tcp

由抓包图可得：Source Port为源端口号，为13917,
Destination Port为目的端口号，为80，
Sequence number为序号，为618，
Acknowledgment number为确认号，为590401，
Header Length为报头长度，为20字节，
ACK为标识位，Window size value为窗口大小，checksum status为校验和。
2、过滤为udp

由抓包图可得：Source Port为源端口号，为8000,
Destination Port为目的端口号，为4013，
Length为UDP长度，为95，
Checksum为UDP校验和

问题：
由上大家可以看到 UDP 的头部比 TCP 简单得多，但两者都有源和目的端口号。请问源和目的端口号用来干什么？
分析：
源端口就是指本地端口，目的端口就是远程端口。源端口就是本机程序用来发送数据的端口，目的端口就是对方主机用哪个端口接收。

二、分析TCP建立和释放连接
打开浏览器访问 qige.io 网站，用 Wireshark 抓包（可用 tcp 过滤后再使用加上 Follow TCP Stream），不要立即停止 Wireshark 捕获，待页面显示完毕后再多等一段时间使得能够捕获释放连接的包。
请在你捕获的包中找到三次握手建立连接的包，并说明为何它们是用于建立连接的，有什么特征。
请在你捕获的包中找到四次挥手释放连接的包，并说明为何它们是用于释放连接的，有什么特征。
步骤：
1、打开浏览器访问 qige.io 网站，用 Wireshark 抓包。
2、寻找三次握手的tcp包四次挥手的tcp包
结果：
1、三次握手

第一次握手：
第二次握手：

第三次握手：

由结果可得，第一次握手时，客户端发送tcp头部SYN标志位为1，客户端序号为0，第二次握手时，服务器返回SYN标志位为1，确认号ACK为1，为客户端序号加1，并且服务器序号为0，第三次握手时，客户端发送确认号ACK为1。
2、四次挥手

第一次挥手

第二次挥手

第三次挥手

第四次挥手

第一次挥手服务器端发送FIN=1，且报文序号Seq=623，确认号ACK=3319；
第二、三次挥手客户端发送ACK=1，FIN=1且报文序号Seq=3319，确认号ACK=624；
第四次挥手服务器端发送ACK=1，且报文序号Seq=624，确认号ACK=3320；
由此可见，后一次“挥手”传输报文中的序号Seq值等于前一次"握手"传输报文中的确认号Ack值；后一次“挥手”传输报文中的确认号Ack值等于前一次"握手"传输报文中的序号Seq值。

问题：
我们上面提到了释放连接需要四次挥手，有时你可能会抓到只有三次挥手。原因是什么？
分析：因为第二次握手和第三次挥手合并了，FIN报文用在本端没有数据发送给对方时，关闭从本端到对端的连接。但是并不影响从对方到本端的连接，也就是说本端仍然可以接收对方的数据。即发送通道关闭，接收通道正常。如果对方收到本端FIN报文时，对方的接收通道就会关闭。此时，如果对方也没有数据发给本端，那么对方也会发送FIN给本端，用于关闭从对方到本端的连接，这时候就可能出现ACK和FIN合在一起的情况。当然，如果对方仍然有数据发送，那么就等数据发完，再发FIN来关闭连接，这时候就是四次挥手了。

应用层

一、了解 DNS 解析
步骤：
1、先使用 ipconfig /flushdns 命令清除缓存，再使用 nslookup qige.io 命令进行解析，同时用 Wireshark 任意抓包。
2、当前计算机使用 UDP，向默认的 DNS 服务器的 53 号端口发出了查询请求，而 DNS 服务器的 53 号端口返回了结果。
结果：


网络客户端程序都使用DNS协议来向DNS服务器查询目标主机的IP地址。由结果可分析得，对于百度域名的应答，IP地址为183.232.231.172。

问题：
你可能会发现对同一个站点，我们发出的 DNS 解析请求不止一个，思考一下是什么原因？
分析：将负载均衡的工作交给DNS，省去了网站管理维护负载均衡服务器的麻烦。对于部署在服务器上的应用来说不需要进行任何的代码修改即可实现不同机器上的应用访问。

二、了解HTTP的请求和应答
步骤：
1、打开浏览器访问 qige.io 网站，用 Wireshark 抓包。
2、在捕获的包中找到 HTTP 请求包和HTTP应答包。

结果：
请求包：

其头部中，最重要为请求行，包括使用方法、URI以及使用的版本号。
应答包：

应答包头部中，最重要的为响应行，包括版本号、应答号、以及响应消息，由抓包可知，使用版本号为1.1，应答号为200，表示成功请求，响应消息为OK。