Golang如何实现HTTP长连接_Golang HTTP Keep-Alive实现_网络技术

Go的http.Transport默认启用Keep-Alive，但需服务端配合；常见断连源于服务端关闭、请求体未读完或超时设置不当；调优关键参数包括MaxIdleConnsPerHost、IdleConnTimeout和ResponseHeaderTimeout。

不需要额外配置，Go 标准库的 http.DefaultClient 和默认 http.Transport 已开启连接复用。只要服务端也支持（返回 Connection: keep-alive 且未显式关闭），底层 TCP 连接就会被缓存并复用。

关键点在于：Keep-Alive 是双向行为，客户端和服务端必须都配合。常见误判是看到请求头没带 Connection: keep-alive 就认为没启用——其实 Go 1.12+ 默认不显式发送该 header，但依然会复用连接。

http.Transport.MaxIdleConns：控制所有 host 共享的最大空闲连接数，默认为 100
http.Transport.MaxIdleConnsPerHost：单个 host 最大空闲连接数，默认为 100
http.Transport.IdleConnTimeout：空闲连接保活时间，默认 30s（超过则关闭）
http.Transport.TLSHandshakeTimeout 和 http.Transport.ResponseHeaderTimeout 也会影响长连接稳定性

现象往往是：连续发多个请求，Wireshark 显示每次都是新 TCP 握手，或 netstat 看不到复用的 ESTABLISHED 连接。大概率不是 Go 没开 Keep-Alive，而是以下任一情况触发了连接提前关闭：

服务端返回了 Connection: close header（比如 Nginx 默认在 HTTP/1.0 下这么做，或设置了 keepalive_timeout 0）
服务端主动关闭了空闲连接（如 Apache 的 KeepAliveTimeout 设得太短）
客户端请求中手动设置了 Connection: close（例如用 req.Header.Set("Connection", "close")）
请求体未读完（resp.Body 没 Close() 或没 io.Copy(ioutil.Discard, resp.Body)），导致连接无法归还到 idle pool
HTTP/2 被协商启用后，Keep-Alive 概念弱化（连接天然复用），但某些代理会降级到 HTTP/1.1 并破坏复用逻辑

不要只看 header，直接观察底层连接行为更可靠：

立即学习“go语言免费学习笔记（深入）”；

用 curl -v 发两次请求，看第二条是否出现 * Connection #0 to host xxx left intact
在 Go 客户端加日志：设置 http.Transport.DialContext 包裹原 net.DialContext，打印每次新建连接的地址和时间戳
抓包过滤 tcp.flags.syn == 1，连续请求间无 SYN 包即复用成功
检查 http.Transport.IdleConnTimeout 是否远小于服务端的 keepalive timeout（比如服务端设了 60s，客户端却用默认 30s，连接总在复用前被回收）

一个小技巧：临时把 IdleConnTimeout 改成 5 * time.Minute，再压测对比连接数变化，能快速定位是不是超时导致的“假断连”。

默认值适合一般场景，但面对每秒数百请求、大量后端服务调用时，容易因连接池不足导致新建连接飙升，甚至 dial tcp: too many open files 错误：

最常被忽略的一点：http.Transport 是有状态的，一旦开始使用就不该再修改其字段（如运行时改 MaxIdleConns 不生效）。初始化后就固定配置，后续靠压测调整。