udp接收延迟是什么原因造成的？
我注意到，当我从 udp 套接字以均匀的间隔发送数据包时，发送的第一个数据包似乎会延迟。例如，如果我每 100 毫秒发送一次数据包，我发现在我的网络上接收数据包之间的延迟呈正态分布，平均为 100 毫秒，平均标准差为 4。然而，第一个数据包和第二个数据包的接收时间之间的差距通常约为 10 到 40 毫秒 - 正如您所看到的，这显然是一个统计上显着的差异，所以我的问题是，是什么原因造成的？
我在 Linux 上使用 C 的 sendto 函数。有人提出延迟可能是由于 arp 解析导致数据包无法发送，直到目标 ip 转换为 MAC 地址 - 这可能吗？如果我重新启动发送程序，第一个数据包再次花费太长时间，并且延迟不一致 - 10 到 40 毫秒是一个相当大的范围。
我需要找出为什么第一个数据包花费的时间太长，以及如何解决它。
编辑：使用 pcap 进一步分析表明发送程序正在以正确的间隔发送数据包。问题肯定出在接收方，它使用 select() 等待可读套接字，然后调用 recvfrom 并打印数据包。是否存在某种我可能不知道的缓冲？
I have noticed that when I am sending packets at even intervals from a udp socket, the first packet sent seems to be delayed. For example, if I am sending the packets every 100 ms, I find the delay between receiving the packets to be normally distributed with mean 100ms and average standard deviation of 4, on my network. However, the gap between the receive time for the first and second packets is usually around 10 to 40 ms - as you can see, that's clearly a statistically significant difference, and so my question is, what's causing it?
I'm using the sendto function from C on linux. Someone suggested the delay might be caused by arp resolution preventing the packet from being sent until the destination ip has been converted to a mac address - is this likely? If I restart the sending program the first packet again takes too long though, and the delay is inconsistent - 10 to 40 ms is a pretty big range.
I need to find out why this first packet is taking too long, and how to work around it.
Edit: Further analysis with pcap indicates that the sending program is sending the packets at the right interval. Problem must be with the receiver, which is using select() to wait for a readable socket, then calling recvfrom and printing the packet. Is there some sort of buffering going on there I might not know about?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这很可能是 ARP 地址解析所需的时间。这是将 MAC 地址解析为 IP 地址的协议。
要解决此问题，请尝试通过
arp -s ip-address hw_address使用 arp 缓存中的静态条目。It is most likely the time required for the ARP address resolution. This is the protocol which resolves MAC addresses to IP addresses.
For working around this, try using static entries in the arp cache with
arp -s ip-address hw_address.猜测不会让我们有任何结果，启动Wireshark，它会告诉你所有你需要知道的。
Speculation will get us nowhere, fire up Wireshark and it will tell you all you need to know.
您已询问解决方法。如果需要了解数据包的接收时间，一种可能的解决方法是设置
SO_TIMESTAMP套接字选项。这将允许您获取目标内核接收每个数据包的时间 - 然后您可以在后续处理中使用该时间而不是“当前时间”。或者，您可以让发送方在其发送的数据包中包含高分辨率时间戳，并使用它们。
You have asked about workarounds. One possible workaround, if the reception time of the packet is important to know, is to set the
SO_TIMESTAMPsocket option. This will allow you to obtain the time that each packet was received by the destination kernel - you can then use this time in subsequent processing rather than the "current time".Alternatively, you could have the sender include a high resolution timestamp in the packet that it sends, and use those.
这是在单个 LAN 上吗？如果是这样，（可能）取决于 ARP 和/或主机名解析。如果它跨越更大的网络，它可能是任何东西（尽管可能与路由查找和缓存填充有关）。
Is this on a single LAN? If so, it is (probably) down to ARP and/or hostname resolution. If it's across a larger network, it may be anything (although probbaly related to route lookup and cache population).
我没有足够的“声誉”来投票选出我认为最好的解决方案，所以我只想说提到 ARP 消息的人很可能是对的。我认为 ARP 消息应该只适用于 LAN。他们将在 Wireshark 上显示为“谁拥有 192.168.0.24？”例如...然后任何声称拥有该 IP 地址的主机都会收到回复。通过 UDP 发送到该地址的初始数据包必须获得 ARP 响应，以将 IP 地址解析为以太网 MAC 地址...因此 UDP，表面上似乎永远不应该阻塞...但这仅是一次ARP地址已解析。我不确定，但我认为如果您将 UDP 发送到不在 LAN 上的地址，则不需要 ARP...除非找到主网关时出现问题。
I don't have enough "reputation" to vote up what I consider to be the best solution, so I'll just say that the guy who mentions ARP messages is most-likely right. I think the ARP messages should only apply on the lan. They'll show up on wireshark as a "who has 192.168.0.24?" for example... and then there will be a reply from any host that claims to have that IP address. The initial packet send via UDP to this address has to get an ARP response to resolve the IP address into an Ethernet MAC address... so UDP, on the surface may seem like it should never BLOCK... however this is only true once the ARP address is resolved. I'm not sure, but I think if you're sending UDP to an address that is not on the LAN, it shouldn't require an ARP... unless there's a problem finding the primary gateway.