Wireshark实验(计算机网络)

  • Post author:
  • Post category:其他




(一)数据链路层



实作一 熟悉 Ethernet 帧结构

使用 Wireshark 任意进行抓包,熟悉 Ethernet 帧的结构,如:目的 MAC、源 MAC、类型、字段等。

发出帧的目的 MAC 地址:

Destination


返回帧的源 MAC 地址:

Source


类型:Type

在这里插入图片描述


问题



Wireshark 展现给我们的帧中没有校验字段,请了解一下原因。


答:因为WireShark把尾部的四个字节的校验字段给过滤了。



实作二 了解子网内/外通信时的 MAC 地址

1、ping 你旁边的计算机(同一子网),同时用 Wireshark 抓这些包(可使用 icmp 关键字进行过滤以利于分析),记录一下发出帧的目的 MAC 地址以及返回帧的源 MAC 地址是多少?这个 MAC 地址是谁的?

在这里插入图片描述

在这里插入图片描述

发出帧的目的 MAC 地址:34:24:3e:10:c6:17

返回帧的源 MAC 地址:38:68:93:c8:c0:ad

发出帧的目的 MAC 地址是ping的主机的。

在这里插入图片描述

2、 ping qige.io (或者本子网外的主机都可以),同时用 Wireshark 抓这些包(可 icmp 过滤),记录一下发出帧的目的 MAC 地址以及返回帧的源 MAC 地址是多少?这个 MAC 地址是谁的?

在这里插入图片描述

在这里插入图片描述

发出帧的目的 MAC 地址:01:00:5e:7f:ff:fa

返回帧的源 MAC 地址:38:68:93:c8:c0:ad

MAC 地址是本主机所在子网的网关MAC地址。

在这里插入图片描述

3、 ping www.cqjtu.edu.cn (或者本子网外的主机都可以),同时用 Wireshark 抓这些包(可 icmp 过滤),记录一下发出帧的目的 MAC 地址以及返回帧的源 MAC 地址又是多少?这个 MAC 地址又是谁的?

在这里插入图片描述
在这里插入图片描述

发出帧的目的 MAC 地址:34:24:3e:10:c6:17

返回帧的源 MAC 地址:38:68:93:c8:c0:ad

MAC 地址是本主机所在子网的网关MAC地址。
在这里插入图片描述


通过以上的实验发现:

访问本子网的计算机时,目的 MAC 就是该主机的

访问非本子网的计算机时,目的 MAC 是网关的

请问原因是什么?


答:因为访问外网的时候,都是通过 mac 地址送到网关处,然后出了网关再通过 IP 地址进行查找;接收到非子网的计算机返回的数据都是先到网关,网关再根据目的 mac 送到本机。



实作三 掌握 ARP 解析过程

1、为防止干扰,先使用

arp -d *

命令清空 arp 缓存

在这里插入图片描述

2、ping 你旁边的计算机(同一子网),同时用 Wireshark 抓这些包(可 arp 过滤),查看 ARP 请求的格式以及请求的内容,注意观察该请求的目的 MAC 地址是什么。再查看一下该请求的回应,注意观察该回应的源 MAC 和目的 MAC 地址是什么。

回应的是对方的mac物理地址。

在这里插入图片描述

在这里插入图片描述

3、再次使用

arp -d *

命令清空 arp 缓存

4、然后 ping qige.io (或者本子网外的主机都可以),同

时用 Wireshark 抓这些包(可 arp 过滤)。查看这次 ARP 请求的是什么,注意观察该请求是谁在回应。

回应的是子网的mac地址。

在这里插入图片描述

在这里插入图片描述


问题



通过以上的实验会发现,

ARP 请求都是使用广播方式发送的

如果访问的是本子网的 IP,那么 ARP 解析将直接得到该 IP 对应的 MAC;如果访问的非本子网的 IP, 那么 ARP 解析将得到网关的 MAC。

请问为什么?


