直接看recv-q和send-q数值并结合listen或established状态，可快速定位积压环节：listen时recv-q为半连接数、send-q为全连接队列上限；established时recv-q为待读字节数、send-q为未确认字节数。
直接看 Recv-Q 和 Send-Q 两列数值，再结合连接状态（LISTEN 或 ESTABLISHED），就能快速定位队列积压发生在哪一环——是内核收不进来、应用读不动，还是对方回不来 ACK。
LISTEN 状态下的队列含义要分清
监听端口行里，这两列代表的是 TCP 连接建立阶段的两个关键队列：
-
Recv-Q 是当前半连接队列（SYN_RECV）中的请求数，反映三次握手第一阶段是否堆积；长期大于 0，可能遭遇 SYN Flood 攻击，或
net.ipv4.tcp_max_syn_backlog设置过小。 -
Send-Q 是全连接队列（已完成三次握手、等待
accept()）的最大长度，不是当前积压数；它体现的是应用层取连接的能力上限，值偏小会导致新连接被丢弃。
ESTABLISHED 状态下看真实积压
已建立连接行里，这两列反映的是数据传输阶段的缓冲区状态：
-
Recv-Q 表示内核已收到、但应用进程还没调用
read()取走的字节数；持续几百 KB 以上，常见于 Java 进程 CPU 满载、线程阻塞、反序列化慢，或SO_RCVBUF设置过小。 -
Send-Q 表示应用已调用
send()、但对方尚未 ACK 的字节数；长时间不归零，说明数据发出去了却没确认，可能是对方网络丢包、接收窗口满、进程崩溃未读，或本端发送过快而带宽/窗口受限。
配合其他命令交叉验证才可靠
单靠 netstat 数值容易误判，需联动排查：
- 用
ss -lnt查 listen 端口的qlen（当前全连接队列长度）和opt（最大长度），比 netstat 更直观。 - 查内核计数器：
cat /proc/net/snmp | grep Tcp关注TcpExtListenOverflows和TcpExtListenDrops，确认是否有真实丢包。 - 查应用状态：
top -p $(pgrep -f your_app)看 CPU/内存，再结合日志查线程池满、处理超时等线索。 - 对高 Send-Q 连接，用
tcpdump -i any port XXXX抓包分析 RTT、重复 ACK、重传行为。
快速筛查积压连接的小技巧
用一行命令筛出异常队列：
- 查所有 Recv-Q 或 Send-Q 超过 100 字节的连接：
netstat -antup | awk '$2 > 100 || $3 > 100 {print}' - 只看监听端口队列情况：
netstat -tunlp | grep LISTEN - 统计各状态连接数：
netstat -ant | awk '{print $6}' | sort | uniq -c
