ESTABLISHED状态的TCP连接数最直接反映真实并发量，因其代表正在双向传输数据的活跃连接；其他状态如TIME_WAIT、LISTEN等均不体现当前业务负载。
并发量最直接的指标就是 ESTABLISHED 状态的 TCP 连接数，不是进程数、不是请求数、也不是 TIME_WAIT 数——它代表正在双向传输数据的真实活跃连接。
为什么只看 ESTABLISHED 才算真实并发
Web 服务（Nginx/Apache）的并发压力，本质是同时有多少客户端在收发数据。其他状态意义不同：
-
LISTEN：只是端口开着等连接，不消耗实际带宽或业务资源 -
TIME_WAIT：连接已关闭，只是内核在等 2MSL 超时，短连接多时必然高，但不反映当前负载 -
SYN_RECV长期 >10 说明握手卡住，可能是攻击或后端响应慢，属于异常信号，不是“并发” -
CLOSE_WAIT持续增长大概率是服务端没主动关连接，属于 bug 或配置缺陷，需排查 keepalive timeout 或应用逻辑
所以监控面板或告警阈值，必须盯死 ESTABLISHED 值。它和 Nginx 的 active connections、Apache 的 requests currently being processed 最接近。
ss -ant | grep ESTABLISHED | wc -l 是首选命令
ss 比 netstat 更快、更轻量，现代系统默认自带，无需额外安装。它直接读取内核 socket 表，无解析开销：
- 用
-a显示所有套接字，-n禁用域名解析，-t限定 TCP —— 组合起来就是最小必要集 - 避免用
ss -s：它只给汇总（如tcp: 2125），但不区分状态，无法提取ESTABLISHED精确值 - 别漏掉
grep -w ESTABLISHED中的-w：防止匹配到ESTABLISHED_TIME_WAIT这类不存在但可能被误捕的字符串（虽然极少见，但加了更稳）
示例：
ss -ant | grep -w ESTABLISHED | wc -l
按端口过滤时注意单词边界和协议类型
查 Web 并发不能只跑全量，要锁定 80/443 或自定义监听端口，否则会混入数据库、后台服务等干扰连接：
- 正确写法：
ss -ant | grep ':443\b' | grep -w ESTABLISHED | wc -l——\b确保只匹配:443，不命中:4430或:4431 - HTTPS 流量走 TCP，所以用
-t；如果服务还开了 UDP 监听（如 QUIC），ss -anu单独查，但常规 HTTP/HTTPS 并发不涉及 UDP - 若服务监听在非标准端口（如
8080），grep ':8080\b'必须同步改，不能沿用旧脚本硬编码 - 权限问题：普通用户执行
ss -tulp（带-p查进程）会因无权读/proc而报错或空白，但计数类命令（不带-p）完全不需要 root
实时观察波动比单次快照更有价值
并发是动态值，秒级突增或缓慢爬升代表不同问题：
- 用
watch -n 0.5 "ss -ant | grep -w ESTABLISHED | wc -l"每半秒刷新一次，能快速识别毛刺或阶梯式上涨 - 别用
watch -n 1查高并发服务：0.5 秒延迟更利于捕捉瞬时峰值（比如压测中ESTABLISHED在 1200–1800 之间跳变） - 长期监控建议导出到 Prometheus + Grafana：用
node_netstat_Tcp_CurrEstab指标（来自 node_exporter），比轮询命令更稳定、可聚合
真正容易被忽略的是：并发数本身没有绝对安全阈值。1000 个 ESTABLISHED 对 Nginx worker event 模式很轻松，对 Apache prefork 模式可能已打满 MaxRequestWorkers。得结合你用的服务模型、worker 数量、keepalive 设置一起看，光盯一个数字会误判。
