ss是Linux查看网络连接的首选工具，直接读取内核socket数据，5万连接仅需0.3秒，远快于netstat的15秒；ss -s可统计ESTAB、TIME-WAIT等状态数，-tunap能定位进程与端口，-o/-m可分析计时器和内存占用，结合watch实时监控异常状态。
直接用 ss 配合关键选项，就能快速掌握应用的网络连接状态、并发量和潜在瓶颈。它不依赖外部服务，数据来自内核第一手信息，比 netstat 快得多，也比抓包更轻量。
查清连接数量与状态分布
运行 ss -s 可以立刻看到全局 socket 统计概要，比如 ESTAB（已建立）、TIME-WAIT、LISTEN 等各状态连接数。这对判断是否遭遇连接耗尽、TIME-WAIT 泛滥或监听端口未生效非常直观。例如输出中 tcp: 行显示 8524716 (ESTAB)，说明当前有八百多万活跃连接——这已经远超常规配置，需立即排查应用逻辑或 ulimit 限制。
定位具体进程与端口行为
加 -tunap 组合可列出所有 TCP 连接及其归属进程（需 root）：
-
sudo ss -tunap | grep :8080查看某端口（如 8080）上所有连接及对应 PID/程序名 -
sudo ss -tunap sport = :3306筛出本机发起的 MySQL 连接（源端口 3306） -
sudo ss -tunap dst 192.168.1.100:443追踪到特定后端的 HTTPS 连接
结合 watch -n 1 实时刷新，能观察连接数突增、异常 CLOSE_WAIT 堆积或 FIN_WAIT2 滞留，这些往往是应用未正确关闭 socket 或对方异常断连的信号。
识别高负载连接与资源占用
用 -o 和 -m 选项深入单条连接：
-
sudo ss -tunapo显示每个连接的计时器状态（如 retrans、rto），重传次数多可能意味着丢包或对端响应慢 -
sudo ss -tunapm显示 socket 内存使用（如rmem:262144），若某连接持续占用大量接收缓冲区，可能是应用读取不及时导致队列堆积
再配合 lsof -p $PID -i 或 cat /proc/$PID/fd/ | grep socket，可确认该进程打开的 socket 数量与地址，验证是否存在连接泄漏。
关联 I/O 与系统级瓶颈
socket 性能问题常不是孤立的。当发现大量连接处于 SYN-RECV 或 LAST-ACK 状态时，要同步检查：
- CPU：用
vmstat 1看wa（I/O 等待）是否持续偏高 - 内存：用
free -h和cat /proc/meminfo | grep -i "memavailable\|oom"排查内存压力是否触发了 socket 缓冲区回收 - 网卡：用
ethtool -S eth0 | grep -i "drop\|error"查收发丢包或错误帧
如果 ss 显示连接正常但应用响应慢，问题很可能不在 socket 层本身，而是后端服务延迟、磁盘 I/O 或锁竞争所致。
