ss比netstat更可靠，因其直接读取内核socket数据、毫秒级响应；需用ss -s看全局连接分布，ss -ltn查监听队列积压，ss -tini盯ESTAB缓冲区，ss -tulpn-m关联进程与内存占用。
在高并发场景下，ss 是比 netstat 更可靠的选择——它直接读取内核 socket 数据，不遍历 /proc，毫秒级响应，且能暴露关键性能指标。重点不是“看到连接”，而是快速识别瓶颈位置。
看全局压力：用 -s 快速掌握连接分布
执行 ss -s 一行输出就能了解整体套接字负载：
- 显示 ESTAB（已建立）、TIME-WAIT、LISTEN 等状态的连接数，判断是否大量连接堆积在某个状态
- 关注 TCP: xxx (estab N, ...) 中的 estab 值，这是真实活跃连接数；若远低于预期，可能连接未成功建立或被中间设备拦截
- 留意 ports N，表示当前分配的端口范围使用情况，接近上限时可能触发端口耗尽
查监听队列积压：-ltn 是诊断服务吞吐的第一步
运行 ss -ltn 查看所有 TCP 监听端口及其队列：
- Recv-Q 列对 LISTEN 状态表示 已完成三次握手但尚未被 accept() 取走的连接数
- Send-Q 列是该监听套接字的 backlog 上限（即 listen() 调用传入的第二个参数）
- 若某行 Recv-Q 长期 > 0（尤其接近 Send-Q），说明应用 accept 速度跟不上，新连接在内核队列中排队，严重时会导致 SYN 丢包或连接超时
盯 ESTAB 连接缓冲：定位读写瓶颈的核心字段
执行 ss -tini | grep ESTAB，重点关注 Recv-Q 和 Send-Q 在已建立连接中的含义：
- Recv-Q 持续 > 0：说明对端发来的数据已在内核接收缓冲区，但本端应用还没调用 read()/recv() 取走——应用读取慢或阻塞
- Send-Q 持续偏大（如 > 数 KB）：说明本端已 send() 的数据尚未被对端 ACK——可能是 网络延迟高、丢包、对端处理慢，或本端发包过猛
- 配合 -i 参数还能看到 retrans（重传次数）、rto（重传超时）、rtt（往返时延），重传率升高是网络或对端异常的强信号
快速关联进程与内存：-tulpn + -m 定位归属与资源占用
组合命令 ss -tulpn 可立即看到端口归属进程（需 root 权限才显示全部）；加 -m 则补充内存细节：
- rmem_alloc / wmem_alloc 显示当前实际占用的接收/发送缓冲区内存
- 若 rmem_alloc 接近 rmem_max，说明接收缓冲区打满，可能触发窗口收缩，限制吞吐
- 结合 PID 快速进入对应进程，检查其线程模型、I/O 调度或日志，避免在错误服务上排查
