TCP重传率高但带宽跑不满，ss -ti里的retrans和rto能说明是链路问题还是本机拥塞？

一、问题的提出：为什么 retrans 与 rto 会被误读

1.1 一个高频现场：重传率 3%，吞吐只有链路的四成

设想一条跨地域专线，标称 1 Gbps，实测单流吞吐长期徘徊在 380–420 Mbps，ss -ti 显示某条连接的 retrans 累计值持续增长，重传率约 2%–4%，rto 在 200ms 上下波动。此时最常见的两种结论是：其一，“链路有丢包，找运营商”；其二，“本机拥塞，调大缓冲区”。这两种结论都可能错，因为 retrans 是一个累计计数器，rto 是一个当前估计值，二者都不直接指示丢包发生的位置。

要理解这一点，需要先明确 TCP 重传的两种触发路径。第一种是超时重传（RTO, Retransmission Timeout）：发送端在 RTO 计时器到期仍未收到 ACK，判定报文丢失并重传，同时触发拥塞窗口收缩。第二种是快速重传（Fast Retransmit）：接收端收到乱序报文后发送重复 ACK（dupACK），发送端收到三个及以上 dupACK 即重传，通常配合快速恢复（Fast Recovery）。RFC 5681 对这两种机制的窗口调整有明确规定，RFC 6298 则规定了 RTO 的计算方法。本文评述：这两种机制在 ss 输出中并不会被分别计数，这正是误读的根源之一——RTO 重传往往意味着严重丢包或路径中断，而快速重传更多对应零星丢包，二者的工程含义截然不同。

1.2 三个常见认知偏差

偏差一：把重传率等同于丢包率。重传率是“重传报文数 / 发送报文总数”，而丢包率是“丢失报文数 / 发送报文总数”。二者在数值上接近，但重传报文本身也可能再次丢失，且 SACK（RFC 2018）与 RACK（RFC 8985）等机制会改变重传的触发时机与数量。在高 BDP 链路上，一次 RTO 可能引发成批重传，使重传率被放大。

偏差二：把 rto 当作链路时延。ss 中的 rto 字段是当前 RTO 估计值，其下界由内核常量决定（Linux 中 TCP_RTO_MIN 通常为 200ms，见 tcp.h），上界受 TCP_RTO_MAX 约束。它反映的是“发送端认为多久没收到 ACK 就该重传”，而不是 RTT。真正的 RTT 应看 rtt 与 rttvar 字段。

偏差三：忽略采样时机。ss -ti 输出的是某一瞬间的套接字状态快照，retrans 是自连接建立以来的累计值。若不结合时间窗口做差分，就无法判断重传是“历史遗留”还是“当前正在发生”。

笔者认为，判断“链路问题还是本机拥塞”这个二分法本身就有缺陷。真实故障往往由多个因素叠加：链路存在 0.1% 的随机丢包，同时本机 qdisc 队列溢出造成额外丢包，二者共同把重传率推高。工程上更应问的是“在当前观测窗口内，哪一类丢包占主导”，而不是非此即彼地归因。

二、原理层：ss -ti 字段的语义与重传触发机制

2.1 ss -ti 输出字段逐项拆解

先看一段典型输出（Linux 5.15 内核，ss -ti）：

ESTAB 0 0 10.0.1.5:52014 203.0.113.20:443
  cubic wscale:7,7 rto:204 rtt:48.3/12.1 ato:40 mss:1448
  pmtu:1500 rcvmss:1448 advmss:1448 cwnd:38 ssthresh:22
  bytes_acked:1843201 bytes_received:92160 segs_out:1290 segs_in:640
  data_segs_out:1278 data_segs_in:320 send 9.6Mbps lastsnd:12
  lastrcv:8 lastack:8 pacing_rate 19.2Mbps delivery_rate 8.4Mbps
  busy:120ms unacked:4 retrans:3/58 lost:2 rcv_space:28960
  notsent:0 minrtt:46.2

各字段含义需要精确界定，否则后续判别无从谈起：

需要特别指出，retrans:3/58 这类斜杠格式在不同内核版本中含义不同：较新内核中前一个数字表示“当前未确认队列中已重传的段数”，后一个数字表示“连接累计重传段数”。若不做版本核对就直接解读，极易得出错误结论。本文评述：这也是为什么很多“经验帖”给出的阈值不可直接套用——内核版本差异会改变字段语义，工程上应先 uname -r 确认版本，再对照对应内核源码中的 tcp_sock 字段定义。

2.2 RTO 的计算与退避机制

