必须用getsockopt系统调用获取：getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &val, &len)返回当前生效值，该值是内核实际分配的字节数（通常为设置值的2倍且不低于最小值），而非初始默认值或sysctl配置值。
用 getsockopt 查单个 socket 的实时缓冲区大小
程序运行中，某个具体 socket 的 SO_RCVBUF 和 SO_SNDBUF 值，必须用系统调用获取，不能靠查 /proc 或 sysctl 推断。因为：这些值在 socket() 创建后由内核按默认值初始化，但后续可能被 setsockopt() 修改过，也可能被内核自动倍增（Linux 会预留管理开销，实际分配空间 ≈ 请求值 × 2）。
关键点：
-
getsockopt(fd, SOL_SOCKET, SO_RCVBUF, &val, &len)返回的是当前生效值，不是初始默认值 - 必须在 socket 已创建、且未关闭前调用，否则
EBADF - 返回的
val是内核实际分配的字节数，可能比你setsockopt时传入的值大
示例片段（C）：
int rcvbuf = 0, sndbuf = 0;
socklen_t len = sizeof(rcvbuf);
if (getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, &len) == 0) {
printf("SO_RCVBUF: %d\n", rcvbuf);
}
if (getsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &sndbuf, &len) == 0) {
printf("SO_SNDBUF: %d\n", sndbuf);
}
用 netstat -tulpn 看进程级缓冲区队列长度
netstat 不显示缓冲区大小配置，但能反映当前 socket 接收/发送队列里堆积了多少字节数据 —— 即 Recv-Q 和 Send-Q 列。这个值是动态的，代表尚未被应用读走或尚未发出去的字节数。
常见误判场景：
-
Recv-Q持续 > 0：说明应用读太慢，或缓冲区太小导致丢包前就积压了 -
Send-Q非零且不下降：可能是对端接收窗口卡住、网络拥塞，或本端发送缓冲区满但应用没检查send()返回值 - UDP socket 的
Recv-Q非零，往往意味着已收到但未被recvfrom()取走的数据报，容易被新包覆盖丢弃
命令示例：
netstat -tulpn | grep :8080 # 输出类似：tcp 12416 0 127.0.0.1:8080 0.0.0.0:* LISTEN 12345/nginx # 其中 12416 就是当前 Recv-Q 字节数
用 ioctl 查 socket 当前已缓存的数据量（非配置值）
如果想确认“此刻这个 socket 的接收缓冲区里到底还剩多少字节没读”，getsockopt(..., SO_RCVBUF, ...) 给的是容量上限，而 ioctl(fd, SIOCINQ, &len) 才返回真实待读字节数。这对调试阻塞/超时逻辑特别有用。
注意区别：
-
SIOCINQ（也叫FIONREAD）：返回接收队列中**已到达、未读取**的字节数（TCP）或数据报个数（UDP） -
SIOCOUTQ：返回发送队列中**已写入但未发出**的字节数（仅 TCP；UDP 不适用，因无重传队列） - 这两个 ioctl 不改变 socket 状态，也不需要特权
示例（C）：
unsigned long inq = 0;
if (ioctl(sockfd, SIOCINQ, &inq) == 0) {
printf("Bytes ready to recv: %lu\n", inq);
}
为什么不能只看 /proc/sys/net/core/rmem_default？
这个文件只控制新 socket 的初始 SO_RCVBUF 值，但它会被多层覆盖：
- TCP socket 还受
/proc/sys/net/ipv4/tcp_rmem中的中间值影响（即“默认值”字段），该值优先级高于rmem_default - UDP socket 才真正用
rmem_default，但一旦调用setsockopt(fd, SOL_SOCKET, SO_RCVBUF, ...)，就彻底脱离系统默认 - 即使没显式设置，某些库（如 glibc 的
getaddrinfo创建的 socket）或框架（如 nginx、redis）也会在内部调用setsockopt覆盖默认值
所以，查系统参数只能知道“如果什么都不做，新 socket 会是多少”，不能代替对具体 fd 的实测。
