Wireshark抓包 [Tcp Previous Segment Not captured][Tcp Out-Of-Order][Tcp Spurious Retransmissiion]

Wireshark抓包时，除了TCP协议的三次握手建立连接、数据收发和四次握手断开连接外，还经常能看到如下几种不太常见的报文，具体包括：

1.Tcp Previous Segment Not captured

2.Tcp Out-Of-Order

3.Tcp Dup Ack 12345#1

4.Tcp Spurious Retransmissiion

5.Tcp Retransmission

其中1、2、3会相伴出现，3、4、5会相伴出现。对应第一种情况是由于由于TCP数据被分块后，传输过程中经过不同的路径，到达目的端时乱序，出现后发而先至的情况，此时目的端会显示【Tcp Previous Segment Not captured】，并且用【Tcp Dup Ack 12345#1】对前一个包再次进行确认，先发而后至的包到达目的端时，会显示【Tcp Out-Of-Order】；对应第二种情况是由于网络不稳定，源端发送数据后，目的端进行了确认，但源端并未在规定的时间内收到确认，所以会重新发送，目的端对重新发送的报文会显示为【Tcp Spurious Retransmissiion】，并且用【Tcp Dup Ack 12345#1】确认。这两种情况出现属于正常情况，TCP的超时重传机制和乱序重排可以保证TCP的按序可靠传输。

下面以具体的抓包数据进行说明。

从98522~98527是第一种情况的完整再现，具体包括：

1）98522是建立SSL过程中服务端到客户端的Server Hello报文，具体如下图：

发送报文序列号为1，报文长度为1424，确认对端的214发送序列号

2）98523是客户端对前一个报文的确认，具体如下图：

3）98524是后发而先至的报文，具体如下图：

很显然，客户端期望确认的序号是1425，实际收到的报文开始序列号为2849。在1425~2848之间的报文还未到达

4）98525是客户端对乱序的应答，具体如下图：

由于客户端并未收到至2849的完整报文，重复对98523的报文，仅对98522报文进行确认

5）98526是先发而后至的报文，具体如下图：

本报文就是98525期待的报文，这样客户端收到至2848的所有报文。用【Tcp Out-Of-Order】显示

从15774~15840是第二种情况的完整再现。

1）15774是服务端发送的请求修改密码算法的报文，具体如下图：

报文起始序列号是3589，同时对上一个报文数据的确认

2）15775是客户端发送SSL密文，具体如下图：

本报文其实序列号是367，同时对15774进行确认（3640）

3）15816是重传报文。服务端未收到15775 的确认，所以重传15774报文，具体如下图：

可以看到跟15774报文完全一致。客户端因为已经对该包进行了确认，确认后又收到重传报文，所以显示【Tcp Spurious Retransmissiion】

4）15817针对这样一种情况，返回与15775同样的确认，具体如下图所示：

5）15823是因为未收到服务端对15775的确认而重新发送15775报文，具体如下图所示：

可以看到与15775完全一致

6）15840是服务端对客户端重传的15823报文的确认