pcap - 使用 pcap_loop 时丢包

Question

我有一个数据包捕获应用程序，它使用 pcap_loop() 进行数据包捕获，但发现数据包丢失。

我正在尝试向主机发送 20 个 DNS 查询。在机器上运行 tcpdump 显示 1 已收到 20 个 DNS 查询数据包和 20 个 DNS 响应数据包，这是正确的。但是我的数据包捕获应用程序收到 20 个查询，但只收到 11 个响应数据包。知道为什么 pcap_loop 缺少一些响应数据包吗？

我发现下面这个链接说:链接:Asynchronous libpcap: losing packets? **“可能的情况是，您发送的请求太多太快，而服务器发送响应的速度比您可以处理它们的速度更快，从而使操作系统的网络缓冲区过载并丢弃数据包。

即使您在 tcpdump 中看到数据包，如果您的应用程序无法处理接收数据包的速率，它们仍可能被操作系统丢弃。"**

这可能是我丢包的原因吗？如果是这样，我该如何处理这种情况，因为我无法在服务中添加延迟以延迟发送响应，因为在我的主机中运行的其他应用程序将受到影响。

我按以下顺序为我的数据包捕获应用程序使用以下 pcap 例程配置:

1. pcap_lookupnet((char *)dev, &net, &mask, errbuf)
2. pcap_open_live((char *)dev, 65535, 0, 1000, errbuf)
3. pcap_compile(pc, &prog, (char *)filterexpr, 0, net)
4. pcap_setfilter(pc, &prog)
5. pcap_compile(pc, &prog, (char *)filterexpr, 0, net)
6. pcap_loop(pc，-1，handle_packet，NULL)；

注意:filterexp exp 为 udp 端口​​ 53

如果我发送大约 10 个 DNS 查询，那么我会收到所有查询和响应数据包。仅当我们有更多数据包时，我才会看到此问题。任何指示都会有帮助。

谢谢。********

$ tcpdump udp -i eth1 -ntcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes10:05:27.066801 IP 10.36.0.96.45267 > 10.35.103.6.domain: 1+ A? Baaaaaaaaaaaaaaaaaa.t2oovm3zgkx9xp05gvn0y2.com. (64)10:05:27.066828 IP 10.36.0.96.45267 > 10.35.103.6.domain: 2+ A? aaaaaaaaaaaaaaaaab.ad2rn4fqq7uc0tlsqz4ygm.net. (63)10:05:27.066831 IP 10.36.0.96.45267 > 10.35.103.6.domain: 3+ A? aaaaaaaaaaaaaaaaac.aawabh0usmsle87qtdg8br.edu. (63)10:05:27.066837 IP 10.36.0.96.45267 > 10.35.103.6.domain: 4+ A? aaaaaaaaaaaaaaaaad.vrgztlp1fatm1hipf315r9.jp. (62)10:05:27.066842 IP 10.36.0.96.45267 > 10.35.103.6.domain: 5+ A? aaaaaaaaaaaaaaaaae.xr3au4o2plet984siue2wr.xxx. (63)10:05:27.066845 IP 10.36.0.96.45267 > 10.35.103.6.domain: 6+ A? aaaaaaaaaaaaaaaaaf.gvcx9lia6hlah8ay4wheps.com. (63)10:05:27.066848 IP 10.36.0.96.45267 > 10.35.103.6.domain: 7+ A? aaaaaaaaaaaaaaaaag.jhiu5ebw9bmbnq0reufe9z.net. (63)10:05:27.066851 IP 10.36.0.96.45267 > 10.35.103.6.domain: 8+ A? aaaaaaaaaaaaaaaaah.a325vjl3v1gkw9sf8mjgna.edu. (63)10:05:27.066853 IP 10.36.0.96.45267 > 10.35.103.6.domain: 9+ A? aaaaaaaaaaaaaaaaab.ad2rn4fqq7uc0tlsqz4ygm.net. (63)10:05:27.066857 IP 10.36.0.96.45267 > 10.35.103.6.domain: 10+ A? aaaaaaaaaaaaaaaaac.aawabh0usmsle87qtdg8br.edu. (63)10:05:27.066860 IP 10.36.0.96.45267 > 10.35.103.6.domain: 11+ A? aaaaaaaaaaaaaaaaad.vrgztlp1fatm1hipf315r9.jp. (62)10:05:27.066882 IP 10.36.0.96.45267 > 10.35.103.6.domain: 12+ A? aaaaaaaaaaaaaaaaae.xr3au4o2plet984siue2wr.xxx. (63)10:05:27.066886 IP 10.36.0.96.45267 > 10.35.103.6.domain: 13+ A? aaaaaaaaaaaaaaaaaf.gvcx9lia6hlah8ay4wheps.com. (63)10:05:27.066888 IP 10.36.0.96.45267 > 10.35.103.6.domain: 14+ A? aaaaaaaaaaaaaaaaag.jhiu5ebw9bmbnq0reufe9z.net. (63)10:05:27.066892 IP 10.36.0.96.45267 > 10.35.103.6.domain: 15+ A? aaaaaaaaaaaaaaaaah.a325vjl3v1gkw9sf8mjgna.edu. (63)10:05:27.066935 IP 10.36.0.96.45267 > 10.35.103.6.domain: 16+ A? aaaaaaaaaaaaaaaaai.f5t6kc1ijgnd655fauwk6e.jp. (62)10:05:27.066940 IP 10.36.0.96.45267 > 10.35.103.6.domain: 17+ A? aaaaaaaaaaaaaaaaai.f5t6kc1ijgnd655fauwk6e.jp. (62)10:05:27.066944 IP 10.36.0.96.45267 > 10.35.103.6.domain: 18+ A? aaaaaaaaaaaaaaaaai.f5t6kc1ijgnd655fauwk6e.jp. (62)10:05:27.066946 IP 10.36.0.96.45267 > 10.35.103.6.domain: 19+ A? aaaaaaaaaaaaaaaaai.f5t6kc1ijgnd655fauwk6e.jp. (62)10:05:27.066983 IP 10.36.0.96.45267 > 10.35.103.6.domain: 20+ A? aaaaaaaaaaaaaaaaaj.iaoq8srst9fud1uvgv72iw.xxx. (63)10:05:27.067239 IP 10.35.103.6.domain > 10.36.0.96.45267: 1 1/0/0 A 158.143.55.1 (80)10:05:27.067252 IP 10.35.103.6.domain > 10.36.0.96.45267: 3 1/0/0 A 169.143.55.1 (79)10:05:27.067288 IP 10.35.103.6.domain > 10.36.0.96.45267: 2 1/0/0 A 164.143.55.1 (79)10:05:27.067300 IP 10.35.103.6.domain > 10.36.0.96.45267: 4 1/0/0 A 159.143.55.1 (78)10:05:27.067335 IP 10.35.103.6.domain > 10.36.0.96.45267: 7 1/0/0 A 167.143.55.1 (79)10:05:27.067343 IP 10.35.103.6.domain > 10.36.0.96.45267: 5 1/0/0 A 165.143.55.1 (79)10:05:27.067345 IP 10.35.103.6.domain > 10.36.0.96.45267: 6 1/0/0 A 177.143.55.1 (79)10:05:27.067375 IP 10.35.103.6.domain > 10.36.0.96.45267: 10 1/0/0 A 169.143.55.1 (79)10:05:27.067383 IP 10.35.103.6.domain > 10.36.0.96.45267: 8 1/0/0 A 168.143.55.1 (79)10:05:27.067412 IP 10.35.103.6.domain > 10.36.0.96.45267: 12 1/0/0 A 165.143.55.1 (79)10:05:27.067421 IP 10.35.103.6.domain > 10.36.0.96.45267: 13 1/0/0 A 177.143.55.1 (79)10:05:27.067448 IP 10.35.103.6.domain > 10.36.0.96.45267: 14 1/0/0 A 167.143.55.1 (79)10:05:27.067455 IP 10.35.103.6.domain > 10.36.0.96.45267: 9 1/0/0 A 164.143.55.1 (79)10:05:27.067470 IP 10.35.103.6.domain > 10.36.0.96.45267: 11 1/0/0 A 159.143.55.1 (78)10:05:27.067485 IP 10.35.103.6.domain > 10.36.0.96.45267: 17 1/0/0 A 176.143.55.1 (78)10:05:27.067495 IP 10.35.103.6.domain > 10.36.0.96.45267: 18 1/0/0 A 176.143.55.1 (78)10:05:27.067502 IP 10.35.103.6.domain > 10.36.0.96.45267: 16 1/0/0 A 176.143.55.1 (78)10:05:27.067532 IP 10.35.103.6.domain > 10.36.0.96.45267: 15 1/0/0 A 168.143.55.1 (79)10:05:27.067539 IP 10.35.103.6.domain > 10.36.0.96.45267: 19 1/0/0 A 176.143.55.1 (78)10:05:27.067618 IP 10.35.103.6.domain > 10.36.0.96.45267: 20 1/0/0 A 171.143.55.1 (79)10:05:34.642563 IP 42.0.1.41.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:30:48:9e:a3:bb, length 300

