调整linux tcp重传策略需区分连接建立与已建立阶段，重点调tcp_syn_retries控制syn重传次数以影响connect()失败等待时长，设为3（约7秒）为通用推荐值；慎动tcp_retries2和tcp_retries1，其作用非简单限制重传次数；应用层超时必须同步配置。
调整 Linux TCP 连接重传策略，关键在于区分“连接建立阶段”和“连接已建立后”的不同机制，不能笼统说“调重传次数”。内核用多个独立参数分别控制不同场景，改错参数不仅无效，还可能引发意外行为。
重点调 tcp_syn_retries：控制 connect() 失败等待时长
这个参数只影响客户端调用 connect() 后、三次握手完成前的 SYN 重传次数。它直接决定“连不上时卡多久”。默认值通常是 6（部分发行版为 5），对应累计超时约 45–63 秒——对现代服务来说太长。
- 设为 2：约 3 秒后失败，适合稳定内网微服务
- 设为 3：约 7 秒后失败，通用推荐值，兼顾响应性与抗丢包能力
- 设为 4：约 15 秒后失败，适用于移动/物联网等弱网环境
- 避免设为 1（易误判丢包）或 0（内核静默回退到默认）
临时生效：sudo sysctl -w net.ipv4.tcp_syn_retries=3
永久生效：在 /etc/sysctl.conf 中添加 net.ipv4.tcp_syn_retries = 3，再执行 sudo sysctl -p。
慎动 tcp_retries2：它不等于“最多重传 N 次”
该参数（默认 15）并不直接限制重传次数，而是参与计算一个理论存活窗口（约 924 秒）。实际重传多少次，取决于当前 RTT、RTO 动态变化和指数退避节奏，往往远少于 15 次。硬砍到 3 或 5 并不能实现“3 次就断”，反而可能让连接过早被 kill，丢失重传机会。
真正影响弱网数据传输鲁棒性的，是启用 tcp_sack=1（选择性确认）、调优 tcp_rmem/tcp_wmem（收发缓冲区），以及合理设置 tcp_rto_min 和 tcp_rto_max（RTO 上下限）。
别忽略 tcp_retries1：它触发路由探测，不是断连开关
默认值通常为 3。当连续 RTO 超时达此次数，内核会怀疑当前路由失效，主动查 FIB 表尝试更新路由——连接本身仍在继续重传，不会终止。除非你频繁遭遇路由抖动，否则一般无需调整。
它和 tcp_syn_retries 完全无关，不能用来“加速失败判定”。
应用层超时必须同步配置
内核参数只是兜底。如果应用代码没设 connect 超时，哪怕 tcp_syn_retries 已调为 2，上层框架仍可能因自身默认值（如 OkHttp 默认 10 秒、Spring Boot 默认 30 秒）提前中止连接。
- Go：用
net.DialTimeout() - Python：用
socket.settimeout()或urllib.request.urlopen(timeout=...) - Java：显式调用
Socket.connect(address, timeout)，勿依赖默认无超时行为
内核与应用层超时应协同设计，前者保底线，后者控体验。
