network-programming - libpcap:pcap_dispatch 或 pcap_next 的效率是多少

我使用 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) 发送的数据包，并注意:

一开始，发送数据包的间隔很小

发送多个数据包后，间隔变为 0.055 秒左右

发送 20 个数据包后，间隔变为 0.031 秒并保持为 0.031 秒

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

pcap_dispatch 或 pcap_next 甚至 libpcap 文件描述符是否有任何效率问题？
谢谢!

最佳答案

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

一开始，在数据包开始堆积在 RX 缓冲区和开始处理之间有一个时间窗口。这些数据包的积累可能会导致这里出现更高的频率。无论实现如何，这部分都是正确的。

我还没有找到令人满意的解释。也许您落后并错过了几个数据包，因此您重新发送数据包之间的时间变得更长。

我想这就是您在正常操作中所期望的。

pcap_dispatch 非常好，至少在 libpcap 中。另一方面， pcap_next 会导致两个惩罚(至少在 Linux 上，但我认为它在其他主流平台上也是如此):每个数据包的系统调用( libpcap 调用 poll 进行错误检查，即使在非阻塞模式下)和copy ( libpcap 尽快释放共享缓冲区中的“槽”，因此它不能只返回该指针)。一个实现细节是，在 Linux 上，pcap_next 只为一个数据包调用 pcap_dispatch，并带有一个复制回调。