前言

流量安全分析设备首先需要经过协议解析，解析后形成不同的业务日志。某次在排场现场设备的过程中发现：某业务流量在某个方向无日志。由于现场设备背景流量比较多，又不能中断流量进行调试，因此只能通过tcpdump抓包分析。

分析过程中踩了不少坑，故作此总结。

总体思路

1、分析pcap包中的流量是否丢失

2、分析流量是否是设备已兼容的协议格式

3、分析是否是设备丢包

分析过程

tcpdump分别抓小文件(little.pcap)和批量大文件(big.pcap)上传时的流量， 通过wireshark分析big.pcap存在大量包的丢失，而little.pcap包正常。实验室设备回放结果表明：现场设备解析异常与流量的方向无关，与协议格式无关，可能是设备丢包。

那接下来的思路，从设备丢包为线索来分析。

丢包可能的原因如下：

1、网卡丢包

2、系统内存不足

3、TCP/IP协议栈丢包

那么问题来了，所有的这些丢包行为都能被tcpdump捕获到吗？要想知道tcpdump的抓包位置，就得从Linux网络数据包的收发过程开始，这里以数据包接收为例。

3.1 Linux网络数据包的接收过程

NIC ：网络适配器

DMA：直接存储访问

NIC Interrupt Handler：网络适配器中断句柄

Poll_quenue ：Poll队列

SoftIrq：软中断

接收过程如图所示：

图1-Linux网络数据包接收过程

• 1、在系统启动后，系统会分配Ring Buffer和专门的内核内存区域给NIC用于存放传输上来的数据包。当有数据时，DMA负责从NIC取数据存入内核内存，并在Ring Buffer上寻找下一个可用数据。
• 
  2、当DMA读取完数据之后，NIC会触发IRQ硬中断让CPU去处理收到的数据。
• 
  3、为了能够集中处理IRQ，这里会通过poll队列批量拉取数据。
• 
  4、通过某种机制触发softirq软中断，获取数据包并执行基本的检查
• 
  5、最后对数据包进行基本的统计和其他处理，交由上层协议栈处理。

从Linux网络数据包大致接收过程可以知道，tcpdump能不能分析”丢包“还得看情况，取决于tcpdump到底在网络数据包传输的哪个过程中抓包的。

那接下来进一步深入到收包的细节当中去，看看tcpdump到底工作在哪个环节？

3.1 Linux网络数据包的接收流程细节描述

如图所示（星号所在位置就是tcpdump的抓包位置）：

__netif_receive_skb_core是协议栈处理数据包的入口函数，在 __netif_receive_skb_core 这个函数里会遍历 ptype_all 上的协议，然后遍历 ptype_all，并使用 deliver_skb 来调用协议中的回调函数。

而tcpdump是ptype_all中的一个伪协议，通过这种方式获得数据包的处理权。即通过deliver_skb来进入 packet_rcv阶段 ，packet_rcv 把收到的skb放到当前的packet socket的接收队列中，应用层调用recvfrom就可以将接收队列中的数据包拷贝到应用层，从而实现tcpdump的收包。

那从tcpdump的抓包位置来看，tcudmp确实能分析丢包，但是却不能覆盖所有的场景，对于一个旁路的流量分析设备莱索，只能分析下面场景的丢包：

1、网卡丢包

2、RingBuffer溢出

对于网络协议栈的丢包，tcpdump也无能为力。

接下来就针对上面的两个丢包的场景，进一步确定在哪个地方丢包，从而找到合适的解决方案。

我们可以通过ifconfig进一步诊断：

这里只关注接收方向（RX）的dropped和overruns：

举个例子，如图所示：

这张表里总结了当前设备可能丢包的情况，因此应对此时丢包的方案：

1、优化per CPU的中断分配方案

2、升级网卡

总结

对于旁路的流量分析设备来说，只关注接收方向，tcpdump只能分析由网卡、系统内存等系统原因产生的丢包，不能判断网络协议栈的丢包行为。

参考资料

1、用户态 tcpdump 如何实现抓到内核网络包的

2、数据包如何从物理网卡到达云主机的应用程序？

3、参考linux-5.16.15内核源码

4、《深入理解Linux网络技术内幕》