RFC 6298 给出的 RTO 计算基于 SRTT 与 RTTVAR：

SRTT    = (1 - α) * SRTT + α * RTT          α = 1/8
RTTVAR  = (1 - β) * RTTVAR + β * |SRTT - RTT|  β = 1/4
RTO     = SRTT + max(G, K * RTTVAR)          K = 4, G 为时钟粒度

Linux 实现中还有若干工程修正：RTO 下界为 TCP_RTO_MIN（200ms），上界为 TCP_RTO_MAX（120s），且每次超时重传后 RTO 按指数退避（1、2、4、8…倍）。这意味着：如果观察到 rto 值明显大于 200ms 且持续增长，几乎可以确定发生过 RTO 超时事件，因为正常 RTT 估计不会把 RTO 推高到数百毫秒以上（除非 RTT 本身很大）。反之，若 rto 稳定在 200ms 附近而 retrans 仍在增长，则重传更可能由快速重传触发，对应零星丢包而非路径中断。

这一推论是本文判别主线的第一块基石。笔者认为，很多现场把“rto 200ms”误读为“时延 200ms”，进而误判链路质量，恰恰是因为没有理解 RTO 是估计值而非测量值。

2.3 快速重传、SACK 与 RACK 的交互

快速重传依赖 dupACK。接收端收到乱序段时立即发送 dupACK，发送端收到 3 个 dupACK 即重传缺失段。SACK 选项让接收端能告知“已收到哪些段”，使发送端可以一次重传多个空洞，显著提升恢复效率。RACK（RFC 8985）则基于时间而非计数判断丢失：若某段发出后经过“最新被 SACK 的段的时间 + RTT”仍未确认，即判定丢失。RACK 在 Linux 4.19 之后默认启用，它改变了 lost 字段的统计口径。

本文评述：RACK 的引入使得“重传”与“丢包”的对应关系更紧密，但也让 retrans 的增长更平滑——过去一次 RTO 会引发成批重传，现在 RACK 会逐段判定、逐段重传。因此在新内核上，retrans 增长快不一定意味着链路差，可能只是丢失检测更灵敏。判断时必须结合 lost 与 delivery_rate 一起看。

三、判别主线：用字段联合形态完成丢包归因

3.1 主线定义：重传触发源分层

本文提出的分析主线是“重传触发源分层”：把每一次重传事件按触发原因归入三个层次——L1 端侧发送路径丢包（本机 qdisc 溢出、网卡队列丢包、TSO/GSO 分片问题）、L2 中间链路丢包（运营商、跨域、无线、隧道封装）、L3 端侧接收路径丢包（对端 rcvbuf 不足、对端 qdisc 溢出）。ss -ti 的字段组合可以给出各层的“嫌疑度”，但不能直接定罪，必须用主动测量交叉验证。

这条主线的价值在于：它把“链路 vs 本机”的二元对立替换为“发送端 vs 中间 vs 接收端”的三元定位，而本机拥塞实际上横跨 L1 与 L3。工程上，先定位层次，再在该层内做参数调优，比盲目调 tcp_wmem 或 rmem 高效得多。

3.2 判别矩阵：字段组合与嫌疑层

这张矩阵是本文的核心工具。它的使用前提是多次采样：单次 ss -ti 无法区分“正在发生”与“历史累计”。建议以 1 秒为间隔连续采样 30–60 次，观察 retrans、lost、cwnd、rto、rtt 的差分轨迹。

3.3 为什么 cwnd 与 BDP 的比值是关键判据

带宽时延积 BDP = 带宽 × RTT。若 cwnd × MSS < BDP，则发送窗口不足以填满链路，吞吐必然受限。此时若 retrans 也在增长，说明窗口被丢包反复打压，形成“丢包—降窗—吞吐下降—更难恢复”的负反馈。反之，若 cwnd × MSS ≈ BDP 而吞吐仍低，则瓶颈不在 TCP 窗口，而可能在应用层、磁盘 IO 或接收端。

本文评述：很多现场只盯着 retrans 的绝对值，却忽略 cwnd 是否已经足够大。一个 retrans 为 0 但 cwnd 只有 10 的连接，吞吐同样跑不满——此时问题根本不是重传，而是窗口受限（可能是接收窗口、也可能是拥塞控制处于慢启动早期）。因此判别必须“先看窗口是否受限，再看重传是否拖累窗口”。

四、工程路径：从观测到验证的完整操作步骤

4.1 第一步：建立基线，确认是否真的“跑不满”

