前言

我们都知道，一般流量分析设备都支持pcap回放离线分析的功能，但如果抓的pcap丢了包，会影响最终安全测试的效果。比如说竞测现场需要提供pcap包测试恶意文件的检测功能，如果pcap中丢包，可能会导致文件还原失败，最终恶意文件检测功能“实效”。

那问题来了，我们怎么识别pcap包是否有丢包呢？接下来，我们通过wireshark来查找pcap文件中的丢包线索。

0x01 完整？丢包？

思路1：透过现象看现象。

在真实的网络分析场景中，特别是传输大文件时，经常会发现这样的现象：

大文件已经传输到了对端，但是pcap中却存在丢包。

这是为什么呢？网络数据包真的有完整地传输给对端吗？

毋庸置疑，对端收到了完整地文件，数据包时肯定传输到了对端。那为什么wireshark中的pcap包丢包了呢？

我们还是来看看wireshark的抓包原理吧！

wireshark在Linux操作系统中，底层是基于libpcap进行抓包的，tcpdump底层也是基于libpcap的，关于tcpdump的底层的收包原因已经在tcpdump能进行丢包分析吗？一文中已经分析过了网卡层面的流程和入口，这里就不再赘述了。

由此我们可明确一点：产生上述现象的原因，并不是网卡丢包，因为网卡层面的丢包肯定会影响文件数据的完整性，由此如果我们排除wireshark使用错误产生的丢包，还可能是在下面这个过程中丢的包：

通过deliver_skb来进入 packet_rcv阶段 ，packet_rcv 把收到的skb放到当前的packet socket缓冲区，应用层调用recvfrom就可以将缓冲区中的数据包拷贝到应用层，从而实现libpcap的收包，大致过程如图1所示：

图片

图1：libpcap的收包过程

所以我们能够得出wireshark丢包的原因可能是：

1、packet socket缓冲区已满导致丢包；

2、从缓冲区拷贝到应用层中断异常导致丢包。

3、当然排除以上两条，也有可能是多路径网络结构允许属于同一 TCP 会话的数据包通过不同的网络接口，导致wireshark捕获的数据包不全。

可是在我们日常的流量分析工作中，往往会根据对端有没有完整地数据包来判断我们用wireshark抓的数据包是否完整，这样做可能会严重影响安全测试的工作效率。那有没有能够快速分析pcap包中是否丢包的方法呢？

答案是有，可以用wireshark的专家信息快速分析丢包的效果。

0x02 丢包线索

思路2：透过本质看现象。

打开wireshark，在工具栏中点击“分析->专家信息”，如图1、图2所示：

图片

图1：wireshark的专家信息位置

wireshark的专家信息中提供了错误、警告、注意、对话这4种信息，选中任意一条都能定位到具体的数据包。

图片图2：wireshark的丢包警告1

图片

图3：wireshark的丢包警告2

那专家信息中的哪些信息提示了丢包的线索呢？

1、Acked segment that wasn't capture(common at capture start)，如图2所示：表示此数据包已经ack了未捕获的数据。传输正常，接收方已经确认，但 Wireshark 无法在捕获的数据中找到某段数据包， 这通常发生在捕获设备不够快的时候，比如libpcap的接收缓冲区已满，或者由缓冲区向应用层拷贝的时候导致的丢包。

2、TCP Previous segment not captured，如图3所示：表示如果数据包 N 标有未捕获的前一个段，则表示在捕获中没有来自同一 TCP 会话的数据包，其 [seq + 长度≠数据包 N 的 seq ]。最典型的原因是数据包丢失或延迟启动捕获，但也有可能是发送方的 TCP 堆栈有问题，或者是多路径网络结构允许属于同一 TCP 会话的数据包通过不同的网络接口，导致数据包确实到达目的地，但没被 Wireshark 捕获到。

0x03 结论

1、1句忠告：不能通过判断数据包是否已被接收端收到来判断pcap中是否丢包。

2、1个小tip：pcap丢包可以通过wireshark的专家信息快速定位和判断。

3、4条经验：由wireshark产生的丢包可能有4种原因，

①packet socket的缓冲区已满导致丢包；

②从缓冲区拷贝到应用层中断异常导致丢包；

③wireshark使用不当，延迟启动捕获导致丢包；

④也有可能是多路径网络结构允许属于同一 TCP 会话的数据包通过不同的网络接口，导致wireshark捕获的数据包不全。