应分状态统计tcp连接并观察队列水位：established突增需结合qps判断，time_wait持续过高提示短连接未复用，close_wait堆积表明应用未调close()，syn_recv异常可能因syn flood或accept队列满；recv-q/send-q长期>0反映读写阻塞；ss -s可快速获取全局概览。
直接用 netstat -an 或 ss -tun 看连接列表，只能得到快照，无法判断高并发下真实压力。要实时分析 TCP 连接状态分布和队列是否溢出，关键在于分状态统计 + 队列水位观察，而不是单纯数连接总数。
按状态分类统计活跃连接，识别异常堆积
高并发场景下，不同 TCP 状态反映不同问题：
- ESTABLISHED 数量突增，说明当前活跃会话多，需结合业务 QPS 判断是否合理
-
TIME_WAIT 持续 >5000 且不回落，大概率是服务端高频短连接+未启用
tcp_tw_reuse -
CLOSE_WAIT 大量堆积（如上百），代表应用层没调
close()，是代码泄漏信号 - SYN_RECV 明显高于平时，可能遭遇 SYN Flood，或后端 accept 队列满导致握手失败
推荐命令（无需 root，兼容性好）：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
输出类似：ESTABLISHED 128、TIME_WAIT 3942、CLOSE_WAIT 67
若系统已弃用 netstat（如 CentOS 8+），改用 ss（注意字段位置不同）：
ss -tn state all | awk '{print $1}' | sort | uniq -c
注意：ss 中状态在第 1 列（如 estab、time-wait），不是末尾；也可用 ss -s 快速看全局摘要。
检查接收/发送队列是否堆积，定位阻塞点
TCP 连接的 Recv-Q 和 Send-Q 是判断队列是否溢出的核心指标：
- Recv-Q 长期 >0（尤其 >10KB）：说明应用读取慢，数据在内核接收缓冲区积压，可能是业务逻辑卡顿或未设超时
- Send-Q 长期 >0：说明对端 ACK 回得慢或网络丢包，也可能是本端发得太猛而对方处理不过来
- 两者同时持续升高，往往意味着连接已“假活”——看似 ESTABLISHED，实则无法收发数据
实时观察命令：
watch -n 1 'ss -tni | grep -E "(estab|time-wait)" | head -10'
加 -i 可看到 rto、rtt、retrans、qsize 等细节；重点关注 rcv_q 和 snd_q 字段值。
快速筛查高队列连接：
ss -tn 'sport = :80 or dport = :80' | awk '$2 > 1024 || $3 > 1024 {print $0}'
（$2 是 Recv-Q，$3 是 Send-Q，单位字节）
关联进程与监听队列，确认 accept 能力瓶颈
当新连接建立失败（如 Nginx 报 accept() failed (24: Too many open files)），除了连接数，更要查：
-
监听 socket 的全连接队列（accept queue）是否溢出：
ss -lnt | grep ":80"，看Recv-Q列 —— 若长期非 0（如 >128），说明应用 accept() 不及时，连接在内核排队等待被取走 -
半连接队列（SYN queue）是否满：
netstat -s | grep -i "listen overflows"，出现递增即表示 SYN 包被丢弃 -
进程打开文件数限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 soft/hard limit 是否足够
用 ss -s 快速获取全局连接概览
ss -s 输出简洁有力，适合定时巡检：
Total: 12345 (kernel 12400)<br> TCP: 12000 (estab 11500, closed 200, orphaned 50, synrecv 10, timewait 300/0), ports 2000
重点看：
- estab vs closed 比例：若 closed 极少，说明连接释放慢
- orphaned：无用户态进程的孤儿连接，通常因进程崩溃未清理 socket
-
timewait 后的
/0：表示当前 TIME_WAIT 中可重用的数量（依赖tcp_tw_reuse） -
ports：当前已分配的本地端口数，接近
ip_local_port_range上限时会触发地址冲突
不复杂但容易忽略。
