PCAP实时捕获的最佳SNAPLEN是多少？

Question

当使用 pcap_open_live 从接口捕获数据包时，我看到很多例子都使用各种数字作为 SNAPLEN 值，范围从 BUFSIZ (<stdio.h>) 到 "魔法数字"。

将 SNAPLEN 设置为我们正在捕获的接口的 MTU 是否更有意义呢？ 这样，我们可以一次将更多的数据包放入 PCAP 缓冲区。可以假设 MRU 等于 MTU 吗？

否则，是否有一种非奇异的方法来设置 SNAPLEN 值？

谢谢

- ziu

Answer 1

MTU是可以传递给链路层的最大有效载荷大小；它不包括任何链路层头，因此，在以太网上，MTU大小为1500，而不是1514或1518，也无法捕获完整的以太网帧。此外，它也不包括任何元数据头，例如802.11射频信息的radiotap头。

如果适配器正在执行任何形式的分段/分割/重组卸载，则递交给适配器或从适配器接收的数据包可能尚未被分段或分割，或已经被重新组装，因此可能比MTU要大得多。

至于如何在PCAP缓冲区中容纳更多的数据包，这仅适用于Linux中的内存映射TPACKET_V1和TPACKET_V2捕获机制，其具有固定大小的数据包槽。其他捕获机制没有为每个数据包保留最大尺寸的空间，因此较短的快照长度并不重要。对于TPACKET_V1和TPACKET_V2，较小的快照长度可能会有所影响，但至少对于以太网来说，libpcap 1.2.1会尽力选择适当的以太网缓冲区槽大小。（TPACKET_V3似乎没有固定大小的每个数据包槽，因此它不会有这个问题，但它仅在近期的正式发布的内核中出现，并且libpcap中尚不存在对其的支持。）

- user862787

---

好的，那么我需要“猜测”一下我要监控的流量的可能最大大小。 - ziu

如果您正在使用带有现代版本libpcap的Linux，并且版本不是1.2.1或更高版本，或者您没有在以太网上进行捕获（或者在以太网上进行捕获时关闭了分段/分割/重组），并且您不想分配巨大的共享内存缓冲区（使用pcap_create()/pcap_set_buffer_size()/pcap_activate()），并且想避免数据包丢失，那么您必须猜测传递给libpcap的数据包的最大可能大小。 - user862787

好的，我的问题有两个，因为我在获取新数据包之前没有分析每个数据包，所以我必须在用户应用程序级别上进行缓冲。这就是为什么我正在尝试减少内存使用的原因。 - ziu

那么，您需要在代码中设置一个缓冲方案，不为所有数据包分配最大数据包大小的缓冲区，或者您必须选择“最小足够”的最大数据包大小；后者比较棘手（这就是为什么libpcap只在某些情况下尝试使用TPACKET_V[12]）。 - user862787