HTTP keep-alive 超时不一致：一次「Connection reset by peer」间歇性 0.7% 失败的根因与三层修复

作者谢寒山-178

HTTPkeep-aliveOkHttpNginx性能调优高并发

智能体品牌：OkHttp · 4.12

结论先行：「偶发 Connection reset by peer、重试一次就好、抓包看不到丢包」，十有八九不是网络，而是客户端与服务端的 keep-alive 空闲超时不一致——服务端先关，客户端不知情，复用旧连接发请求，撞上服务端 RST。这类问题重试能救，但会放大而不是消除故障。下面给一套「定位 → 原理 → 修复 → 防回归」的完整链路。

一、现象与背景：0.7% 的失败率，重试后归零

服务：Java 17 + Spring Boot 3.2，作为 HTTP 客户端调用下游 4 个内部服务，OkHttp 4.12.0，ConnectionPool(10, 5, TimeUnit.MINUTES)。
下游：Nginx 1.24 反代到 Tomcat 10.1，Nginx keepalive_timeout 65s，Tomcat keepAliveTimeout=65000。
规模：单机 ~1800 QPS，其中 85% 请求走内网同机房，跨机房 15%。
症状：跨机房链路的调用，Connection reset by peer 稳定在 0.7%~0.9%，重试 1 次后成功率回到 99.99%；同城链路 0 失败。
已排除：ethtool 无错包、ss -ti 无 retrans、网关侧无 5xx、服务端 GC 无 Full GC。
反直觉点：把 OkHttp 连接池 idle 从 5min 改成 5min 后失败率不降反升，从 0.7% 涨到 1.2%。

二、原理：为什么「先关方」是服务端，RST 却由服务端发出

HTTP/1.1 keep-alive 的语义（RFC 7230 §6.3）只规定连接空闲多久可以关，不规定谁先关。TCP 层的正常关闭是四次挥手：服务端 close(fd) → 发 FIN → 客户端回 ACK → 客户端发 FIN。但只要 FIN 之后、客户端 ACK 之前，服务端 socket 还挂着未读数据（比如客户端正好复用这条连接发来了新请求），内核就会把 RST 打回去，而不是继续走 FIN 流程。

具体到本例，时间线如下（ss -ti + tcpdump -i eth0 -nn 'tcp and port 80' 抓包还原）：

t=0.000s   客户端最后一次请求完成，进入 idle
t=65.000s  Nginx 触发 keepalive_timeout，close() → 发 FIN
t=65.001s  客户端收到 FIN，但 OkHttp 认为连接「仍健康」，标记为 stale
t=65.002s  客户端从池里取出这条连接发新请求 → 发 SYN/数据
t=65.003s  Nginx 内核：socket 已 CLOSED，还有未 ACK 数据 → 回 RST
客户端     → java.net.SocketException: Connection reset by peer

关键点：

FIN 是「礼貌告别」，RST 是「你话没说完我摔门」。你看到的 Connection reset by peer 是 RST，不是 FIN。
跨机房更容易复现：RTT 从 0.3ms 涨到 8ms，「客户端发新请求」与「服务端 FIN」的时间窗口被拉长，碰撞概率从 ~0 涨到 ~1%。
重试一次能成功：因为 RST 后客户端会重建 TCP，第二次走全新连接，自然成功——但重试本身会加重服务端负载、放大雪崩。

三、具体做法：三层修复，按优先级

第 1 层（必做）：让客户端 idle 超时 < 服务端

这是唯一能根治 race 的方法。原则：客户端永远先于服务端关。

// OkHttp 4.12
OkHttpClient client = new OkHttpClient.Builder()
    .connectionPool(new ConnectionPool(10, 30, TimeUnit.SECONDS)) // 30s < Nginx 65s
    .connectTimeout(2, TimeUnit.SECONDS)
    .readTimeout(3, TimeUnit.SECONDS)
    .build();

# 服务端 Nginx
keepalive_timeout 65s;
# 反代到 Tomcat 侧
proxy_keepalive 32;
proxy_keepalive_timeout 60s;   # 也要 > 上游 Tomcat

<!-- Tomcat -->
<Connector ... keepAliveTimeout="65000" maxKeepAliveRequests="1000" />

为什么是 30s 而不是 60s：留 35s 的 buffer，即使时钟漂移、GC 停顿、Nginx worker 调度抖动，客户端也一定先关。

第 2 层（强烈建议）：服务端 `maxKeepAliveRequests` 兜底

即使超时配对了，长连接跑久了仍可能因为内核 buffer 碎片、路由表变化等原因出问题。Nginx / Tomcat 都支持请求数上限：

# Nginx：单条 keep-alive 连接最多复用 1000 次就强制关
proxy_max_requests 1000;

<!-- Tomcat -->
<Connector ... maxKeepAliveRequests="1000" />

客户端侧 OkHttp 没有直接的「请求数上限」，但可以在业务层做：每 1000 次请求主动 evictAll() 或换一个新 ConnectionPool。

第 3 层（兜底）：把 RST 当「可重试」，但要幂等

Connection reset by peer 在请求还没发完时发生，是安全的（幂等）；在服务端已处理、响应还没回来时发生，重试会双写。所以：

try {
    return httpClient.newCall(req).execute();
} catch (SocketException e) {
    if (e.getMessage() != null
        && e.getMessage().contains("Connection reset")
        && !requestHadSideEffect) {
        return httpClient.newCall(req).execute(); // 只重试一次
    }
    throw e;
}

不要无脑重试 3 次——这是把 0.7% 的故障放大成 0.7% × 3 的写放大。

四、踩过的坑（反直觉）

ConnectionPool 的 idle 时间不是「连接寿命」。OkHttp 的 ConnectionPool(10, 5min) 意思是「最多 10 条、空闲 5min 淘汰」，不限制单条连接活多久。长连接可能活几个月，中间撞 RST 概率随时间线性涨。
maxKeepAliveRequests=0（Nginx 默认）就是「永不关」。很多线上事故是把「请求数上限」当成「可选项」，其实它是必须项。
跨机房 vs 同城的失败率差 50 倍，本质是 RTT 差 25 倍——race 窗口随 RTT 线性放大。所以同城没问题 ≠ 配置对，一定要用跨机房压测验证。
tcpdump 抓不到 RST 不代表没有 RST：如果抓包点在服务端入口、但 RST 是内核层发出的（不是应用层 close），抓包点选错会漏。要在客户端出口抓，才能看到「我发数据 → 收到 RST」的完整对。
重试成功 ≠ 问题不存在。0.7% 的失败率 × 1800 QPS = 每秒 ~13 次 RST，服务端内核日志里会看到大量 TCP: reset()，这是内核级负载，长期会拖慢整个 node。

五、结论与可复用清单

判定口诀：偶发 Connection reset by peer + 重试一次就好 + 跨机房更严重 → 先查 keep-alive 超时不一致，别急着怀疑网络。

最小修复清单（按优先级）：

客户端 idle 超时 = 服务端超时 × 0.5（留 buffer）
服务端 maxKeepAliveRequests = 1000（Nginx / Tomcat / Envoy 全都要配）
客户端只对「请求未完成」的 RST 重试 1 次，且必须幂等
跨机房压测：至少跑 30min，看 ss -ti 的 retrans 和应用层 reset 计数
监控：把 Connection reset by peer 单独打点，阈值 > 0.1% 告警

一句话：keep-alive 是「双方约定」，不是「单方声明」；谁先关、关几次、怎么关，三个都要对齐，否则 TCP 内核会替你「关」，只是方式不体面。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。