在归因之前，先确认吞吐瓶颈是否真的在 TCP 层。用 iperf3 做单流与多流对比：若单流低、多流高，说明单流窗口受限（BDP 大或丢包打压窗口）；若单流多流都低，说明瓶颈在链路带宽或端侧处理能力。同时记录 ethtool -S 的网卡丢包计数、ip -s link 的 errors/dropped，作为 L1 的基线。

# 基线采集（发送端执行）
iperf3 -c 203.0.113.20 -t 30 -P 1 -J > single.json
iperf3 -c 203.0.113.20 -t 30 -P 8 -J > multi.json
ethtool -S eth0 | egrep 'drop|err|miss|fifo'
ip -s link show eth0
nstat -az | egrep 'TcpRetrans|TcpExtTCPLostRetransmit|TcpExtTCPSackRecv'

nstat 提供的是协议栈全局计数器，比单连接 ss 更适合做趋势判断。其中 TcpRetransSegs 是全局重传段数，TcpExtTCPLostRetransmit 是“重传又丢失”的次数——后者若持续增长，强烈指向链路质量差，因为本机队列丢包通常不会让重传段再次丢失（重传段优先级相同，但队列已空出）。

4.2 第二步：连续采样 ss，绘制字段轨迹

用脚本对目标连接连续采样，输出 CSV 便于绘图：

#!/bin/bash
# ss_trace.sh —— 对指定四元组连续采样
TARGET="203.0.113.20:443"
for i in $(seq 1 60); do
  ss -tin dst $TARGET 2>/dev/null | awk -v ts=$(date +%s.%N) '
    /cubic|bbr|reno/ {
      for (i=1;i<=NF;i++) {
        if ($i ~ /^rto:/)   rto=substr($i,5)
        if ($i ~ /^rtt:/)   rtt=substr($i,5)
        if ($i ~ /^cwnd:/)  cwnd=substr($i,6)
        if ($i ~ /^retrans:/) retrans=substr($i,9)
        if ($i ~ /^lost:/)  lost=substr($i,6)
        if ($i ~ /^unacked:/) unacked=substr($i,9)
      }
      print ts","rto","rtt","cwnd","retrans","lost","unacked
    }'
  sleep 1
done

把输出导入表格工具，重点看三条曲线：retrans 的斜率（是否持续增长）、rto 的台阶（是否出现退避）、cwnd 的锯齿（是否被反复打压）。若 cwnd 呈规则锯齿且每次下探都伴随 retrans 增加，说明丢包正在触发拥塞控制降窗；若 cwnd 平稳但吞吐低，则瓶颈不在拥塞控制。

4.3 第三步：主动测量交叉验证

被动观测只能给出嫌疑，主动测量才能定罪。常用手段有三：

其一，mtr 长时观测。mtr -rwzc 200 203.0.113.20 可给出逐跳丢包率与抖动。若丢包只出现在最后一跳，多为对端问题；若中间某跳开始丢包且后续跳继承，则为链路问题。注意 ICMP 限速会导致“假丢包”，需结合 TCP 模式（mtr -T）复核。

其二，tcpdump 抓包分析。在发送端抓包，统计重传段与 dupACK：

tcpdump -i eth0 -s 128 -w trace.pcap 'host 203.0.113.20 and tcp'
# 分析（tshark）
tshark -r trace.pcap -q -z io,stat,1,"tcp.analysis.retransmission"
tshark -r trace.pcap -Y "tcp.analysis.fast_retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.rto" | wc -l

若 tcp.analysis.rto 计数高，说明存在超时重传，指向严重丢包或路径中断；若只有 fast_retransmission，则为零星丢包。进一步看重传段的原始发送与重传间隔：间隔接近 RTO 的是超时重传，间隔约 1 个 RTT 的是快速重传。

其三，接收端对照。在对端同时用 ss -ti 与 nstat 观测，若对端 TcpExtTCPBacklogDrop、TcpExtTCPRcvQDrop 增长，说明丢包发生在接收路径（L3），而非链路。这一步常被忽略，却是区分“发送端拥塞”与“接收端拥塞”的关键。

4.4 第四步：本机队列与内核参数核查

L1 层最隐蔽的丢包源是 qdisc 队列溢出。用 tc -s qdisc show dev eth0 查看 dropped、overlimits、backlog。若 dropped 持续增长，说明发送队列已满，属于典型的本机拥塞丢包。此时应优先考虑换用 fq_codel 或 fq 队列规则，而非一味增大缓冲区。

