本文主要是介绍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报文的确认
这篇关于Wireshark抓包 [Tcp Previous Segment Not captured][Tcp Out-Of-Order][Tcp Spurious Retransmissiion]的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
