直接查看/proc/sys/net/core/和/proc/sys/net/ipv4/下对应文件即可获取所有关键缓冲区数值：core/rmem_default等为全局默认值，影响未显式调用setsockopt的套接字；core/rmem_max是so_rcvbuf设置的硬上限，超限会被静默截断；tcp_rmem/wmem为tcp专用三元组（min default max），仅约束内核自动调优范围，不干预so_rcvbuf设置。
直接看 /proc/sys/net/core/ 和 /proc/sys/net/ipv4/ 下的对应文件，就能拿到所有关键缓冲区数值——不需要写代码、不依赖进程状态，系统级配置一目了然。
查系统级默认与最大值：/proc/sys/net/core/rmem_default 等
这些是内核为所有 socket 设置的全局基准值，影响未显式调用 setsockopt 的套接字：
-
/proc/sys/net/core/rmem_default：UDP 和 TCP（未启用自动调优时）的接收缓冲区默认大小（字节） -
/proc/sys/net/core/wmem_default：对应发送缓冲区默认大小 -
/proc/sys/net/core/rmem_max：应用层通过SO_RCVBUF能设置的最大值（注意：内核实际分配可能翻倍） -
/proc/sys/net/core/wmem_max：同上，对应发送方向
执行 cat /proc/sys/net/core/rmem_max 就能立刻看到当前上限。这个值若太小，setsockopt(..., SO_RCVBUF, ...) 会被静默截断，不是报错而是“默默变小”。
查 TCP 协议栈专用三元组：/proc/sys/net/ipv4/tcp_rmem
TCP 的缓冲区策略更复杂，由三个整数控制（空格分隔），顺序是：min default max：
-
cat /proc/sys/net/ipv4/tcp_rmem输出类似4096 131072 6291456，表示接收方向最小 4KB、默认 128KB、最大 6MB -
tcp_wmem同理，但发送方向的default值通常比rmem_default小，避免压垮对端 - 这个三元组只对 TCP 生效；UDP 不走这套逻辑，只认
core/rmem_default
注意：tcp_rmem 的 max 不限制 SO_RCVBUF 设置——它只约束内核自动调优时的上限。真正卡死的是 core/rmem_max。
查运行中某个 socket 的实际值：getsockopt 获取 SO_RCVBUF
如果已知进程 PID 和 socket fd（比如从 ss -tulpn 或 lsof -i 找到），必须进进程上下文才能读取其当前缓冲区大小：
- 用 C 写个小程序调用
getsockopt(fd, SOL_SOCKET, SO_RCVBUF, &val, &len) - 或用
gdbattach 进程，在内存里读该 socket 结构体的sk_rcvbuf字段（不推荐，易出错） - 没有现成命令能直接打印某 fd 的缓冲区值——
ss和netstat只显示Recv-Q/Send-Q（队列积压字节数），不是缓冲区容量
常见误区：以为 ss -m 或 ss -i 能显示缓冲区大小。它们只显示内存页统计和拥塞控制信息，不暴露 SO_RCVBUF 值。
为什么 setsockopt 设置后 getsockopt 返回值翻倍？
Linux 内核会把用户传入的 SO_RCVBUF 值乘以 2 存储，因为要预留额外空间管理 sk_buff 链表头、元数据等：
- 你传
65536，getsockopt返回131072是正常行为，不是 bug - 这个翻倍仅发生在
SOL_SOCKET层；tcp_rmem里的数值是原始值，不翻倍 - 所以比较时要注意：用
core/rmem_max对比你传的原始值，而不是对比getsockopt返回值
最易被忽略的一点：修改 /proc/sys/net/core/rmem_max 后，旧进程不会自动继承新值——只有新创建的 socket 才生效。调试时别在改完 sysctl 后立刻去测老进程的 fd。