答:因为访问本子网IP会通过ARP解析出IP的MAC地址;如果访问的是非本子网的IP时APR 只能解析得到网关的MAC地址,再由网关将数据给发送出去。



(二)网络层



实作一 熟悉 IP 包结构

使用 Wireshark 任意进行抓包(可用 ip 过滤),熟悉 IP 包的结构,如:版本、头部长度、总长度、TTL、协议类型等字段。

在这里插入图片描述

版本

在这里插入图片描述

头部长度

在这里插入图片描述

总长度

在这里插入图片描述

TTL

在这里插入图片描述

协议类型

在这里插入图片描述


问题



为提高效率,我们应该让 IP 的头部尽可能的精简。但在如此珍贵的 IP 头部你会发现既有头部长度字段,也有总长度字段。请问为什么?


答:因为头部长度是来表明该包头部的长度,可以使得接收端计算出报头在何处结束及从何处开始读数据。总长度是为了接收方的网络层了解到传输的数据包含哪些,如果没有该部分,当数据链路层在传输时,对数据进行了填充,对应的网络层不会把填充的部分给去掉。



实作二 IP 包的分段与重组

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

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

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

可以看出长度为2000字节的IP包被分成了长度为548字节的IP包,通过分段号来作为分段的标志。


问题

分段与重组是一个耗费资源的操作,特别是当分段由传送路径上的节点即路由器来完成的时候,所以 IPv6 已经不允许分段了。那么 IPv6 中,如果路由器遇到了一个大数据包该怎么办?


答:路由器会直接丢弃该数据包同时向发送端发回一个”分组太大”的ICMP报文,之后发送端就会使用较小的IP数据包重发。



实作三 考察TTL事件

在 IP 包头中有一个 TTL 字段用来限定该包可以在 Internet上传输多少跳(hops),一般该值设置为 64、128等。

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

请使用

tracert www.baidu.com

命令进行追踪,此时使用 Wireshark 抓包(用 icmp 过滤),分析每个发送包的 TTL 是如何进行改变的,从而理解路由追踪原理。

在这里插入图片描述

在这里插入图片描述

在抓包过程中,可以观察到ttl是在逐渐增加的。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述


问题

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


答:至少经过了50跳



传输层



实作一 熟悉 TCP 和 UDP 段结构

用 Wireshark 任意抓包(可用 tcp 过滤),熟悉 TCP 段的结构,如:源端口、目的端口、序列号、确认号、各种标志位等字段。

在这里插入图片描述

源端口

在这里插入图片描述

目的端口

在这里插入图片描述

序列号

在这里插入图片描述

确认号

在这里插入图片描述

标志位

在这里插入图片描述

用 Wireshark 任意抓包(可用 udp 过滤),熟悉 UDP 段的结构,如:源端口、目的端口、长度等。

在这里插入图片描述

源端口

在这里插入图片描述

目的端口

在这里插入图片描述

长度

在这里插入图片描述


问题

由上大家可以看到 UDP 的头部比 TCP 简单得多,但两者都有源和目的端口号。请问源和目的端口号用来干什么?


答:源端口来表示发送终端的某个应用程序,目的端口来表示接收终端的某个应用程序。端口号就是来标识终端的应用程序,从而实现应用程序之间的通信。



实作二 分析 TCP 建立和释放连接

打开浏览器访问 qige.io 网站,用 Wireshark 抓包(可用 tcp 过滤后再使用加上 Follow TCP Stream),不要立即停止 Wireshark 捕获,待页面显示完毕后再多等一段时间使得能够捕获释放连接的包。

请在你捕获的包中找到三次握手建立连接的包,并说明为何它们是用于建立连接的,有什么特征。

SYN 同步序列号,用来发起一个TCP连接。

1、注意到”第一次握手”客户端发送的TCP报文中以[SYN]作为标志位,并且客户端序号Seq=0;

2、接下来”第二次握手”服务器返回的TCP报文中以[SYN,ACK]作为标志位;并且服务器端序号Seq=0;确认号Ack=1(“第一次握手”中客户端序号Seq的值+1);

