UDP sendto() 何时阻塞？
在 UDP 套接字上使用默认（阻塞）行为时，在这种情况下对 sendto() 的调用会阻塞吗？我主要对 Linux 行为感兴趣。
对于 TCP，我知道如果发送窗口已满，拥塞控制会使 send() 调用阻塞，但是 UDP 呢？它有时会阻塞或者只是让数据包在较低层被丢弃吗？
While using the default (blocking) behavior on an UDP socket, in which case will a call to sendto() block? I'm interested essentially in the Linux behavior.
For TCP I understand that congestion control makes the send() call blocking if the sending window is full, but what about UDP? Does it even block sometimes or just let packets getting discarded at lower layers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您填满了套接字缓冲区，则可能会发生这种情况，但它高度依赖于操作系统。由于 UDP 不提供任何保证，当您的套接字缓冲区已满时，您的操作系统可以决定执行任何操作：阻止或删除。您可以尝试增加SO_SNDBUF来暂时缓解。
这甚至可能取决于系统的微调，例如，它还可能取决于网络接口驱动程序中 TX 环的大小。 iperf 邮件列表，但您确实想与您操作系统的开发人员讨论这个问题。特别注意 O_NONBLOCK 和 EAGAIN / EWOULDBLOCK。
This can happen if you filled up your socket buffer, but it is highly operating system dependent. Since UDP does not provide any guarantee your operating system can decide to do whatever it wants when your socket buffer is full: block or drop. You can try to increase SO_SNDBUF for temporary relief.
This can even depend on the fine tuning of your system, for instance it can also depend on the size of the TX ring in the driver of your network interface. There are a few discussions about this in the iperf mailing list, but you really want to discuss this with the developers of your operating system. Pay special attention to O_NONBLOCK and EAGAIN / EWOULDBLOCK.
这可能是因为您的操作系统正在尝试执行 ARP 请求以获取远程主机的硬件地址。
基本上，每当数据包发出时，标头都需要远程主机的 IP 地址和远程主机的 MAC 地址（或到达它的第一个网关）。 192.168.1.34 和 AB:32:24:64:F3:21。
您的“阻止”行为可能是 ARP 正在运行。
我听说在旧版本的 Windows（我想是 2k）中，如果请求花费的时间太长并且发送的数据太多，第一个数据包有时会被丢弃。从那时起，一个服务包可能解决了这个问题。
This may be because your operating system is attempting to perform an ARP request in order to get the hardware address of the remote host.
Basically whenever a packet goes out, the header requires the IP address of the remote host and the MAC address of the remote host (or the first gateway to reach it). 192.168.1.34 and AB:32:24:64:F3:21.
Your "block" behavior could be that ARP is working.
I've heard in older versions of Windows (2k I think), that the 1st packet would sometimes get discarded if the request is taking too long and you're sending out too much data. A service pack probably fixed that since then.