如何获取 UDP 套接字的排队数据量？
为了了解我在处理传入数据方面的表现如何，我想测量 TCP 和 UDP 套接字的队列长度。
我知道我可以通过 SO_RCVBUF 套接字选项获取队列大小，并且 ioctl( 告诉我这些信息对于 TCP 套接字。但对于 UDP，SIOCINQ/FIONREAD ioctl 仅返回下一个待处理数据报的大小。有没有一种方法可以获取 UDP 队列大小，而无需解析 /proc/net/udp 等系统表？
To see how well I'm doing in processing incoming data, I'd like to measure the queue length at my TCP and UDP sockets.
I know that I can get the queue size via SO_RCVBUF socket option, and that ioctl(<sockfd>, SIOCINQ, &<some_int>) tells me the information for TCP sockets. But for UDP the SIOCINQ/FIONREAD ioctl returns only the size of next pending datagram. Is there a way how to get queue size for UDP, without having to parse system tables such as /proc/net/udp?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
FWIW，我做了一些实验来绘制
FIONREAD在不同平台上的行为。FIONREAD返回SOCK_DGRAM套接字中所有待处理数据的平台：平台，其中
FIONREAD仅返回第一个待处理数据报的字节：还值得注意的是，某些实现在计数中包括标头或其他开销字节，而其他实现仅计算有效负载字节。 Linux 似乎返回有效负载大小，不包括 IP 标头。
FWIW, I did some experiments to map out the behavior of
FIONREADon different platforms.Platforms where
FIONREADreturns all the data pending in aSOCK_DGRAMsocket:Platforms where
FIONREADreturns only the bytes for the first pending datagram:It might also be worth noting that some implementations include headers or other overhead bytes in the count, while others only count the payload bytes. Linux appears to return the payload size, not including IP headers.
正如 ldx 提到的，ioctl 或 getsockopt 不支持它。
在我看来，SIOCINQ 当前的实现旨在确定读取整个等待缓冲区需要多少缓冲区（但我想它对此没有那么有用，因为它可以在读取它与实际缓冲区之间发生变化）读）。
通过此类系统调用，还有许多其他遥测不受支持，我想在正常生产使用中没有真正的需要。
您可以通过“netstat -su”检查丢弃/错误，或者如果您只想监视机器状态，最好使用 SNMP (udpInErrors)。
顺便说一句：您始终可以选择侵入内核代码并添加此值（或其他值）。
As ldx mentioned, it is not supported through ioctl or getsockopt.
It seems to me that the current implementation of SIOCINQ was aimed to determine how much buffer is needed to read the entire waiting buffer (but I guess it is not so useful for that, as it can change between the read of it to the actual buffer read).
There are many other telemetries which are not supported though such system calls, I guess there is no real need in normal production usage.
You can check the drops/errors through "netstat -su" , or better using SNMP (udpInErrors) if you just want to monitor the machine state.
BTW: You always have the option to hack in the Kernel code and add this value (or others).