3、最后”第三次握手”客户端再向服务器端发送的TCP报文中以[ACK]作为标志位;其中客户端序号Seq=1(“第二次握手”中服务器端确认号Ack的值);确认号Ack=1(“第二次握手”中服务器端序号Seq的值+1)。

这就完成了”三次握手”的过程

在这里插入图片描述

请在你捕获的包中找到四次挥手释放连接的包,并说明为何它们是用于释放连接的,有什么特征。

TCP断开连接是通过发送FIN报文,来告诉对方数据已经发送完毕,可以释放连接了。

1、”第一次挥手”客户端发送的FIN请求释放连接报文以[FIN,ACK]作为标志位,其中报文序号Seq=601;确认号Ack=137;

2、”第二次挥手”服务器端继续返回的FIN同意释放连接报文以[FIN,ACK]作为标志位;其中报文序号Seq=137;确认号Ack=602;

3、”第三次挥手”客户端发出的ACK确认接收报文以[ACK]作为标志位;其中报文序号Seq=602;确认号Ack=138;

后一次“挥手”传输报文中的序号Seq值等于前一次”握手”传输报文中的确认号Ack值;

后一次“挥手”传输报文中的确认号Ack值等于前一次”握手”传输报文中的序号Seq值;

在这里插入图片描述


问题一

去掉 Follow TCP Stream,即不跟踪一个 TCP 流,你可能会看到访问 qige.io 时我们建立的连接有多个。请思考为什么会有多个连接?作用是什么?


答:因为它们之间的连接是属于短连接,一旦数据发送完成后,就会断开连接。虽然,断开连接,但是页面还是存在,由于页面已经被缓存下来。一旦需要重新进行发送数据,就要再次进行连接。

建立多个连接主要是浏览器为了优化打开网页的速度,会同时打开多个端口去访问同一个网页,打开多个端口同时接收数据,接收到的数据进行整合,以便于浏览网页的快速化。


问题二



我们上面提到了释放连接需要四次挥手,有时你可能会抓到只有三次挥手。原因是什么?


答:客户端向服务端发送断开连接的请求为第一次挥手,服务端向客户端回复同意断开为第二次,然后服务端向客户端发送断开的请求为第三次挥手,客户端向服务端回复同意断开连接为第四次挥手。但是如果对方也没有数据发给本端,那么对方也会发送FIN给本端,使得二三次挥手合并为一次。



应用层

应用层的协议非常的多,在此只对 DNS 和 HTTP 进行相关的分析。



实作一 了解 DNS 解析

先使用

ipconfig /flushdns

命令清除缓存,再使用

nslookup qige.io

命令进行解析,同时用 Wireshark 任意抓包(可用

dns

过滤)。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

你应该可以看到当前计算机使用 UDP,向默认的 DNS 服务器的 53 号端口发出了查询请求,而 DNS 服务器的 53 号端口返回了结果。

可了解一下 DNS 查询和应答的相关字段的含义。

DNS查询和应答报文的格式如下:

在这里插入图片描述

16位标识字段用于标记一对DNS查询和应答,以此区分一个DNS应答是哪个DNS查询的回应

16位标志字段用于协商具体的通信方式和反馈通信状态。DNS报文头部的16位标志字段的细节如图

在这里插入图片描述

  1. QR:查询/应答标志。0表示这是一个查询报文,1表示这是一个应答报文

  2. opcode,定义查询和应答的类型。0表示标准查询,1表示反向查询(由IP地址获得主机域名),2表示请求服务器状态

  3. AA,授权应答标志,仅由应答报文使用。1表示域名服务器是授权服务器

  4. TC,截断标志,仅当DNS报文使用UDP服务时使用。因为UDP数据报有长度限制,所以过长的DNS报文将被截断。1表示DNS报文超过512字节,并被截断

  5. RD,递归查询标志。1表示执行递归查询,即如果目标DNS服务器无法解析某个主机名,则它将向其他DNS服务器继续查询,如此递归,直到获得结果并把该结果返回给客户端。0表示执行迭代查询,即如果目标DNS服务器无法解析某个主机名,则它将自己知道的其他DNS服务器的IP地址返回给客户端,以供客户端参考

  6. RA,允许递归标志。仅由应答报文使用,1表示DNS服务器支持递归查询

  7. zero,这3位未用,必须设置为0

  8. rcode,4位返回码,表示应答的状态。常用值有0(无错误)和3(域名不存在)

