ss -s 输出中 total 是用户态可见的活跃 socket 数，kernel 值是内核管理的 socket 结构体总数（含半连接、close_wait 等），二者差值持续增大表明存在 socket 泄漏或回收异常。
ss -s 输出的各字段到底代表什么
执行 ss -s 后看到的汇总行（如 Total: 1234 (kernel 5678)）不是简单计数，而是内核 socket 子系统当前维护的各类状态统计。其中 Total: 是用户态可见的 socket 数量（即已绑定、已连接、监听中等处于“活跃生命周期”的 socket），而括号里的 kernel 值是内核内部实际管理的 socket 结构体总数——包括那些尚未完成三次握手的半连接（SYN_RECV）、已关闭但未彻底释放的 CLOSE_WAIT、以及某些协议栈内部暂存的控制块。
常见误解是认为两个数字应该一致。实际上只要 kernel 明显大于 Total（比如差值持续增长），就说明有 socket 卡在内核内部未被上层回收，典型原因包括：应用未调用 close()、文件描述符泄漏、或 TIME_WAIT 过多但未被快速复用。
如何用 ss -s 快速识别连接堆积问题
ss -s 最实用的不是第一行总数，而是下面按状态分类的统计，例如：
TCP: 120 (estab 89, closed 12, orphaned 3, synrecv 0, timewait 16/0, portalloc 0)
重点关注这些字段：
-
estab：当前 ESTABLISHED 连接数，突增可能意味着业务请求激增或下游服务响应变慢 -
timewait左侧数字（如16）是当前 TIME_WAIT 状态 socket 数；右侧（如0）是该状态中已被快速回收（net.ipv4.tcp_tw_reuse=1生效时）的数量 -
orphaned：无对应文件描述符的 TCP socket（即进程已退出但连接尚未关闭），>0 就说明存在连接泄漏或进程异常终止 -
synrecv：停留在 SYN_RECV 的连接数，持续 >0 可能是 SYN Flood 攻击或后端 accept 队列溢出（net.core.somaxconn不足）
ss -s 和 netstat -s 的关键区别在哪
ss -s 统计来自内核 socket 子系统的实时快照，开销极低，适合高频巡检；而 netstat -s 解析的是 /proc/net/snmp 和 /proc/net/netstat 中的累积计数器（如重传次数、连接失败数），反映的是自启动以来的协议栈行为总览。
两者不替代，而是互补：
- 查“现在有多少连接卡住” → 用
ss -s - 查“最近是否频繁重传或拒绝连接” → 用
netstat -s | grep -A 5 'Tcp:' -
ss -s不显示错误类型细节（比如 RST 数、超时数），这类指标只能从netstat -s或/proc/net/snmp里找
为什么 ss -s 显示的总数有时和 lsof -i | wc -l 差很多
根本原因是统计维度不同：lsof -i 列出的是所有进程打开的网络文件描述符（FD），一个进程可能打开多个 socket，也可能 fork 后子进程继承了 FD 但没关闭；而 ss -s 统计的是内核 socket 对象数量，且会去重（如 UDP socket 多播组成员关系不重复计数）。
更关键的是：lsof -i 默认只显示非 root 用户可读的 FD（受权限限制），而 ss -s 总是返回内核真实值。如果用 sudo lsof -i | wc -l，结果仍可能偏高，因为：
- 同一个 socket 被多个进程通过
dup()共享时，lsof会为每个 FD 行单独计数 -
lsof无法过滤掉已 close() 但仍在等待 FIN-ACK 的 socket（它们还在内核中，ss -s会计入） - 某些内核模块创建的 socket（如 iptables conntrack helper）不会出现在
lsof中
所以当发现两者差异大，优先信 ss -s 的总数，再用 ss -tuln 或 ss -tan state time-wait | head -20 定位具体 socket 归属。
