ss -ltn 中 LISTEN 状态下 Recv-Q 表示已完成三次握手但未被 accept() 取走的连接数，Send-Q 表示内核允许的最大 accept 队列长度；Recv-Q 持续 > 0 或接近 Send-Q 说明应用 accept 过慢或队列已满，可能导致连接丢弃和客户端超时。
用 ss -ltn 就能直接看到 TCP 监听套接字的连接请求队列状态，关键看 Recv-Q 和 Send-Q 两列。
监听状态下 Recv-Q 和 Send-Q 的真实含义
在 ss -ltn 输出中，State 为 LISTEN 的行里：
-
Recv-Q：表示已完成三次握手、但还没被应用调用
accept()取走的连接数（即 accept 队列中积压的已建立连接） -
Send-Q：不是发送缓冲区，而是该监听套接字允许的最大 accept 队列长度（即 socket 创建时传入的
backlog参数上限）
如何快速识别队列异常
重点关注 Recv-Q 是否持续不为 0 或接近 Send-Q：
- Recv-Q 长期 > 0：说明应用 accept 太慢，新连接在内核队列里排队，可能触发丢包或超时重传
- Recv-Q 接近甚至等于 Send-Q：accept 队列已满，后续完成三次握手的连接会被内核丢弃（表现为客户端 SYN-ACK 后无响应）
- 若 Send-Q 值很小（如 1、8、16），可能是服务启动时未显式设置 backlog，建议检查应用代码或 systemd 服务配置中的
ListenStream或SO_BACKLOG设置
带进程信息的完整查看方式
加 -p 参数可定位具体服务：
-
sudo ss -ltnp | grep ':80'— 查看 80 端口监听及对应进程 -
sudo ss -ltnp | awk '$4 ~ /:22$/ {print $0}'— 精确匹配 SSH 端口 - 注意：需 root 权限才能显示进程名和 PID，否则会提示 “Permission denied”
对比 netstat 的等效命令
虽然 netstat -tln 也能看监听状态，但：
- ss 更轻量、输出更准确，尤其在高并发场景下不会因 /proc/net/tcp 解析延迟而卡顿
- netstat 的 Recv-Q/Send-Q 列含义与 ss 一致，但部分旧版本对 backlog 解释不够明确
- 推荐统一使用 ss，避免因工具差异造成误判
