libpcap：pcap_dispatch或pcap_next的效率是多少

Question

我使用libpcap捕获大量数据包，然后处理/修改这些数据包并将它们发送到另一台主机。

首先，我创建一个libpcap处理程序handle并将其设置为NON-BLOCKING，然后使用pcap_get_selecable_fd(handle)获取相应的文件描述符pcap_fd。

然后我将这个pcap_fd的事件添加到libevent循环（就像select（）或epoll（））。

为了避免频繁轮询此文件描述符，每次有数据包到达事件时，我都会使用pcap_dispatch收集缓冲的数据包并将它们放入队列packet_queue，然后调用process_packet处理/修改/发送队列packet_queue中的每个数据包。

  pcap_dispatch(handle, -1, collect_pkt, (u_char *)packet_queue);
  process_packet(packet_queue);

我使用tcpdump来捕获process_packet(packet_queue)发送的数据包，并注意：

1. 一开始，发送数据包之间的间隔很小
2. 在发送了几个数据包之后，间隔变为大约0.055秒
3. 发送20个数据包后，间隔变为0.031秒并保持0.031秒

我仔细检查了我的源代码，发现没有可疑的块或逻辑导致如此大的间隔。所以我想知道是否是由于函数pcap_dispatch的问题。

pcap_dispatch或pcap_next甚至是libpcap文件描述符都存在效率问题吗？ 谢谢！

Answer 1

在许多平台上，libpcap使用特定于平台的实现来更快地捕获数据包，因此使用YMMV。通常，它们涉及内核和应用程序之间的共享缓冲区。

1. 从一开始，您就有一个时间窗，在数据包开始堆积在RX缓冲区和开始处理之间。这些数据包的累积可能导致此处的频率更高。无论实现如何，这部分都是正确的。
2. 我还没有找到令人满意的解释。也许您落后了并且错过了一些数据包，因此重发数据包之间的时间变得更长。
3. 我认为这是您在正常操作中所期望的。

pcap_dispatch至少与libpcap一样好。另一方面，pcap_next会产生两个惩罚（至少在Linux上会这样，但我认为在其他主流平台上也会这样）：每个数据包的系统调用（libpcap为错误检查，即使在非阻塞模式下也是如此）并复制（poll会尽快释放共享缓冲区中的“插槽”，因此它不能仅返回该指针）。一个实现细节是，在Linux上，libpcap仅针对一个数据包调用pcap_next并使用复制回调。