调高net.ipv4.tcp_retries2不会减少重传，只延长死连接存活时间；重传频发根因是底层丢包或延迟，需用ss -i、tcpretrans定位源头，并排查网卡驱动、TSO/GSO、MTU及物理链路等问题。
为什么 net.ipv4.tcp_retries2 调高反而让重传更频繁？
这不是参数本身的问题，而是它只控制「超时后重试的轮数上限」，不控制重传触发条件。真正导致重传次数升高的是底层丢包或延迟，tcp_retries2 只是决定了系统在放弃连接前“最多试几次”。默认值 15 意味着最后一次重传后约 15–30 分钟才断连，期间你看到的“高重传次数”其实是持续丢包下的被动响应。
- 调大
tcp_retries2不会减少重传，只会延长死连接的存活时间，可能掩盖真实网络问题 - 调小（如设为 6）会让连接更快失败，便于快速发现异常，但可能误杀弱网场景下的正常连接
- 该值对 SYN 握手阶段无效——SYN 重传由
tcp_syn_retries控制，需单独排查
如何用 ss -i 和 tcpretrans 定位真实重传源头？
ss -i 能直接显示每个 socket 的重传统计，比全局计数器更有针对性；tcpretrans（来自 bcc-tools）则可追踪到具体哪条流、哪个目的 IP 在高频重传。
- 运行
ss -i state established | grep retrans，关注retrans字段非 0 的连接，再结合dst和timer判断是否卡在某次超时 -
tcpretrans -L可列出当前所有正在重传的 TCP 流，加-C参数还能显示重传率（%），>5% 就值得深挖 - 注意区分「快速重传」（3 个重复 ACK 触发）和「超时重传」（RTO 超时触发）：前者说明路径上有丢包但链路尚通，后者往往指向中间设备故障或严重拥塞
网卡驱动、TSO/GSO 和 MTU 不匹配如何引发隐性重传？
这类问题不会报错，但会导致分片异常、校验失败或硬件丢包，最终体现为 TCP 层不断重传。常见于虚拟化环境或升级内核/驱动后。
- 检查是否启用了 TSO/GSO：
ethtool -k eth0 | grep tso|gso；若接收端不支持却开启发送，对方 TCP 栈可能静默丢弃大包 - 确认 MTU 一致：
ip link show eth0 | grep mtu，对比交换机端口、宿主机、容器网络；1500 和 9000 混用极易引发 ICMP “Fragmentation Needed” 被过滤，从而无反馈丢包 - 某些旧网卡驱动（如部分 Realtek 或早期 virtio）在高吞吐下会丢弃带 timestamp 选项的 ACK，导致发送端误判超时并重传
/proc/net/snmp 中的 TcpRetransSegs 真实含义是什么？
它统计的是「重传的 TCP 段数量」，不是重传事件次数。一个重传事件可能包含多个段（比如之前发了 10 个段，丢了其中 3 个，就会计为 3 次 TcpRetransSegs 增量），所以数值高不一定代表连接不稳定，而可能是单次丢包量大或窗口设置不合理。
- 对比
TcpOutSegs（总发出段数）看比例：若TcpRetransSegs / TcpOutSegs > 0.02（2%），才算显著异常 - 该计数无法区分是本机发出的重传，还是收到对端重传后自己响应的 ACK——需配合抓包确认方向
- 重启网络服务或内核模块会清零该值，不能直接跨时段比较；建议用
watch -n 1 'awk "/TcpRetransSegs/ {print $2}" /proc/net/snmp'观察增量速率
真实重传高的根因，往往藏在 TCP 层之下：物理链路误码、交换机 buffer 丢包、防火墙连接跟踪老化、甚至云厂商安全组限速策略。盯着 tcp_retries2 调参，就像给发烧病人反复换体温计刻度。