数据包顺序

TCP Previous sement not captured

出现在连续的数据包，出现丢包的情况，与上一个数据包之间存在丢包现象

TCP Dup ACK 序号#次数

出现在丢包客户端反复请求

TCP Fast Restransmission

出现在客户端请求丢失的报文，快速重传的的第一个丢失的数据包

TCP Restransmission

服务器按照丢失报文的顺序发送

 

三次握手建立连接

本地端口号58400

服务器端口号80

 

 

 

数据包的序号

客户端请求序号1467的数据包报文接收完毕

客户端又请求数据

序号1955，的数据分片接收。

 

 

 

丢包分析

 

第一黑色的标志着出现了丢包，

序号4262----seq = 413130  Ack = 977

-----------------Seq = 414526 Ack = 977               丢失

-----------------Seq = 415922 Ack = 977              丢失

序号4267----Seq = 417318 Ack = 977               WireShark标记黑色

导致接收到的数据包不连续，标记黑色。

之后都是按照黑色的数据包顺序，继续发包，不丢包不标记黑色。

 

当第一个数据包丢了以后，主机请求这个丢失的报文

同时又接收到了417318到420120的数据包

SLE/SRE表示已经接收到的数据包

左边界和右边界，作用告诉服务器这些报文已经接收到了，不需要重新发送。

左边界一直不变，右边界持续增加，说明后续的数据包都接收到了。

TCP Dup ACK 4272#4  意思是重复应答序号4272的丢失的报文，#4代表了重复了次数，重复了第四次，

 

服务器重发丢失的报文

 

序号4418 时服务器重发了丢失的第一个报文

4422发送了第二个丢失的报文

 

序号4443，客户端回应服务器

收到了415922的数据包。和417318到442446的报文

415922+1396=417318，也就是说所有的数据包442446之前的报文全都接收到了

4445序号的终端回应服务器发送442446开始的报文

 

第二部分丢失报文的分析与前面一样

序号4476----Seq = 446634 Ack = 977  下个数据包应该是448030

    Seq = 448030 Ack = 977            丢失

    Seq = 449426 Ack = 977            丢失

    Seq = 450822 Ack = 977            丢失

    Seq = 452218 Ack = 977            丢失

    Seq = 453614 Ack = 977            丢失

    Seq = 455010 Ack = 977            丢失

序号4487---Seq = 456406 Ack = 977 直接丢了6个数据包直接到456406

 

服务器开始重传丢失的报文

可以看到，黑色标记的六个报文都补充完整了

按照顺序客户端都确认收到报文，

 

 

TCP连接的四次挥手

 

服务器发送FIN ACK 报文，通知客户端结束连接

客户端应答+1，收到，结束的报文

客户端发送FIN ACK 报文确认结束

服务器应答，结束。