gpt4 book ai didi

udp - 使用tcpdump监视流量时缺少UDP片段

转载 作者:行者123 更新时间:2023-12-05 01:21:46 27 4
gpt4 key购买 nike

我在本地局域网中,只有8台连接的计算机使用netgear 24端口千兆交换机,网络负载确实很低,并且所有涉及的节点(运行slackware 11)上的发送/接收缓冲区都设置为16mb。我还在每个节点上运行tcpdump来监视流量。

发送节点发送10044字节的大型UDP数据包,该数据包通常(3/4倍)未出现在接收方应用程序中,在这种情况下,我注意到(使用tcpdump)前x个片段丢失了,只有最后一个x片段丢失了tcpdump捕获了3个(所有偏移量都大于0且顺序排列)。因此,碎片化的UDP包无法重新组装,很可能会被丢弃。

我发现丢失的片段很奇怪,因为我还尝试了一个简单的负载测试,该测试突发了相同大小的10000条UDP消息,接收应用程序发送了响应,到目前为止所有测试都提供了100%的响应。

有任何线索或提示吗?

最佳答案

更新!

在恢复对上述软件的测试之后,我发现了一种可重复的错误再现方法。

在将应用程序闲置了一段时间(约5分钟)后,在发送Windows机器上使用windump,在接收机器上使用tcpdump,我尝试发送udp消息,但最终只有一个被windump和tcpdump捕获的片段,剩下的3个片段丢失了。再发送一次相同的消息可以正常工作,并且展位windump和tcpdump捕获了所有4个片段,并且接收方的应用程序收到了该消息。模式是可重复的。

开始搜索并找到以下信息,但对我来说,仍然不是一个明确的答案。

http://www.eggheadcafe.com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx

重新检查日志后,我现在注意到正在发送ARP请求/答复,该请求与上面链接中给出的想法之一匹配。

注意!我使用以下命令过滤发送方的windump:“ dst host receivernode”

从Windump中捕获:第一个失败的udp消息,长度应为4个片段

14:52:45.342266 arp who-has receivernode tell sendernode
14:52:45.342599 IP sendernode> receivernode : udp


从Windump中捕获:第二条udp消息,内容完全相同,所有4个片段均被捕获

14:52:54.132383 IP sendernode.10104 > receivernode .10113: UDP, length 6019
14:52:54.132397 IP sendernode> receivernode : udp
14:52:54.132406 IP sendernode> receivernode : udp
14:52:54.132414 IP sendernode> receivernode : udp
14:52:54.132422 IP sendernode> receivernode : udp
14:52:56.142421 arp reply sendernode is-at 00:11:11:XX:XX:fd (oui unknown)


有人对发生的事情有个好主意吗?请详细说明!

关于udp - 使用tcpdump监视流量时缺少UDP片段,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1324819/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com