ss是比netstat更快更轻量的网络诊断工具，直接读取内核socket信息；常用组合如ss -tuln查监听端口、ss -tulnp显进程、ss -tn state established查已建立连接，并支持按端口、ip、状态等精准过滤及计时器分析。
ss 和 antp 是两类不同用途的工具，不能组合使用来分析 TCP 连接状态。“ss -antp”是标准用法，而“ANTP”并非 Linux 内置或主流网络诊断命令——它在权威文档、内核源码、主流发行版（如 RHEL、Ubuntu、Alpine）中均无对应实现。网上部分资料将“ANTP”误作命令，实为混淆或笔误，可能源自对“tcpdump”“nping”“hping”等工具的误写，或虚构工具名。
正确用 ss 分析关闭过程中的残留状态
TCP 关闭阶段的常见残留状态包括 CLOSE_WAIT、TIME_WAIT、FIN_WAIT_1/2、LAST_ACK。这些状态反映连接释放是否完成，需用 ss 精准过滤：
- 查所有关闭相关状态分布：
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr - 单独看 CLOSE_WAIT（通常表示服务端未调用 close）：
ss -ant state close-wait - 统计 TIME_WAIT 数量（判断端口复用压力）：
ss -tan state time-wait | wc -l - 带进程信息定位问题服务：
ss -antp state close-wait（需 root 权限）
为什么不能用 “ss -antp” 加 “ANTP”？
ss 命令本身不支持 “antp” 这一选项组合。“-a -t -n -p” 是四个独立合法选项，含义如下：
- -a：显示所有套接字（含监听与非监听）
- -t：仅 TCP 协议
- -n：以数字格式显示地址和端口（跳过 DNS 解析，提速防卡）
- -p：显示关联进程（需 root 或 CAP_NET_ADMIN）
不存在 “-antp” 作为一个整体参数；实际执行的是 ss -a -t -n -p。所谓 “ss -antp” 是 shell 参数合并写法，不是新命令。
替代方案：补充诊断关闭异常的深层指标
仅看状态数不够，还需结合连接行为判断是否异常：
- 加 -o 查超时信息：
ss -tano state time-wait | head -5，观察 timer 字段（如 on (14.220ms, 0ms）表示仍处于定时器管理中 - 加 -i 查重传与 RTT：
ss -tani state fin-wait-2，若 retrans 较高（如 >3），说明对端未响应 FIN，链路或对方应用异常 - 对比两端角色：CLOSE_WAIT 多 → 检查本机应用是否漏调 close()；TIME_WAIT 多 → 通常是本机主动断连（如 HTTP 客户端），而非服务端问题
排查典型关闭残留场景
发现某状态堆积时，按角色快速定位：
-
CLOSE_WAIT 长期存在：服务端 accept 后未 read+close，常见于 Python/Java 应用未正确释放 socket；用
lsof -i -n -p PID查该进程打开的未关闭连接 - FIN_WAIT_2 卡住：本机已发 FIN 并收到 ACK，但迟迟没收到对方 FIN；可能是客户端崩溃、NAT 超时断连，或防火墙静默丢包
-
TIME_WAIT 超过 60 秒：正常；若数量持续 >5000 且业务为短连接，应启用
net.ipv4.tcp_tw_reuse = 1（仅对 outbound 有效），并推动应用层复用连接
