Linux TCP 重传次数过高的原因

调高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 层不断重传。常见于虚拟化环境或升级内核/驱动后。

BizPower CRM客户管理系统

通过使用BizPower CRM解决方案，您的员工、生产过程及信息能够与客户保持着平稳、无间断的联络，并且能够通过以客户为焦点、创新的产品和服务；以客户为中心，更高层次的生产过程；持久有益的客户关系这三个方面创造有价值客户的领导关系。选择Bizpower CRM的原因1、灵活的数据权限和功能权限BizPower CRM 系统通过引入了灵活的数据权限和功能权限，模仿现实中协同工作的实际情况。 实现企

下载

• 检查是否启用了 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' 观察增量速率