ss 深入：重传、RTT、收发缓冲与调优
更新时间：2026-09-19。基础连接查看见 ss 速查。这篇讲如何用
ss的详细输出判断网络质量和瓶颈：重传多不多、RTT 高不高、拥塞窗口和缓冲区有没有受限、监听队列是否溢出。
一、关键选项
bash
ss -t -i # TCP 连接 + 内部 TCP 信息（rtt、cwnd、retrans）
ss -t -i -n -m # 再加数字端口和内存/缓冲信息
ss -tlni # 监听(listen)套接字 + 内部信息（看 accept 队列）
ss -s # 套接字汇总（各状态计数、TIME_WAIT/重传统计）
ss -tan state time-wait | wc -l
ss -ti 'dport = :443' # 按表达式过滤二、一条连接的详细字段
bash
ESTAB ... bytes_received:14000 bytes_sent: ...
cubic wscale:7,7 rto:204 rtt:2.4/0.8 mss:1448
cwnd:10 bytes_acked: ... bytes_received: ...
pacing_rate 12.5Mbps retrans:0/3 dsack_ack ...
rcv_space: ... rtt:2.4/0.8 rcv_ssthresh:...| 字段 | 含义 | 异常信号 |
|---|---|---|
rtt:avg/mdev | 往返时延均值/抖动（ms） | rtt 高或 mdev 大说明链路慢/不稳定 |
retrans:cur/total | 当前重传/累计重传次数 | total 比例高 = 丢包或网络抖动 |
cwnd | 拥塞窗口（MSS 数） | 窗口一直很小限制吞吐 |
rto | 重传超时 | 随丢包成倍增长 |
rcv_space/rcv_ssthresh | 接收窗口通告 | 收端窗口小限制发送 |
pacing_rate | 发包速率 | 打不满带宽时看它和 cwnd |
重传率是最直接的网络质量指标：retrans 占 bytes_acked/data_segs_out 比例持续偏高，先怀疑物理网络丢包、带宽打满或对端处理慢（队列丢包），配合 dropwatch 看丢在内核还是线路。
三、收发缓冲：-m 与套接字内存
bash
ss -t -m -i dst 10.0.0.5
# skmem:(r0,rb...,t...,tb...,f...,w...)rb/tb是该连接接收/发送缓冲的内核分配上限，受tcp_rmem/tcp_wmem限制。- 高 BDP（高带宽×高延迟，如跨地域、长肥网络）链路，默认窗口可能不够大，吞吐被「窗口/RTT」限制，需要调大
tcp_wmem/tcp_rmem、开启窗口缩放（wscale，默认开）。 - 缓冲持续打满 + cwnd 大但发送慢，多为应用读写不及时或对端不读（零窗口），不是链路问题。
四、监听队列：backlog 溢出会丢握手
bash
ss -tln
# State Recv-Q Send-Q Local Address:Port
# LISTEN 0 128 *:8080
ss -tlni | grep -A1 :8080监听状态下：
- Send-Q = backlog 上限，Recv-Q = 当前已完成握手、等待 accept() 的连接数。
- Recv-Q 经常顶到 Send-Q，说明应用 accept 不及时（线程阻塞/单线程 accept），新连接会被丢弃或 SYN 重传——这正是 connection refused vs timeout 之外的第三类「队列满」故障。
- 调大应用层 listen backlog 与内核
net.core.somaxconn、tcp_max_syn_backlog，但更要修应用为什么接得慢。
五、ss -s 与 TIME_WAIT
bash
TCP: 1203 (estab 800, closed 320, orphaned 2, synrecv 0, timewait 300/0)
TCPRTT: ... TCPRETRANS: 142 # 累计重传，快速看健康度- TIME_WAIT 多：短连接频繁主动关闭方产生，通常无害（端口够用时不是问题）；只有在源端口耗尽（
timewait巨量 + 连不上）时才需要tw_reuse、长连接或扩大本地端口范围，不要盲目开tw_recycle（现代内核已移除且有 NAT 陷阱）。 - orphaned 大量增长：应用关闭了但内核还在维持的连接，关注 fd/连接泄漏。
- 建立不上时结合状态统计看是卡在 SYN-SENT（网络/对端）还是 ESTABLISHED 但应用无响应。
六、调优方向速查
| 症状 | ss 线索 | 方向 |
|---|---|---|
| 吞吐打不满 | cwnd/rwnd 小、BDP 大 | 调缓冲、查丢包 |
| 延迟抖动 | rtt mdev 大、retrans 高 | 网络质量/拥塞 |
| 偶发握手失败 | listen Recv-Q≈Send-Q | 调 backlog/somaxconn + 修 accept |
| 端口耗尽 | 大量 TIME_WAIT 到同一目标 | 连接池/长连接/tw_reuse |
| 连接堆积 | ESTAB 巨多、应用慢 | 连接池、限流 |
坑
- 看到 TIME_WAIT 多就当故障调内核，绝大多数情况无害，要看是否端口耗尽。
- 只看连接数不看
-i的 retrans/rtt，漏掉真正的网络丢包。 - backlog 溢出只想到调 somaxconn，根因常是应用 accept/线程被阻塞。
- 把发送缓冲打满当带宽不足，实际是应用没及时读/对端零窗口。
总结
ss -ti 暴露每条 TCP 连接的 RTT/抖动、拥塞窗口 cwnd、累计重传 retrans、pacing_rate 等真实传输指标，是判断丢包、长肥网络窗口受限和带宽打不满的第一手依据；-m 看收发缓冲、-tln 看监听 backlog 与待 accept 队列是否溢出、-s 汇总各状态和全局重传，从而把「连接慢/建不上」细分到网络丢包、缓冲窗口、accept 队列还是短连接端口耗尽，再对症调整内核参数或应用连接模型。