libpcap：pcap_dispatch 或 pcap_next 的效率是多少

Question

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

首先，我创建一个 libpcap 处理程序handle并将其设置为非阻塞，并用于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在非阻塞模式下也需要错误检查）和一个副本（libpcap释放尽快共享缓冲区中的“槽”，因此它不能只返回该指针）。实现细节是，在 Linux 上，pcap_next仅调用pcap_dispatch一个数据包并使用复制回调。