我注意到当我从udp套接字以均匀间隔发送数据包时，发送的第一个数据包似乎被延迟了。例如，如果我每100毫秒发送一次数据包，我会发现在我的网络上接收正常分布的数据包与平均值100毫秒和平均标准差4之间的延迟。但是，第一个和第二个数据包的接收时间之间的差距通常在10到40毫秒左右 - 正如您所看到的那样，这显然是一个统计上显着的差异，所以我的问题是，是什么导致它？
我在Linux上使用C语言的sendto函数。有人建议延迟可能是由于arp解决方案阻止了数据包被发送，直到目标IP被转换为mac地址 - 这可能吗？如果我重新启动发送程序，第一个数据包再次花费太长时间，并且延迟不一致 - 10到40毫秒是一个相当大的范围。
我需要找出为什么第一个数据包花费的时间太长，以及如何解决它。
编辑：使用pcap进行进一步分析表明发送程序正在以正确的间隔发送数据包。问题必须是接收器，它使用select（）等待可读的套接字，然后调用recvfrom并打印数据包。那里有某种缓冲，我可能不知道吗？
答案 0 :(得分：2)
很可能是ARP地址解析所需的时间。这是将MAC地址解析为IP地址的协议。
要解决此问题，请尝试使用arp -s ip-address hw_address在arp缓存中使用静态条目。
答案 1 :(得分：1)
猜测会让我们无处可去，启动Wireshark它会告诉你所有你需要知道的事情。
答案 2 :(得分：0)
这是在一个局域网上吗？如果是这样，它（可能）归结为ARP和/或主机名解析。如果它跨越一个更大的网络，它可能是任何东西（虽然probbaly与路由查找和缓存填充有关）。
答案 3 :(得分：0)
您询问过变通方法。一种可能的解决方法是，如果要知道数据包的接收时间，则设置SO_TIMESTAMP套接字选项。这将允许您获取目标内核接收每个数据包的时间 - 然后您可以在后续处理中使用此时间而不是“当前时间”。
或者，您可以让发件人在其发送的数据包中包含高分辨率时间戳，并使用这些时间戳。
答案 4 :(得分：0)
我没有足够的“声誉”来表达我认为最好的解决方案，所以我只会说提到ARP消息的人最有可能是正确的。我认为ARP消息应该只适用于局域网。他们会在wireshark上显示为“谁拥有192.168.0.24？”例如...然后会有来自声称拥有该IP地址的任何主机的回复。通过UDP发送到此地址的初始数据包必须获得ARP响应才能将IP地址解析为以太网MAC地址...所以UDP表面看起来似乎永远不会阻塞...但是这只是真的一次ARP地址已解决。我不确定，但我认为如果您将UDP发送到不在LAN上的地址，则不应该要求ARP ...除非找到主网关时出现问题。