ProtocolDataUnit初探-计算机网络实验教程-实验二

ProtocolDataUnit初探-计算机网络实验教程-实验二

ComputerScience GuoYiXuan 2021/12/26


计算机网络学习笔记系列
计算机网络实验教程-实验一:计算机网络概念初探.
计算机网络实验教程-实验二:ProtocolDataUnit初探.
计算机网络实验教程-实验三:CiscoPacketTracer初探.



写在前面

接上篇博客,在本篇博客中,我们将采用Wireshark来对ProtocolDataUnit进行探究,说实话,上一篇写完还是一头雾水,还是很难把计算机网络这几层结构的联系想明白,那么,我们不妨从它们各层的代表协议入手,对它们的在实际中的最小单元进行剖析,以更好了解它。
还有,觉得文章写的不错的话,可以给我一个小小的赞!也可以在评论区给给予我指点!你小小的动作将会成为我程序员路上极大的鼓励!!


0.准备阶段

新建一个捕获过滤器
用来捕获百度相关的包

在这里插入图片描述

新建两个显示过滤器
用来捕获百度相关的ICMP包
用来捕获虚拟机相关的ICMP包

在这里插入图片描述

在这里插入图片描述

接上一篇博客,我发现如果去ping自己的虚拟机,会采用虚拟网卡192.168.226.1去给虚拟机ip 192.168.226.129 发送ICMP。


1.数据链路层

1.1 Ethernet帧结构

ping www.baidu.com 得到的以太网帧

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

问题:我们发现在Wireshark展现给我们的帧中没有校验字段是为什么呢?
参考wiki.wireshark.org上的以太网Wiki得到答案:在大多数硬件/平台上,以太网校验和在传递给Wireshark之​​前由NIC处理。由于NIC是在硬件中完成的,因此没有办法(或实际上没有任何理由)将其传递到更高的层,除非您已对硬件/驱动程序进行了编码以使其具有这种行为。

NIC(Network Interface controller)
也就是网卡

1.2 子网内/外通信时的MAC地址

在这里插入图片描述

ping我的虚拟机

在这里插入图片描述

结合上一篇博客的图来看
源MAC是我主机的一个虚拟MAC,目的mac是虚拟机的虚拟MAC

在这里插入图片描述

虚拟机ping qige.io

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

本机ping qige.io

在这里插入图片描述

显然,我使用虚拟机也好,主机也罢,目的MAC地址是不一样的,ping同一个网站为什么目的MAC不一样呢?再仔细观察发现,在使用主机时,目的和源MAC都是zte开头,我使用的是中兴的网卡,而在使用虚拟机时,目的和源MAC都是VMware开头,也就是说,它们并没有直接发往目的MAC而是经过了中间步骤,这个MAC应该就是网关的MAC

2021/12/27 补充

做这个真的不容易啊,终于找到一个愿意陪我做实验的人了(要是有女朋友就好了qwq)

两台机器连接同一个手机热点,一台机器ping另一台机器
在这里插入图片描述

可以得到结论:
1.访问内网时目的MAC就是对方的MAC,如本机ping虚拟机,同一热点下的互相ping
2.访问外网的目的MAC就是对方的MAC

1.3 ARP解析过程

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

可以看到,192.168.0.178也就是本机要找192.168.0.1也就是网关,被我们上图见到的zte_00:00:00回应了,也就是说凡是出子网的,都必须经过网关即被ARP解析到网关的MAC,而在子网内,便直接解析目的IP的MAC。


2.网络层

2.1 IP包结构

在这里插入图片描述

关于为什么要有IP头部长度又要有总长度的解释:可以这样想,头部长度决定了从那里开始读数据,而总长度决定了读到哪里结束,况且IP包的数据部分的长度是可变的,这样做不仅高效而且稳定。

2.2 IP包的分段和重组

ping qige.io -l 2000

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

可以看到,分段标志 0x20 More fragments,偏移量为0,每个包都是1500(允许的最大长度)

IPv6不允许分段和重组,分段和重组太消耗资源了,那么,在IPv6中,路由器遇到了一个大的数据包我想应该是交给上一个节点来解决,也就是说应该把数据包扔掉,叫发超大包的一方切好在发过来(分片)

2.3 考察TTC事件

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

在这里插入图片描述

在这里插入图片描述

可以看到目的IP和源IP都是一样的,只是TTC在递增。当路由器接收到ICMP并且TTC减一的时候,就会返回应该ICMP说TTL用完了,这样我们就知道中间的路由器了。

在这里插入图片描述


3.传输层

3.1 TCP和UDP端结构

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

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

多看几个就会发现,TCP段的目的端口都是80端口,序列号都是474,UDP段的目的端口都是53端口

标志字段(较重要的标志位):URG(紧急位)、SYN(同步位)、ACK(确认位)、FIN(结束位)、RST(重置位)

问题来了:UDP的头部比TCP简单的多,而且它们都有源和目的端口号,它们用来干什么?
不难发现,在TCP段中,又窗口尺寸,这就容易想到,窗口是用来接受数据的,那么说明要接收数据呢?应用或者服务等等,那端口号就是为了这个而存在的,也就是实现本机和服务器的双向通信。

3.2 TCP建立和释放连接

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

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

总结:
第一次握手:SYN:1,ACK:0
第二次握手:SYN:1,ACK:1
第三次握手:SYN:0,ACK:1
第四次挥手:释放连接:ACK:1,FIN:1

