Golang HTTP客户端与服务端无法维持可靠长连接问题求助

该问题是HTTP长连接（keep-alive）空闲超时的时序竞态导致，核心是服务端和客户端的空闲连接回收逻辑没有对齐阈值：

具体触发逻辑 #

• Go标准库http.Server的默认规则：如果没有显式配置IdleTimeout参数，会直接复用ReadTimeout的值作为空闲连接的最大存活时间，你代码中服务端ReadTimeout设为5秒，意味着空闲超过5秒的长连接会被服务端主动关闭。
• 客户端请求间隔正好是5秒，刚好卡在服务端空闲连接的回收阈值上：客户端等待5秒后发起下一次请求的时间点，正好是服务端要关闭对应空闲连接的时间点，此时会出现两边同时操作连接的竞态：
  • 客户端刚将请求写入连接，服务端的FIN包刚好到达，触发EOF、connection reset by peer错误
  • 客户端从连接池取出连接的瞬间，服务端刚完成连接关闭，触发http: server closed idle connection错误

你用到的规避方案生效原因 #

• 设置req.Close = true、禁用客户端keep-alive：每次请求新建独立连接，不使用长连接池，自然不会出现从池子里取出已被服务端关闭的连接的问题，缺点是会额外产生TCP三次握手开销。
• 将请求间隔调整为1秒：1秒远小于服务端5秒的空闲超时阈值，连接不会被服务端判定为空闲回收，因此不会触发竞态。

最优解决方案（不需要禁用长连接） #

不需要强制每次新建连接，只要对齐两边的空闲超时阈值即可：

1. 服务端显式配置IdleTimeout，数值要大于客户端的请求间隔，比如你客户端请求间隔为5秒，可以将服务端IdleTimeout设为10秒，给连接回收留足够的缓冲时间：

srv := &http.Server{
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 10 * time.Second,
    IdleTimeout:  10 * time.Second, // 新增显式配置
    Addr:         ":9090",
    Handler:      mux,
}

2. 客户端侧同步配置Transport的IdleConnTimeout，数值要略小于服务端的IdleTimeout，比如服务端IdleTimeout设为10秒，客户端可以设为7~8秒，保证客户端先淘汰空闲连接，永远不会从池子里拿到服务端已经关闭的连接：

client := &http.Client{
    Timeout: 1 * time.Second,
    Transport: &http.Transport{
        IdleConnTimeout: 7 * time.Second, // 小于服务端IdleTimeout
    },
}

3. 如果你的POST请求是幂等的，也可以配置客户端开启错误重试逻辑，进一步降低偶发错误的影响。

内容的提问来源于stack exchange，提问作者Jonas Bergner