Recv-Q和Send-Q含义取决于TCP连接状态：LISTEN时Recv-Q为半连接数、Send-Q为全连接队列积压数；ESTABLISHED时Recv-Q为未读字节数、Send-Q为未确认字节数，误判状态将导致错误诊断。
netstat 输出里的 Recv-Q 和 Send-Q 不是固定含义的“队列长度”，而是取决于连接所处的状态——尤其是 LISTEN 还是 ESTABLISHED。看错状态，就容易误判问题根源。
Recv-Q：接收方缓冲区里“还没被程序拿走”的数据
对已建立连接（ESTABLISHED）：Recv-Q 表示内核已成功接收、但应用程序尚未调用 recv() 或 read() 读取的字节数。数值持续偏高，说明应用消费能力不足，比如 Java 服务 GC 频繁、线程阻塞或逻辑卡在数据库查询上。
- 若 Recv-Q 稳定在几百字节以内，属正常抖动
- 若长期大于几 KB（如 >5 KB），需检查应用是否卡住、CPU 是否过载、是否有反向代理未及时转发
- 在 LISTEN 状态下，Recv-Q 实际表示 SYN 半连接队列中未完成三次握手的请求数，过高可能遭遇 SYN Flood 攻击或内核参数 net.ipv4.tcp_max_syn_backlog 设置过小
Send-Q：发送方缓冲区里“对方还没确认收到”的数据
对已建立连接（ESTABLISHED）：Send-Q 是已交给 TCP 协议栈、但尚未收到对端 ACK 确认的数据字节数。它反映的是网络传输延迟或对端接收能力瓶颈。
- 短暂非零（如几百字节）常见于突发写入，无需干预
- 若 Send-Q 持续增长（如 >10 KB），可能是：对端处理慢（如客户端卡死、网络丢包）、本端发得太猛（未做流控）、中间链路拥塞（可结合 ping、mtr、tcpretrans 观察）
- 在 LISTEN 状态下，Send-Q 表示 已完成三次握手、但尚未被 accept() 取走的全连接数，即 backlog 队列积压量；持续不为 0，说明应用调用 accept() 太慢，或连接并发远超服务承载能力
快速定位异常的实操建议
执行 netstat -antp | grep :端口号 后，重点关注三类现象：
- 大量 ESTABLISHED 连接 Recv-Q > 0 且稳定不降 → 应用层读取阻塞，优先查进程堆栈（jstack / strace）
- LISTEN 行 Recv-Q 显著大于 0（如 >10）→ 半连接堆积，检查是否遭受攻击或 net.ipv4.tcp_syncookies 是否关闭
- LISTEN 行 Send-Q 长期 > 0 → 全连接堆积，检查服务 accept 线程是否耗尽、连接超时设置是否过长、是否存在连接泄漏
别被 man 手册带偏的小提醒
Linux 官方 man page 对 LISTEN 状态下 Send-Q 的描述存在长期错误：它说 Send-Q 是“半连接队列容量”，实际是“全连接队列当前积压数”。这一差异在排查连接拒绝（Connection refused）或大量 CLOSE_WAIT 时尤为关键——务必以内核源码行为和实测为准，而非文档字面。
