Wireshark实验分析各种协议

前言:

看完了计网的五层结构,就实际操作一下来捉下不同层下的协议包来康康。加深一下印象=。=

实验准备

Wireshark软件
随意获取一个网站的ip地址,用于过滤
在这里插入图片描述

TCP三次握手

TCP三次握手用于建立TCP连接。
在这里插入图片描述
三次握手的连接:
在这里插入图片描述
第一次握手:
客户端主动打开,发送连接请求报文段(SYN报文),SYN标识位置为1,Sequence Number会被设置为一个随机值,然后客户端进入SYN_SEND状态同步已发送状态
在这里插入图片描述
第二次握手:
服务器收到SYN报文段进行确认,将SYN标识位置为1,ACK置为1,Sequence Number置为y,这里是Acknowledgment Number置为x+1,然后服务器进入SYN_RECV状态,并且为这个状态被称为半连接状态,会在第三次握手之前为该TCP连接分配TCP缓存和变量,并将该TCP连接放入半连接队列。此处服务器容易收到SYN攻击。
在这里插入图片描述
第三次握手:
客户端再进行一次确认,将ACK置为1,Sequence Number置为x+1,Acknowledgment Number置为y+1,最后客户端与服务器都进入ESTABLISHED状态,已建立连接状态,第三次连接可以在报文段负载中携带数据了。
在这里插入图片描述

常见问题:

ack与ACK的区别:

ack代表着期待发送的下一个包的序号 ,ACK代表的是TCP标识位中的ACK标识为1,表示这是一个确认报文。

第二次握手中服务器容易收到什么攻击?

服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握手时分配的,所以服务器容易受到SYN洪泛攻击,SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server则回复确认包,并等待Client确认,由于源地址不存在,因此Server需要不断重发第二次握手报文直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃

为什么需要第三次握手?

归根到底就是要让客户端和服务端都清楚双方的初始序号,TCP 需要 seq 序列号来做可靠重传或接收,因此需要三次握手来约定确定。第二次握手让客户端清楚服务端以获取自身序号,第三次握手让服务端知道客户端以获取自身序号。

TCP四次握手

tcp四次握手主要是用来关闭TCP连接的
在这里插入图片描述
四次连接
这种是服务器主动提出断开连接。试了蛮多次都是服务器先主动断开连接的,也没差啦,不过就是跟书上描述的客户端先提出的断开连接调转了而已,过程差不多。
在这里插入图片描述

书上的过程:

第一次握手:
客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状
态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
第二次握手:

  • 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间,关闭等待状态。

  • 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。

第三次握手:
服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。

第四次握手:

  • 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
  • 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

常见问题:

为什么连接的时候是三次握手,关闭的时候却是四次握手?

答:关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭TCP连接,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送,多出了这一步。故需要四步握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

DNS连接

dns连接主要分为两次:
在这里插入图片描述
dns查询报文:
通过udp报文携带dns报文,可以看出是根据把域名携带到dnf服务器中
在这里插入图片描述
dns响应报文:dns服务器返回域名对应的ip地址
在这里插入图片描述

DHCP协议

由于是笔记本=。=,这里就断开了wifi然后走到二楼连新的wifi。这时笔记本就会启动DHCP协议来获取ip地址
在这里插入图片描述
Discover:
u此时广播DHCP发现报文,通过发送udp分组,使用广播地址255.255.255.255 源地址0.0.0.0,等待DHCP服务器的响应
在这里插入图片描述
offer:某个DHCP分配好ip地址,并返回DHCP提供报文(携带这ip地址、网络掩码、ip地址租用期)。此时仍然通过广播的形式返回。因为此时主机还不知道自身的ip地址
在这里插入图片描述

request:从多个DHCP服务器中选择一个并且向选择的DHCP服务器返回一个响应报文,此时仍然是广播,未收到DHCP的ack报文还不能使用所分配的地址
在这里插入图片描述
ACK:服务器用DHCP ACK报文对DHCP请求报文就行响应。
在这里插入图片描述
至此主机可以使用所分配的地址。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章