Answer 1

好的，他们都使用 libpcap 1.1.1。

遗憾的是，这意味着“操作系统缓冲区”始终是单数据包缓冲区插槽的集合，其大小与打开捕获设备时使用的快照长度一样大。它默认为 2MB，因此，快照长度为 65535，即 32 个缓冲区插槽，因此，如果您的程序处理数据包的速度不够快，则 40 个数据包可能会溢出缓冲区。 20+11=31，所以看起来这可能就是正在发生的事情。

Tcpdump 也使用快照长度 65535； 如果它在pcap_loop()回调中所做的工作比您的程序在其回调中所做的工作少，并且如果它没有阻塞打印与您的程序通过执行任何按数据包 I/O 执行的操作相比，它能够跟上标准输出的速度。

尝试使用例如 2048 作为快照长度，而不是 65535。您不会收到 TCP 数据包，因此您不必担心 TCP 分段卸载导致您的程序获得非常大的数据包，并且您可能正在捕获数据包长度限制为最大以太网数据包大小(1514 字节，除非使用“巨型帧”)的网络，因此这应该足够了。这将减少单数据包缓冲区槽的大小，从而增加这些槽的数量。

当然，这不会阻止您的程序落后，因此，如果它要运行很长一段时间，您必须确保它能够以数据包到达的平均速率处理数据包- 操作系统中的缓冲处理突发，在短时间内，数据包到达的速度快于其消耗的速度，但程序可以在“较慢”的时间内 catch 。

更高版本的 libpcap(1.2 及更高版本)尝试，如果可以的话，将单数据包缓冲区槽的大小减小到最大数据包大小(“如果> 他们可以”意味着它不能总是确定最大数据包大小；它仅在以太网上工作，并且仅在关闭各种形式的 TCP 分段/解除分段卸载时起作用)。

直到Linux 3.2引入了TPACKET_V3(它没有那些烦人的固定长度单数据包缓冲区插槽)，Linux PF_PACKET套接字(这是Linux提供的用于数据包捕获的内置机制)不支持数据包捕获得非常好，甚至 TPACKET_V3 也有一些恼人的错误，直到 3.19 才修复。