netstat虽不直接显示socket实时读写状态,但通过recv-q和send-q瞬时值可判断缓冲区堆积:recv-q高说明本端应用未及时读取,send-q高提示对端接收异常或网络问题;可用netstat -tn -c持续监控,或用ss -tni获取更精细队列信息。

netstat 本身不直接显示 Socket 的实时读写状态(如 Recv-Q / Send-Q 的动态变化),但它能显示当前连接的瞬时队列长度——这正是反映读写缓冲区堆积情况的关键指标。
Recv-Q 和 Send-Q 列数值,本质就是内核 socket 接收缓冲区和发送缓冲区中尚未被应用层读取或尚未被对端确认的数据字节数。数值持续偏高,往往意味着应用处理慢、网络拥塞或对端接收异常。
看懂 Recv-Q 和 Send-Q 的含义
-
Recv-Q:本地接收队列中的字节数
- TCP 连接中,若该值 > 0 且长期不归零,说明本端应用没及时调用
recv()/read(),数据在内核缓冲区积压 - 对于监听套接字(LISTEN),该列为 0(无意义)
- TCP 连接中,若该值 > 0 且长期不归零,说明本端应用没及时调用
-
Send-Q:本地发送队列中的字节数
- TCP 连接中,若该值 > 0 且稳定不降,常见原因包括:
- 对端接收窗口为 0(停等)
- 网络丢包导致重传未确认
- 本端应用写入过快,而底层未完成发送
- TCP 连接中,若该值 > 0 且稳定不降,常见原因包括:
注意:UDP 没有可靠传输机制,
Recv-Q表示已收到但尚未被应用读取的 UDP 数据报数量(不是字节数),Send-Q通常为 0(内核不缓存 UDP 发送)。
实时观察读写队列变化的方法
netstat 不支持“流式刷新”式监控,但可通过 -c(continuous)选项实现每秒自动重刷:
netstat -tn
显示所有 TCP 连接(含数字地址、端口),含 Recv-Q/Send-Q/State 列。
netstat -tn -c
每秒刷新一次,终端会滚动输出,便于肉眼观察某连接的 Recv-Q/Send-Q 是否持续增长或卡住。
✅ 提示:配合
grep筛选关键连接更高效,例如:netstat -tn -c | grep :8080—— 监控 8080 端口相关连接的队列波动。
更精准的替代方案:ss 命令
ss(socket statistics)比 netstat 更轻量、更贴近内核,且默认显示更精细的队列信息(包括 skmem 内存使用):
ss -tni
-
-t:TCP -
-n:数字格式 -
-i:显示 TCP 内部信息(含rto,rtt,qsize,pmtu,advmss,rcv_space,snd_wnd等) - 输出中
skmem:(r:<bytes>,d:<bytes>,t:<bytes>,w:<bytes>)</bytes></bytes></bytes></bytes>可反映接收/发送缓冲区实际占用与上限
若需持续监控:
watch -n 1 'ss -tni | head -20'
辅助判断:结合状态码看读写异常模式
| State | Recv-Q 高? | Send-Q 高? | 典型含义 |
|---|---|---|---|
| ESTABLISHED | ✅ 持续增长 | ❌ | 本端应用卡住,未读数据 |
| ESTABLISHED | ❌ | ✅ 持续增长 | 对端卡住或网络不通,ACK 未回 |
| CLOSE_WAIT | ✅ | ❌ | 本端未调用 close(),资源泄漏 |
| FIN_WAIT2 | ❌ | ✅ | 对端已关闭,本端迟迟不结束 |
⚠️ 注意:
CLOSE_WAIT高 +Recv-Q非零,是典型的“服务端忘记关闭连接”问题信号。
不复杂但容易忽略