tc -s qdisc show dev eth0
# 切换为 fq_codel（对抗缓冲膨胀）
tc qdisc replace dev eth0 root fq_codel
# 或使用 fq + pacing（配合 BBR）
tc qdisc replace dev eth0 root fq
# 查看套接字缓冲区
sysctl net.ipv4.tcp_wmem net.ipv4.tcp_rmem net.core.wmem_max net.core.rmem_max

本文评述：缓冲区并非越大越好。过大的 tcp_wmem 会加剧缓冲膨胀（bufferbloat），使 RTT 升高、丢包检测延迟，反而降低吞吐。RFC 8290 对 fq_codel 的设计目标有详细论述，其核心是用 AQM 在队列将满时主动标记/丢弃，以维持低时延。工程上应结合 BDP 设置缓冲区上限，而非直接套用“调大就好”的经验。

五、典型场景与案例拆解

5.1 场景一：跨域专线，rto 阶跃 + retrans 成批增长

某企业跨域专线，单流吞吐 200 Mbps（标称 500 Mbps），ss -ti 显示 rto 从 204ms 阶跃到 1.6s 再回落到 204ms，retrans 在阶跃期间成批增长，cwnd 从 120 骤降到 2。mtr -T 显示中间某跳丢包率 8%，且后续跳继承。抓包显示存在 tcp.analysis.rto 事件。

归因：L2 链路丢包，且严重到触发 RTO。rto 的阶跃是 RTO 指数退避的直接证据（204ms → 408ms → 816ms → 1.6s）。处理路径：向运营商提供 mtr 与抓包证据，要求排查中间跳；同时在应用侧启用多流并行以摊薄单流受损影响。本文评述：这类场景下调本机参数几乎无效，因为丢包不在本机。把 rto 的阶跃形态作为“链路严重丢包”的判据，比单看 retrans 更可靠。

5.2 场景二：同机房高吞吐，cwnd 锯齿 + qdisc drops 增长

某对象存储网关，同机房内 25 Gbps 网卡，单流吞吐 6 Gbps 上不去。ss -ti 显示 retrans 缓慢增长，rto 稳定 200ms，cwnd 呈规则锯齿，rtt 从 0.2ms 升到 4ms。tc -s qdisc 显示 dropped 持续增长，backlog 接近上限。

归因：L1 本机队列溢出。rto 稳定说明没有超时重传，retrans 增长来自快速重传，对应队列丢包。rtt 升高是队列积压的直接体现（排队时延）。处理：将 qdisc 从默认 pfifo_fast 换为 fq_codel，并按 BDP 调整 tcp_wmem 上限；若使用 BBR，配合 fq 做 pacing。处理后 cwnd 锯齿消失，吞吐提升到 18 Gbps。本文评述：此例中“retrans 高”与“链路差”无关，纯粹是本机队列问题，若误判为链路问题会浪费大量排查时间。

5.3 场景三：无线接入，rtt 方差大 + 重传集中在特定时段

某移动端回传场景，4G/5G 链路，rtt 均值 60ms 但方差达 40ms，retrans 在忙时集中增长，rto 在 200–600ms 间波动。minrtt 为 35ms，说明排队时延占比高。此类场景的丢包多来自无线侧调度与切换，属于 L2 但具有强时变性。

处理思路与专线不同：不宜追求零丢包，而应提升对丢包的鲁棒性。可考虑启用 BBR（对随机丢包不敏感）、增大初始窗口、使用 FEC 或 QUIC 多路径。本文评述：在无线场景下，retrans 高是常态，判别重点应转向“丢包是否集中在切换/忙时”，而非追求绝对数值。把有线场景的阈值套用到无线，是常见的误判来源。

六、本机拥塞的深层成因：从 qdisc 到协议栈

6.1 qdisc 层的丢包机制

Linux 发送路径依次经过：套接字缓冲区 → TCP 层分段 → IP 层 → qdisc 入队 → 驱动环形缓冲区 → 网卡。任一环节队列满都会丢包。qdisc 的 dropped 计数对应入队失败，overlimits 对应 AQM 主动丢弃/标记。默认 pfifo_fast 无 AQM，队列满即尾丢（tail drop），会引发全局同步（global synchronization）与缓冲膨胀。

本文评述：很多“本机拥塞”其实是 qdisc 配置不当。把 pfifo_fast 换成 fq_codel 往往能在不改应用的情况下显著改善时延与吞吐。RFC 8290 与 RFC 8289（CoDel）提供了理论依据：AQM 通过控制排队时延而非队列长度来管理拥塞，更适应动态带宽。

