什么是 tcp_retries2
当发送方向的数据长期得不到确认时，内核按退避策略反复重传，tcp_retries2 限定这类重传的次数上限，默认 15，对应大约十几分钟到二十分钟才会判定连接失败。它决定了“链路断了多久才被感知”，但代价很直观：调小能更快发现断链，却可能在弱网或高丢包链路上误杀本来还能恢复的连接。
基本信息
| 参数路径 | net.ipv4.tcp_retries2 |
|---|---|
| 默认值 | 15 |
| 定位 | 未被确认的重传次数上限，按指数退避累计 |
| 相关参数 | tcp_retries1（触发通知的重传次数）、tcp_rto_min/max |
| 生效范围 | 内核全局，新连接生效 |
| 观测 | ss -tin 的 retrans 与 timer 字段、nstat 的重传计数 |
典型使用场景
- 断链感知过慢：业务日志晚十几分钟才报超时，评估是否与之相关
- 弱网环境调优：确认调小是否会造成可用连接被误中断
- 长连接健康检查设计：明确内核超时与应用心跳的分工
- 故障复盘：判断“连接卡住很久”是否为内核重传窗口所致
- 与 keepalive 配合：评估两套机制同时存在时的叠加效果
查看与核查
查看与核查
sysctl net.ipv4.tcp_retries2 # 当前值
sysctl net.ipv4.tcp_retries1 # 通知阈值
ss -tin | grep -m3 -o 'retrans:[0-9/]*' # 连接级重传次数
ss -tin state established | grep -m3 -o 'timer:[^ ]*'
nstat -az 2>/dev/null | grep -iE 'retrans|timeout' | head
# 变更示例（结合弱网基线评估）：sysctl -w net.ipv4.tcp_retries2=8取值与后果
| 取值 | 断链判定速度 | 风险 |
|---|---|---|
| 15（默认） | 十几分钟量级 | 业务感知滞后，长连接尤其明显 |
| 8 左右 | 缩短到分钟量级 | 弱网可能误杀可用连接 |
| 更小 | 很快放弃 | 高丢包链路频繁中断 |
| 配合应用超时 | 由业务层主导 | 推荐做法，内核参数保持默认 |
内核重传判定与 TCP keepalive 是两套机制：前者针对有数据待确认的情况，后者针对空闲连接，排查“连接为什么还活着”要分别看。
调小前先用弱网基线估算实际的判定时间，只在实验室验证过的值才能上生产，因为这个参数直接影响业务对故障的感知与恢复行为。