recv-q和send-q数值需结合连接状态判断：listen时，recv-q为半连接数、send-q为全连接队列上限；established时，recv-q为待读字节数、send-q为未确认字节数。
直接看 Recv-Q 和 Send-Q 的数值及其对应连接状态，就能快速判断积压发生在哪一环——是内核收不进来、应用读不动，还是对方回不来 ACK。
区分 LISTEN 与 ESTABLISHED 状态下的队列含义
同一列数字，在不同状态下代表完全不同的问题：
- LISTEN 状态下：Recv-Q 是半连接队列（SYN_RECV）数量，反映三次握手第一阶段是否堆积；Send-Q 是全连接队列（已完成三次握手、等待 accept()）长度，体现应用层取连接的速度。
- ESTABLISHED 状态下：Recv-Q 表示内核已收到但应用还没 read() 的字节数；Send-Q 表示应用已 send() 但对方尚未 ACK 的字节数，本质是未确认的 TCP 发送窗口数据。
Recv-Q 持续偏高说明什么
分两种情况看：
- LISTEN 行 Recv-Q 长期大于 0：可能遭遇 SYN Flood 攻击，或 net.ipv4.tcp_max_syn_backlog 设置过小，导致合法 SYN 包被丢弃。
- ESTABLISHED 行 Recv-Q 稳定在几百至几 KB：常见于应用读取慢，比如 Java 进程 CPU 占满、线程阻塞、反序列化耗时长；也可能是 SO_RCVBUF 缓冲区太小，突发流量直接打满接收队列。
Send-Q 长时间不归零的典型原因
这个值升高，说明数据发出去了但没被对方确认：
- 对方网络质量差或丢包严重，ACK 回不来，TCP 重传机制持续触发；可用 tcpdump 抓包验证是否有重复 ACK 或超时重传。
- 本端应用调用 send() 过快，而 TCP 窗口受限（如对方接收缓冲区满、带宽低），导致数据卡在本地发送队列；此时常伴随高吞吐但低有效吞吐现象。
- 对方进程崩溃或未读取 socket，连接实际已“假死”，但 TCP 层尚未检测到 RST/FIN，Send-Q 就会缓慢增长直至超时断连。
配合其他命令交叉验证
单靠 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 -w sendq.pcap抓包后分析 RTT、窗口缩放、重复 ACK 等指标。