6.2 接收路径丢包：被忽视的 L3

接收端丢包同样会表现为发送端重传。常见原因包括：net.core.rmem_max 过小导致接收窗口不足、net.core.netdev_max_backlog 过小导致软中断处理不过来、应用读取过慢导致 tcp_rmem 被填满。nstat 中的 TcpExtTCPBacklogDrop、TcpExtTCPRcvQDrop、TcpExtTCPOFODrop 是直接证据。

判别方法：在接收端执行 ss -ti，若 rcv_space 持续为 0 或很小，且 skmem 显示接收队列满，则为接收端瓶颈。此时发送端的 cwnd 会被接收窗口限制，unacked 接近接收窗口而非拥塞窗口，吞吐同样上不去，但 retrans 未必高。本文评述：这正是“重传率高”与“带宽跑不满”不总是同时出现的原因——接收窗口受限时，吞吐低但未必重传。

6.3 拥塞控制算法的影响

CUBIC（RFC 9438）以丢包为主要拥塞信号，丢包即降窗，因此对随机丢包敏感；BBR（基于模型）以带宽与最小 RTT 估计为信号，对随机丢包不敏感，但在浅缓冲与多流公平性上存在争议。RACK 与 SACK 的启用会改变重传时机。判别时必须先确认算法：ss -ti 输出首行会显示 cubic、bbr 等标识。

本文评述：在存在随机丢包的链路上，CUBIC 的 retrans 会显著高于 BBR，但这不代表链路更差，而是算法对丢包的反应不同。用 CUBIC 的阈值去评判 BBR 连接，是典型的“跨算法误判”。工程上应固定算法后再做纵向对比。

七、对比与局限：方法边界、算法差异与误判清单

7.1 与既有方法的对比

本文评述：eBPF 是近年最有价值的补充手段。通过 kprobe 挂载到 tcp_retransmit_skb、kfree_skb 等函数，可以精确统计“在哪个函数丢的包”，从而把 L1/L2/L3 的嫌疑直接落到代码路径。相比抓包，eBPF 在高吞吐下开销更低。相关入门资料可参考 Brendan Gregg 的 eBPF 资料页 与 Cilium 的 BPF 文档。

7.2 误判清单

综合前文，列出高频误判：把 rto 当 RTT；把累计 retrans 当当前重传率；忽略内核版本导致的字段语义差异；用 CUBIC 阈值评判 BBR；把接收窗口受限当作拥塞窗口受限；把 ICMP 限速当作链路丢包；在无线场景套用有线阈值；忽略 qdisc 的 dropped 计数。每一条都对应前文的一个机制，工程上应逐条排除。

7.3 方法边界

本文方法在以下条件下失效：加密流量无法抓包分析（需依赖 eBPF 或内核计数）；中间设备做 TCP 代理或优化（重传语义被中间件改写）；多路径传输（MPTCP）下重传归属复杂；容器网络经过多次 NAT 与 veth 转发，qdisc 层次多，需逐层排查。这些边界应在使用判别矩阵前明确。

八、结论与展望

回到标题的问题：ss -ti 里的 retrans 和 rto 能说明是链路问题还是本机拥塞吗？答案是：单独不能，联合可以给出高置信度的嫌疑排序，但最终定罪仍需主动测量与端侧对照。本文的核心贡献是把“二元归因”重构为“重传触发源分层”，并给出可操作的判别矩阵与四步工程路径。

具体而言：rto 的阶跃与退避指向 RTO 超时，对应严重丢包或路径中断，多为 L2；rto 稳定在 200ms 而 retrans 缓慢增长，多为快速重传，对应零星丢包，需结合 qdisc 计数区分 L1 与 L2；cwnd 锯齿与 rtt 升高同时出现，优先怀疑本机队列；unacked 接近接收窗口而非拥塞窗口，则瓶颈在接收端。每一条判据都有明确的机制支撑，而非经验口诀。

展望未来，三个方向值得关注：其一，eBPF 与可观测性框架（如 OpenTelemetry 的网络语义约定）正在把丢包归因从“事后排查”推向“持续观测”；其二，QUIC 的普及会改变重传语义，ss 对 UDP 类传输的观测能力需要新的工具补充；其三，可编程数据平面（P4、eBPF/XDP）使得在网卡侧精确统计丢包点成为可能，未来“链路 vs 本机”的判别有望在数据平面完成。本文评述：工具在变，但“先分层、再验证”的方法论不会过时——这正是本文希望传递的核心。

主要参考文献