问题:不跟踪一个TCP流,可能会看到建立的连接有多个,为什么呢?
我认为是因为页面只是初步加载了,还有很多内容需要某些行为来触发,或者说要等待一定时间,而连接会占用资源,所以为了节约资源就只会在需要用到,或者资源需要加载或更新的时候被再次建立。

问题:我们上面提到了释放连接需要四次挥手,有时你可能会抓到只有三次挥手。原因是什么?
将中间的两次合成为一次。例如:客户端向服务端发送断开连接的请求为第一次挥手,服务端向客户端回复同意断开连接为第二次挥手,接着服务端向客户端发送断开连接的请求为第三次挥手,客户端向服务端回复同意断开连接为第四次挥手。三次挥手是将服务器向客户端发送断开连接和回复同意断开连接合成一次挥手,其他两次挥手不变。


4.应用层

4.1 DNS解析

在这里插入图片描述

在这里插入图片描述

16位的标志位
QR:查询/应答标志。0表示这是一个查询报文,1表示这是一个应答报文
opcode,定义查询和应答的类型。0表示标准查询,1表示反向查询(由IP地址获得主机域名),2表示请求服务器状态
AA,授权应答标志,仅由应答报文使用。1表示域名服务器是授权服务器
TC,截断标志,仅当DNS报文使用UDP服务时使用。因为UDP数据报有长度限制,所以过长的DNS报文将被截断。1表示DNS报文超过512字节,并被截断
RD,递归查询标志。1表示执行递归查询,即如果目标DNS服务器无法解析某个主机名,则它将向其他DNS服务器继续查询,如此递归,直到获得结果并把该结果返回给客户端。0表示执行迭代查询,即如果目标DNS服务器无法解析某个主机名,则它将自己知道的其他DNS服务器的IP地址返回给客户端,以供客户端参考
RA,允许递归标志。仅由应答报文使用,1表示DNS服务器支持递归查询
zero,这3位未用,必须设置为0
rcode,4位返回码,表示应答的状态。常用值有0(无错误)和3(域名不存在)
应答字段
域名,类型,生命周期,数据长度,地址

问题:你可能会发现对同一个站点,我们发出的 DNS 解析请求不止一个,思考一下是什么原因?
DNS不止一个的原因可能是DNS解析过程是先从浏览器的DNS缓存中检查是否有这个网址的映射关系,如果有,就返回IP,完成域名解析;如果没有,操作系统会先检查自己本地的hosts文件是否有这个网址的映射关系,如果有,就返回IP,完成域名解析;如果还没有,电脑就要向本地DNS服务器发起请求查询域名;本地DNS服务器拿到请求后,先检查一下自己的缓存中有没有这个地址,有的话直接返回;没有的话本地DNS服务器会从配置文件中读取13个根DNS服务器的地址,然后向其中一台发起请求;直到获得对应的IP为止。

4.2 HTTP的请求和应答

POST

在这里插入图片描述

GET

在这里插入图片描述

请求头详解
Host:客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号
Accept:告诉WEB服务器自己接受什么介质类型
User-Agent的:包含发出请求的用户信息
Connection:表示是否需要持久连接。
Cache-Control:用来指示缓存系统(服务器上的,或者浏览器上的)应该怎样处理缓存
Accept-Encoding:指定浏览器可以支持的web服务器返回内容压缩编码类型。
Content-Type:WEB 服务器告诉浏览器自己响应的对象的类型
Content-Length:WEB 服务器告诉浏览器自己响应的对象的长度

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

如何对应一个请求和一个响应?
我发现响应的ACK就是请求的SequenceNumber。

在这里插入图片描述

还有一个方法

在这里插入图片描述

常见应答的代码
100 :Continue:这个状态码是告诉客户端应该继续发送请求,这个临时响应是用来通知客户端的,部分的请求服务器已经接受,但是客户端应继续发送求请求的剩余部分,如果请求已经完成,就忽略这个响应,而且服务器会在请求完成后向客户发送一个最终的结果
200:OK:这个是最常见的http状态码,表示服务器已经成功接受请求,并将返回客户端所请求的最终结果
202:Accepted:表示服务器已经接受了请求,但是还没有处理,而且这个请求最终会不会处理还不确定
204:No Content:服务器成功处理了请求,但没有返回任何实体内容 ,可能会返回新的头部元信息
301:Moved Permanently:客户端请求的网页已经永久移动到新的位置,当链接发生变化时,返回301代码告诉客户端链接的变化,客户端保存新的链接,并向新的链接发出请求,已返回请求结果
304:Not Modified:未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
404:Not Found:服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面
503:No Content:服务器由于临时的服务器过载或者是维护,无法解决当前的请求

更多内容见https://www.runoob.com/http/http-status-codes.html

在这里插入图片描述

问题:刷新一次 qige.io 网站的页面同时进行抓包,你会发现不少的 304 代码的应答,这是所请求的对象没有更改的意思,让浏览器使用本地缓存的内容即可。那么服务器为什么会回答 304 应答而不是常见的 200 应答?
答案显而易见,网页上很多内容都是很久都不会更改的,就像上篇博客我们在使用Cache访问qige.io和不使用一样,我们的浏览器为我们缓存了很多页面的内容,这些内容在第一次被请求的手应该受到200应答,而在后面发现以及缓存了就会收到304应答了。


写在最后

例如:以上就是今天要讲的内容,本文仅仅简单介绍了pandas的使用,而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。
还有,觉得文章写的不错的话,可以给我一个小小的赞!也可以在评论区给给予我指点!你小小的动作将会成为我程序员路上极大的鼓励!!

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值