应用超时 800ms 但内核 RTO 退避还在跑：「double-send」窗口到底怎么算，tcp_retries2 该不该改？

背景

我在写 tc netem 故障注入的文章时（见引用 #1），梳理内核 RTO 退避和应用超时的交互，发现一个一直没被认真讨论的问题：当应用超时（比如 800ms）先于内核 RTO 退避完成而触发时，应用层发起重试（新建连接或重发），此时内核对原始连接还在做 retransmission——等于同一个逻辑请求在网络上跑了两份。社区里 #1508 讨论过 P99 抖动归因，但焦点在「谁的锅」，没深入到「应用重试 vs 内核重试」的时序冲突。

现象（生产环境实抓）

我们一组 32 个 gRPC 微服务，跨机房 RTT 基线 4.2ms，峰值 QPS 约 6800。某次上联链路出现 500ms 抖动窗口：

• nstat -az 增量：TcpRetransSeg +340、TcpTimeouts +12
• 应用层 800ms 超时触发，Resilience4j 重试 3 次（无 jitter）
• 抓包（tcpdump 对端侧）看到：原始连接的 FIN 在 2.4s 才发出——内核还在做第 3 轮 RTO 退避（200→400→800ms，tcp_rto_min=100 但实际 RTO 从 SRTT 算出 200ms 起步）
• 结果：同一业务请求在网络上跑了 4 份（1 原始 + 3 应用重试），对端瞬时 QPS 翻 4 倍
• 对端有 2 个非幂等写接口，产生了 2 条重复数据（对账才发现）

已尝试的排查与结果

1. 把应用超时从 800ms 提到 3s：P99 从 SLO 2s 直接爆到 3.2s，业务侧不可接受，回滚。
2. 把 net.ipv4.tcp_retries2 从 15 降到 3：理论上 RTO 窗口缩到 ~200+400+800=1.4s，但应用 800ms 还是先超时，double-send 依然存在，问题没解决。另外担心：正常链路偶尔 1-2 次 RTO 是正常的，降到 3 会不会把「差一点就恢复」的连接直接 kill？
3. 应用层加 jitter（±100ms）：缓解了重试风暴（QPS 尖刺从 4× 降到 2.5×），但没消除 double-send 本身。
4. 抓包对比 ss -ti 的 rto 值：确认 RTO 确实从 200ms 起步、指数翻倍，retrans 计数和应用超时触发时间对得上——不是观测误差，是时序设计问题。

期望得到的答案形态

1. 有没有一个公式或经验法则，能根据「目标 SLO + 内核默认 RTO 参数（tcp_rto_min、SRTT 基线、退避轮数）」反推出应用超时的合理区间？比如：「SLO 2s、RTT 基线 5ms → 应用超时应 ≥ X ms，其中 X = f(RTO_min, retrans_rounds)」？
2. tcp_retries2 降到 3 或 4 的生产风险：有没有人实际改过？会不会把「正常 2 次 RTO 后恢复」的连接误杀？跨机房 5ms RTT 和同机房 0.5ms RTT 下这个参数该怎么差异化设？
3. 有没有人在应用层做过「等内核 retransmission 窗口结束再重试」的机制？比如通过 getsockopt(TCP_INFO) 读 tcpi_retrans / tcpi_rto，或者用 eBPF 挂 kprobe/tcp_retransmit_skb 感知内核还在退避，再决定应用层要不要发重试？怎么实现的、性能开销多大？
4. 更根本的问题：在微服务 + 连接池架构下，「应用超时」和「内核超时」这两层到底谁该是权威？有没有架构层面的干净解法（比如 socket option TCP_USER_TIMEOUT 替代应用层定时器）？