ss命令中Recv-Q和Send-Q含义依连接状态而变：LISTEN时，Recv-Q为已完成三次握手待accept的连接数，Send-Q为全连接队列最大长度；ESTABLISHED时，Recv-Q为应用未读取的接收缓冲区字节数，Send-Q为未被对端ACK确认的发送缓冲区字节数。
ss 命令本身不直接显示“吞吐量”，但它能精准反映影响吞吐的关键缓冲区状态——即 Recv-Q 和 Send-Q 的实时积压情况。这两个字段分别代表接收端和发送端的未处理数据量，是判断网络或应用层瓶颈最直观的指标。
看监听端口的连接队列（服务接入能力）
运行：
ss -ltnp
重点关注 LISTEN 行中的两列：
- Recv-Q：当前等待被 accept() 的已完成三次握手的连接数（SYN queue 已完成部分）。持续 > 0 说明服务响应慢或并发处理能力不足；若长期接近 Send-Q 值，可能触发连接拒绝（如 "Connection refused"）
-
Send-Q：该监听套接字允许的最大连接等待队列长度（即内核参数
net.core.somaxconn或程序调用 listen() 时指定的 backlog）。值过小（如默认 128）在突发流量下易丢连接
示例输出：
LISTEN 5 128 *:8080 *:* users:(("java",pid=1234,fd=12))
→ 表明已有 5 个新连接排队等待 Java 进程 accept，队列上限为 128，尚有余量；但若持续为 120+，就需优化服务线程池或调大 somaxconn。
查已建立连接的数据缓冲区（实际传输压力）
运行：
ss -tunap | grep ESTAB
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
对每条 ESTABLISHED 连接，理解：
- Recv-Q：本机 TCP 接收缓冲区中、尚未被应用程序 read() 取走的数据字节数。值高（如持续数千字节以上）说明应用读取慢（I/O 阻塞、逻辑卡顿、GC 暂停等），数据在内核堆积
- Send-Q：本机 TCP 发送缓冲区中、尚未被对端 ACK 确认的数据字节数。值高常见于：对方接收窗口小、网络丢包重传、路径拥塞、或本端发送太快而对方处理不过来
例如：
ESTAB 0 32768 10.0.1.10:443 192.168.5.200:51234
→ 本地无积压（Recv-Q=0），但发送端积压 32KB，需结合 tcpping、ping -R 或 ip -s link 查链路质量，或用 ss -i 看 cwnd/ssthresh 判断是否进入拥塞控制。
结合内存与内部状态深入诊断
当基础 Q 值异常时，追加参数获取深层信息：
- ss -tunai：显示 TCP 内部信息，包括 cwnd（拥塞窗口）、ssthresh（慢启动阈值）、rtt/rttvar（往返时延）。cwnd 长期偏低（如 ≤ 10 MSS）常意味着频繁丢包或超时
-
ss -tunam：显示 socket 内存用量，含 rmem_alloc（已分配接收内存）、wmem_alloc（已分配发送内存）。若 rmem_alloc 接近
net.ipv4.tcp_rmem最大值，说明接收缓冲区已满，会丢包或触发流控 -
ss -s：快速查看全局 socket 内存总用量和各状态连接数，辅助判断是否达到系统级限制（如
net.core.wmem_max）
关联内核参数做针对性优化
缓冲区表现异常，往往需同步检查并调整以下内核参数：
- 监听队列上限：
sysctl net.core.somaxconn（建议 ≥ 4096） - TCP 接收/发送缓冲区范围：
sysctl net.ipv4.tcp_rmem和sysctl net.ipv4.tcp_wmem（三元组中“最大值”应 ≥ 单连接预期峰值缓冲需求） - 全局缓冲区上限：
sysctl net.core.rmem_max/wmem_max（必须 ≥ tcp_rmem/tcp_wmem 的最大值） - 启用窗口缩放：
sysctl net.ipv4.tcp_window_scaling=1（高延迟网络必备）
临时生效用 sysctl -w，永久生效写入 /etc/sysctl.conf 后执行 sysctl -p。
