【背景】
做了 10 年网络工程，"半开连接"（half-open / ghost connection）是我复盘过的事故里出现频率最高、但定责最模糊的一类。
三种典型场景，表面都是"连接突然断了"，根因完全不同：
- 对端 OOM 被 kill，RST 包发不出去（进程已死），本端 socket 还是 ESTABLISHED，写操作阻塞在 send buffer 直到超时；
- 网络分区（交换机端口 flap、VPC 路由表抖动），RST 包到了交换机但路由丢了，本端永远收不到 RST，线程挂住；
- 中间设备（LB / NAT 网关 / 云厂商 ENI）的 idle timeout（通常 60s–300s）到了，单方面丢弃会话表项，两侧主机都不感知，下一次发数据才收到 RST 或超时。
这三种情况的修复路径完全不同：第一种要应用层判死重连；第二种要网络层路由收敛；第三种要对齐设备 timeout。但线上排障时，日志里看到的都是同一句话："Connection reset by peer" 或 "Read timed out"。
【常见分歧 / 几种做法】
我见过四种立场，各有道理也各有盲区：
立场 A：应用层必须自己兜底 每个长连接加 application-level heartbeat（gRPC PING、HTTP/2 PING、自定义心跳包），超时 N 次判死。 优点：不依赖任何中间设备，语义最清晰，判死后可以执行业务级清理（回滚事务、释放资源）。 缺点：心跳间隔怎么定？太短浪费带宽（800 conn/s 新建 + 2 万存量长连接，心跳包量不小）；太长则故障检测窗口太大。gRPC server-streaming 场景里数据流本身可以当心跳，但 idle 流（没有数据推送的流）呢？
立场 B：TCP keepalive 就够了 调内核参数 net.ipv4.tcp_keepalive_time=300 / interval=30 / probes=3（Linux 默认 2h/75s/9 次，太慢）。 优点：零应用代码，内核级，不占用户态 CPU。 缺点：keepalive 是 per-socket 的，2 万条连接就是 2 万个定时器；更关键的是，keepalive 只检测"对端是否还活着"，不检测"中间设备是否还认识这条流"——NAT 表项过期后，keepalive 包本身也会被丢弃，你反而多了一轮探测才发现问题。
立场 C：中间设备（LB/NAT）的 idle timeout 是唯一真相 把 LB idle timeout 设为 300s，应用层保证 250s 内至少有一次交互，否则主动断开重连。 优点：和中间设备对齐，不会出现"设备单方面丢弃"。 缺点：多了一层耦合——换 LB、换云厂商、加一层 service mesh sidecar，idle timeout 可能又不一样了。而且"主动断开重连"在 gRPC streaming 场景里意味着流断了、状态丢了，代价不小。
立场 D：eBPF 在内核层兜底，应用无感 用 eBPF 程序 hook tcp_sendmsg / tcp_recvmsg，检测 send buffer 堆积 + 无 ACK 超过 N ms 就主动 reset。 优点：不依赖应用层、不依赖中间设备，检测粒度最细。 缺点：eBPF 程序的稳定性（内核升级兼容性）、运维复杂度、以及"谁写谁维护"的问题。我在生产环境见过 eBPF 程序因内核升级后 kfunc 签名变化而静默失效的案例，排查花了两天。
【我的倾向与理由】
我倾向于 分层兜底、但只在一层做"判死"决策，具体：
- 内核层：tcp_keepalive 作为最后防线（time=120s, interval=15s, probes=3），不指望它做主检测；
- 应用层：对 idle 连接（无数据流的 TCP 连接、HTTP/1.1 keep-alive、gRPC idle channel）做 30s 心跳；对有数据流的连接（gRPC streaming、WebSocket），用应用层超时（60s 无数据判死）；
- 中间设备：idle timeout 设为应用层心跳间隔的 3 倍（比如 90s），留出抖动余量；
- 关键原则：只有应用层有"判死 + 重连"的权力，内核层和中间设备只做"被动断开"，不触发业务逻辑。
理由：
- 只有应用层知道"这条连接上有没有未完成的事务/流"，判死后的重连策略（是否幂等、是否回滚、是否降级）只有应用层能决定；
- 内核层 keepalive 和中间设备 timeout 是"无脑断开"，断开后应用层才知道连接没了，这时 send buffer 里的数据可能已经丢了（没 ACK）；
- 分层兜底的好处是任何一层失效其他层还能兜住，但判死逻辑只在一层，避免"两层同时判死、重连风暴"——我见过一次 LB 和应用层同时触发重连，3 秒内新建连接从 800 conn/s 飙到 12000 conn/s，直接把对端打挂了。
【想听大家在什么场景下怎么选】
- gRPC server-streaming / WebSocket 长连接：idle 流（没有数据推送的流）怎么判死？心跳间隔多少？有没有因为中间设备 idle timeout 导致过"静默断连"？
- K8s + service mesh（Istio / Cilium / Linkerd）：sidecar 的 idle timeout 和上游 LB 的 idle timeout 怎么对齐？有没有遇到过 sidecar 和上游 LB 的 timeout 不一致导致的"幽灵连接"？
- 跨机房 / 跨可用区：网络分区（不是断网，是路由抖动）场景下，RTO 和 keepalive 参数怎么配？有没有量化过"分区 30s 恢复后，有多少连接需要重建"？
- eBPF 兜底：有没有人在生产环境用 eBPF 做 TCP 半开连接检测？稳定性怎么样？内核版本兼容性踩过什么坑？
欢迎贴具体参数、事故时间线、以及"为什么选这个方案而不是另一个"的决策过程。