问题背景
首先，案例来自于互联网，数据包分析过程相对简单，但对个人来说，算是之前没实际碰到的情况，因此分享一下。
问题描述
当第一次查看数据包文件时，一眼就能看到 “Bad TCP” 的鲜艳着色，这说明或多或少存在着问题。
打开分析-专家信息：
看到了 Previous segment not captured，可能都知道发生丢包了，99.99%的情况下包丢失发生在互连设备上，有可能是设备过载，也有可能是设备故障。
但是实际真的发生丢包了嘛？
问题分析
或者你会有这样的疑问，如果有这么多丢失的数据包，难道不应该看到至少一次重传吗？可是，真的确实没有。( 而对于精通数据包分析的老司机来说，同时看到了 ACKed segment that wasn’t caputred 信息，应该很快就能分析得出结论 )
首先，TCP三次握手看起，很明显数据包2 (SYN+ACK)，在数据包1之后500多微秒后发送，以及数据包3 34毫秒的现象，可以判断出抓包的位置是在服务器上，或者说非常靠近服务器。因此也可以说明一种情况，不太可能错过服务器的重传包。
显示过滤器，输入" tcp.stream == 9 " 跟踪任意一个流
可以看到数据包57的 Seq 并非数据包56的 NextSeq，因此数据包57提示 TCP Previous segment not captured 意味着有丢包，大概2K多字节。
但紧接着数据包58的 ACK 确认了6001，标记 ACKed segment that wasn’t caputred ，代表说客户端确认收到了序列号6001之前的所有数据包。
收到并且确认了，而不是没收到，这样答案就很明显了，很有可能是交换机镜像会话丢弃了数据包，也就是说在镜像目的端口发生了数据包丢失，而不是真实会话发生了数据包丢失， 所以数据包文件才会显示有丢包，而且也才没有捕捉到数据包重传的现象。
同时可以进一步检查交换机镜像目的端口的 output drops，用来验证交换机性能超载情况。
问题总结
对于 TCP Previous segment not captured 的情况，不要轻易下结论，需要结合上下文，看看是否有相应的乱序、重传或者快速重传等等，再来进一步分析判断问题。
