转:关于wireshark抓包的那点事儿

转自51CTO博客作者lihongweibj,原文地址:https://blog.51cto.com/lihongweibj/1690518
工作中分析包时看到的一篇文章,转发收藏下,以便下次使用

三次握手

wKioL1XlX13xlyMyAAFscNScy5c669.jpg

172.18.254.177为客户 111.13.2.158为服务端

1、主动打开。发送SYN,协商window size 、TCP MSS seq=0 len=0 MSS=1460 win=65535最大窗口大小

客户端为syn_sent

服务端为syn_recv

2、接收到syn。回复syn ack seq=0 ack=1=0+1 确认自己的最大win=14480 MSS=1460

客户端为established

服务端为syn_recv

3、接到到syn 回复ack seq=1 ack=1=0+1 至此三次握手成功建立。

客户端为established

服务端为established

四次断开

wKioL1XlX2_AUT7YAAGbpSbjH5U362.jpg

1、主动关闭,发送fin。Seq=328

服务端状态为fin_wait1

客户端状态为closed_wait

2、客户端发送确认ack ack=329=328+1

服务端状态为fin_wait2

3、客户端发送fin seq=133

客户端状态为last_ack

服务端状态为time_wait

4、服务端发送ack ack=134=133+1

客户端状态closed

服务端状态closed

数据包ACK=segment len+seq = 下一个要接收的数据包的seq

wKioL1Xo956wfPxEAANr3qx7vFo320.jpg

图1

wKiom1Xo9XqC4Z0tAAKq0Ca2WuM420.jpg

图2

wKioL1Xo956CwfovAALFFcot3aA172.jpg

图3

由图1 数据包情况可以看出 359 seq=1441 segment len=1440 所以下一个回包的ack=1441+1440=2881 从图2中可以确认ack确实为2881.

图2 数据包情况可以看出 360 seq=349 segment len=0 所以下一个回包的ack=349+0=349,从图3可以确认ack确实为349.

图1 359 的ack=349 则图2 350 的seq=349 ack=2881 推断图3 361的seq=2881 .

一条完整会话(session)指的是,相同的传输协议中两个不同IP之间的两个不同端口的互相通信,如果IP或端口变化刚属于不同的会话,其seq和ack也是相互独立的,没有任何关联。

TCP segment of a reassembled PDU (TCP数据包重组的一部分)

wKioL1XlYEHgbu_rAADSnbJx6ak656.jpg

分段的数据包的ACKnum相同,

当请求的数据包大于TCP MSS时会将数据分为多个数据包进行传输。

局域网内的TCP MSS大小为1460=1500-20(IP包头)-20(TCP包头)

wKiom1XoaJyDscodAAUHKhqnRp4820.jpg

server=124.192.132.36 client=192.168.10.111

(378、381、384、387) seq=349不变,ack一直增加。说明client端一直在接收server端的数据,且一直在给client应答。

wKioL1Xo1jHAQbEQAANJp6mqMxc204.jpg

wKiom1Xo1A2CdixvAALdZxxK7Uc402.jpg

wKioL1Xo1jHwTb2AAAKf7LnUZbE552.jpg

server=124.192.132.36 client=192.168.10.111

(376、377、379) ack=349没有变化。seq不断增加,说明server端一直在向client发送数据包,不用给client应答,而是等待client端的应答。

由以上可以看出client不用对server端的每一个包都做一一应答,可以接收几个包后统一做应答。

TCP window update (TCP 窗口更新)

TCP zero window

TCP window full

wKioL1XmvTDh1SqAAAGjrU4JZqc299.jpg

wKioL1XmvOzyjnjcAAaVcyp_la0940.jpg

是TCP通信中的一个状态,它可以发生的原因有很多,但最终归结于发送者传输数据的速度比接收者读取的数据还快,这使得接受端的在缓冲区必须释放一部分空间来装发送过来的数据,然后向发送者发送Windows Update,告诉给发送者应该以多大的速度发送数据,从而使得数据传输与接受恢复正常。

或者一个TCP Window变为0了, 或者接近0了, 这就会警告数据发送方没有更多空间来接受更多数据了.文件传输会停止, 直到收到一个update说buffer已经清空了.

Tcp window full :服务端向客户端发送的一种窗口警告。

Tcp zero window:客户端向服务端发送的一种窗口警告。

Tcp keep-alive: 会话保持,一般由服务端发出。

以下是针对上图的数据包进行分析

客户端:192.168.10.111 服务端:42.250.12.36

131:服务端向客户端发出tcp window full,表示无法再接受新的数据,

132:客户端向服务端发送tcp zero window ,表示没有window可以接收新数据

137:服务端向客户端发送keep-live,保持会话,直至客户端有足够的window可以再次接收数据。

138:客户端再次向服务端发送 tcp zere window ,提示服务端目前没有足够的window可以接收新数据。

139:客户端向服务端发送 tcp window update,表示buffer已经清空。并提示服务端现在已经有足够的window 大小为 17280。

140:由于收到了客户端发送的window buffer已经清空,所以继续发送数据。

TCP DUP ACK (重复的ACK)

wKioL1XlX7LRd2bpAAGTxqoAu84045.jpg

wKioL1Xlo9OSl5stAAMFqaa8keQ933.jpg

表示数据段已丢失, 574是数据丢失的位置,#1 代表丢失一次。

一般情况下,当网络延时增大导致网络速度变慢,是产生重复ACK的一个主要原因。或者是服务端或者客户端响应速度变慢或者没没有响应。

TCP out-of-order

wKiom1XlXcCDqfqcAADCxhkH-Ys945.jpg

wKiom1XlXc-ie_uLAAG86whhBSI904.jpg

由于收到的数据包乱序,有可能是网络拥塞或者路由上存在负载分担的情况,导致后发送的数据包先达到。

TCP Restransmission 重传

wKioL1XlYAHjxAxxAAQHFLqHGJ4246.jpg

170号数据包是为167号数据包做的重传操作,所以seq ack都是一样的,seq=2070 ack=6264

TCP previous segment not captured 之前的分段未收到

wKiom1XpDFGBi6qLAAPwxDW2DoE290.jpg

说明乱序了,未收到之前的数据包,也要进行重传,1932的ack=83066,也就是要求server端下次发送seq=83066的包,结果 1933发送的数据包seq=85946.说明server端收到过client端发送的数据包ack=85946,则判断之前的一个数据包未收到。在1934 对1932数据包进行重传操作。

你可能感兴趣的:(转:关于wireshark抓包的那点事儿)