ss -ti 的 retransmits 字段仅统计 RTO 超时重传次数，不包含快速重传、SACK 或 TLP；它对应 /proc/net/snmp 中的 TCPTimeouts，值在连接关闭后清零，无法回溯历史，且与 TCPRetransSegs 无关。
ss -ti 的 retransmits 字段只统计超时重传
执行 ss -ti state established 时，每行末尾的 retransmits 值不是“总重传次数”，而是该连接自建立以来触发的 RTO 超时重传次数。它不包含快速重传（3×dupACK）、SACK 重传或 TLP。这意味着：
- 即使
TcpRetransSegs在/proc/net/snmp中持续上涨，retransmits仍可能为 0 —— 只要丢包被快速重传机制消化掉了 - 该值在连接关闭后清零，无法回溯历史；不能用于判断“这个连接总共重传过多少次”
- 它对应内核统计中的
TCPTimeouts，不是TCPRetransSegs
用 ss -tunap 定位目标连接再查重传
直接跑 ss -ti 会刷出所有连接，干扰大。真要盯住某个具体流，得先过滤四元组：
- 查目标服务端口（如 443）：
ss -tunap dport = :443→ 得到 PID 和源 IP/端口 - 再加
-i查细节：ss -ti dst 192.168.1.100:12345（替换为实际对端地址） - 观察输出中
retransmits后的数字，若 > 0 且rtt或rto显著增大（比如 rto > 2000），说明该路径存在稳定丢包或响应延迟
/proc/net/snmp 提供全局重传段总数，但不绑定连接
/proc/net/snmp 是唯一能拿到累计重传段数（TCPRetransSegs）的地方，但它只给总量，不告诉你哪条连接干的：
- 运行
awk '$1 == "Tcp:" {print $15}' /proc/net/snmp提取第 15 列（不同内核列序可能微调，先head -1 /proc/net/snmp确认） - 该值是系统级累计，重启归零；增长快（如每秒 +10）说明整体链路有问题，但无法定位到具体连接
- 别和
netstat -s混用——后者字段名不统一、依赖 net-tools 包，在容器里常不可用
tcpdump 是唯一能确认重传类型和位置的方法
如果需要知道某连接到底发生了哪种重传（超时？快速？乱序？），必须抓包：
- 过滤特定连接：
sudo tcpdump -i any 'tcp and src host 192.168.1.100 and dst port 80' -w retrans.pcap - Wireshark 打开后，用显示过滤器
tcp.analysis.retransmission标出所有重传包 - 进一步区分：
tcp.analysis.fast_retransmission→ 快速重传；tcp.analysis.ack_lost_segment→ 丢 ACK 导致重传；纯重发相同 seq 且间隔翻倍 → RTO 超时重传
真正难的不是看到重传，而是判断重传背后的原因——rto 长了是路径丢包，retransmits 为 0 但 TCPRetransSegs 却涨，大概率是快速重传主导，这时候要看接收端 buffer 或中间设备是否乱序。