接下来的4个字段则分别指出DNS报文的最后4个字段的资源记录数目。对查询报文而言,它一般包含1个查询问题,而应答资源记录数,授权资源记录数和额外资源记录数则为0.应答报文的应答资源记录数则至少为1,而授权资源记录数和额外资源记录数可为0或非0

查询问题的格式:

在这里插入图片描述

如图所示,查询名以一定的格式封装了要查询的主机域名。16位查询类型表示如何执行查询操作,常见的类型有如下几种:

  1. 类型A,值是1,表示获取目标主机的IP地址。
  2. 类型CNAME,值是5,表示获得目标主机的别名。
  3. 类型PTR,值是12,表示反向查询。

应答字段,授权字段和额外信息字段都使用资源记录(Resource Record,RR)格式。

资源记录格式:

在这里插入图片描述

  1. 32位域名是该记录中与资源对应的名字,其格式和查询问题中的查询名字段相同。16位类型和16位类字段的含义也与DNS查询问题的对应字段相同。
  2. 32位生存时间表示该查询记录结果可被本地客户端程序缓存多长时间,单位是秒
  3. 16位资源数据长度字段和资源数据字段的内容取决于类型字段。对类型A而言。资源数据是32位的IPv4地址,而资源数据长度则为4(以字节为单位)

    参考地址:

    https://blog.csdn.net/qq_41091373/article/details/90384705



    问题

    你可能会发现对同一个站点,我们发出的 DNS 解析请求不止一个,思考一下是什么原因?


    答:原因是一台服务器下会有多个域名,发送DNS解析请求时不是固定在一台服务器上的,会选择距离自己最近的服务器为自己服务。



实作二 了解 HTTP 的请求和应答

  1. 打开浏览器访问 qige.io 网站,用 Wireshark 抓包(可用http 过滤再加上 Follow TCP Stream),不要立即停止 Wireshark 捕获,待页面显示完毕后再多等一段时间以将释放连接的包捕获。

    在这里插入图片描述

  2. 请在你捕获的包中找到 HTTP 请求包,查看请求使用的什么命令,如:GET, POST。并仔细了解请求的头部有哪些字段及其意义。
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    Accept:告诉WEB服务器自己接受什么介质类型

    Host:客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号

  3. 请在你捕获的包中找到 HTTP 应答包,查看应答的代码是什么,如:200, 304, 404等。并仔细了解应答的头部有哪些字段及其意义。

    在这里插入图片描述

    Expires:告诉浏览器把回送的资源缓存多长时间,-1或0则是不缓存。

    Last-Modified:文档的最后改动时间。

    Content- Type:表示后面的文档属于什么MIME类型。

    Content-Length:表示内容长度。

    200:交易成功;

    304:客户端已经执行了GET,但文件未变化;

    404:没有发现文件、查询或URl;


问题


刷新一次 qige.io 网站的页面同时进行抓包,你会发现不少的 304 代码的应答,这是所请求的对象没有更改的意思,让浏览器使用本地缓存的内容即可。那么服务器为什么会回答 304 应答而不是常见的 200 应答?


因为第一次访问时成功收到响应,就会返回200,浏览器这时会下载资源文件,记录response header和返回返回时间。浏览器第二次发送请求的时候,告诉浏览器我上次请求的资源现在还在自己的缓存中,如果你那边这个资源还没有修改,就可以不用传送应答体。服务器根据浏览器传来的时间发现和当前请求资源的修改时间一致,就应答304,表示不传应答体了,从缓存里取,不一致返回200。



版权声明:本文为weixin_59049031原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。