使用 tcpdump 监控流量时丢失 UDP 片段
我所在的本地 LAN 上只有 8 台连接的计算机，使用 netgear 24 端口千兆位交换机，网络负载非常低，所有相关节点（运行 slackware 11）上的发送/接收缓冲区已设置为 16mb。我还在每个节点上运行 tcpdump 来监控流量。
发送节点发送一个 10044 字节的大 UDP 数据包，该数据包通常（3/4 次）不会在接收端应用程序中结束，在这些情况下，我注意到（使用 tcpdump）前 x 片段丢失，只有最后一个片段丢失3（所有偏移量> 0并且按顺序）被tcpdump捕获。因此，碎片化的 UDP 数据包无法重新组装，很可能被丢弃。
我发现丢失的片段很奇怪，因为我还尝试了一个简单的负载测试，突发了 10000 个相同大小的 UDP 消息，接收应用程序发送了一个响应，并且到目前为止所有测试都给出了 100% 的响应。
有什么线索或提示吗？
I'm on a local LAN with only 8 connected computers using a netgear 24 port gigabit switch, network load is really low and send/receive buffers on all involved nodes(running slackware 11) have been set to 16mb. I'm also running tcpdump on each node to monitor the traffic.
A sending node sends a 10044byte large UDP packet which more often than not (3/4 times) does not end up in the receiving side application, in these cases I notice(using tcpdump) that the first x fragments are missing and only the last 3 (all with offsets > 0 and in order) are caught by tcpdump. The fragmented UDP package can therefore not be reassembled and is most likely thrown away.
I find the missing fragments strange since I have also tried a simple load test bursting out 10000 UDP messages of the same size, the receiving application sends a response and all tests so far gives 100% responses back.
Any clues or hints?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
更新！
恢复上述软件的测试后，我找到了一种可重复的方法来重现错误。
在发送 Windows 计算机上使用 windump，在接收计算机上使用 tcpdump，在使应用程序空闲一段时间（~5 分钟）后，我尝试发送 udp 消息，但最终只得到了 windump 和 tcpdump 捕获的单个片段，剩下的 3 个碎片丢失了。再次发送相同的消息工作正常，booth windump 和 tcpdump 捕获所有 4 个片段，并且接收端的应用程序获取该消息。该模式是可重复的。
开始搜索并找到以下信息，但对我来说，仍然没有明确的答案。
http://www.eggheadcafe。 com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx
重新检查日志，我现在注意到正在发送 ARP 请求/回复，这与链接中给出的想法之一相匹配多于。
笔记！我使用以下方式在发送端过滤 windump：“dst host receivenode”
从 windump 捕获：第一个失败的 udp 消息，应该是 4 个片段长
从 windump 捕获：第二个 udp 消息，完全相同的内容，所有 4 个片段都捕获
了对发生的事情有什么想法吗？请详细说明！
Update!
After resuming the testing of the above mentioned software I found a repeatable way of recreating the error.
Using windump on the sending windows machine, and tcpdump on the receiving machine, after having left the application idle for some time(~5 minutes), I tried sending the udp message but only end up with a single fragment caught by windump and tcpdump, the 3 remaining fragments are lost. Sending the same message one more time works fine and booth windump and tcpdump catches all 4 fragments and the application on the receiving side gets the message. The pattern is repeatable.
Started searching and found the following information, but to me, still not a clear answer.
http://www.eggheadcafe.com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx
Re examining the logs I now notice the ARP request/reply being sent, which matches one of the ideas given in the link above.
NOTE! I filter windump on the sending side using: "dst host receivernode"
Capture from windump: first failed udp message, should be 4 fragments long
Capture from windump: second udp message, exactly the same contents, all 4 fragments caught
Anyone who has a good idea about whats happening? please elaborate!