Go HTTP Server 怎样关闭 Keep-Alive 连接复用

我在把一个 Go HTTP 服务放到资源比较紧的环境时，遇到过一个很容易混淆的问题：明明只是想让服务端不要复用连接，却先去改客户端的 Transport。真正控制服务端 Keep-Alive 的入口在 http.Server 上，最直接的写法是 srv.SetKeepAlivesEnabled(false)。

官方资料：https://pkg.go.dev/net/http#Server.SetKeepAlivesEnabled

Go 的 HTTP Server 默认开启 Keep-Alive。要关闭服务端连接复用，应创建一个自定义 http.Server，再调用 SetKeepAlivesEnabled(false)。这个开关只解决服务端连接生命周期问题，不能替代客户端 Transport 的连接池配置，也不应把 HTTP/1 的行为直接套到 HTTP/2。

先分清这个开关到底管哪一端

Keep-Alive 这个词同时出现在客户端和服务端语境里，所以配置位置经常被写错。服务端接收请求时，开关属于 http.Server；客户端发请求时，连接复用通常由 http.Transport 负责。两者都可能出现“连接没有马上断开”，但它们面对的连接方向不同。

如果你的问题是“这个 Go 服务端不要让 HTTP/1 请求继续占用可复用连接”，下面的 Server 方法就是正确起点。

在自定义 Server 上关闭 Keep-Alive

http.ListenAndServe 的快捷写法不会给你留下一个可配置的 Server 对象。先创建自定义 Server，再在启动前关闭 Keep-Alive：

package main

import (
	"log"
	"net/http"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
		// 健康检查只返回一个简短结果，便于上游判断服务是否可用。
		w.WriteHeader(http.StatusNoContent)
	})

	srv := &http.Server{
		Addr:    ":8080",
		Handler: mux,
	}

	// 关闭服务端 Keep-Alive；该设置作用于这个 Server 接收的连接。
	srv.SetKeepAlivesEnabled(false)

	// ListenAndServe 结束时总会返回错误，生产代码应记录启动或关闭原因。
	if err := srv.ListenAndServe(); err != nil {
		log.Printf("HTTP server stopped: %v", err)
	}
}

关键点有三个。第一，必须操作真正用于 ListenAndServe 或 Serve 的那个 Server 实例。第二，传入 false 才是关闭，默认状态相当于开启。第三，这个调用改变的是服务端策略，不会替客户端决定是否缓存或复用连接。

HTTP/1 下，关闭后会发生什么

Go 官方文档把 SetKeepAlivesEnabled 定义为 HTTP Keep-Alive 的服务端总开关，并说明默认始终开启。源码实现中，传入 false 后会记录禁用状态，并调用关闭空闲连接的逻辑。对 HTTP/1 来说，可以把它理解成：一个请求完成后，连接不再作为后续请求的长期复用通道。

这不等于“每个请求一到就立刻中断”。当前正在处理的请求仍要按正常流程返回；真正受到影响的是请求完成之后连接是否继续留作空闲连接。客户端下一次请求如果没有可复用的连接，就需要重新建立 TCP 连接，若是 HTTPS 还会重新经历 TLS 建连成本。

因此，这个开关适合资源非常有限、连接复用本身带来管理压力，或者服务已经进入停机过程的场景。对于普通高并发服务，默认复用通常更节省握手和系统调用开销，不能为了“看起来连接更干净”就常态关闭。

func buildServer(handler http.Handler) *http.Server {
	srv := &http.Server{
		Addr:    ":8080",
		Handler: handler,
	}

	// 只有明确需要短连接策略时才关闭；否则保留默认 Keep-Alive。
	if shouldUseShortConnections() {
		srv.SetKeepAlivesEnabled(false)
	}
	return srv
}

func shouldUseShortConnections() bool {
	// 示例只表达配置决策点，真实项目应从受控配置读取并记录变更原因。
	return false
}

把 HTTP/2 单独看待

这里是最容易过度推断的地方。HTTP/1 的 Keep-Alive 通常围绕一条连接是否在响应后继续空闲复用来讨论；HTTP/2 则有自己的多路复用和连接管理语义。Go 官方源码在关闭 Keep-Alive 的实现旁明确留下了“关闭 HTTP/2 连接的空闲处理”边界，因此不能把“HTTP/1 空闲连接会被关闭”直接改写成“所有 HTTP/2 连接都会立刻断开”。

如果服务通过 TLS 启用 HTTP/2，应该先确认实际协议，再决定是否需要更具体的协议配置。不要用一个 HTTP/1 客户端的观察结果去证明 HTTP/2 的连接行为，也不要仅凭服务端调用了一个方法就宣称所有长连接已经即时消失。

停机时，短连接开关不是 Shutdown 的替代品

有些项目会在收到退出信号后调用 SetKeepAlivesEnabled(false)，这是一个可以理解的辅助手段，但它不等于优雅停机。优雅停机仍然应该关闭监听器、等待活跃请求返回，并为等待过程设置上下文期限。

func stopServer(srv *http.Server) error {
	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel() // 确保超时计时器和关联资源及时释放。

	// Shutdown 负责停止接收新连接并等待活跃请求回到可关闭状态。
	return srv.Shutdown(ctx)
}

如果要使用这段代码，需要在导入列表中加入 context 和 time。实践中可以把 “关闭新的 Keep-Alive 复用” 和 “等待已有请求完成” 作为两个动作理解：前者改变连接策略，后者负责服务生命周期。

最后用一张清单做决定

• 问题是服务端响应后的连接复用：配置实际运行的 http.Server。
• 问题是客户端连接池或客户端空闲连接：查看客户端 Transport。
• 只是普通 HTTP 服务：优先保留默认 Keep-Alive，避免额外握手开销。
• 资源极紧张或正在停机：可以关闭服务端 Keep-Alive，再结合 Shutdown 管理生命周期。
• 链路使用 HTTP/2：单独确认协议语义，不把 HTTP/1 的结论直接外推。

常见追问

调用 SetKeepAlivesEnabled(false) 后，正在处理的请求会被立即断开吗？

不应这样理解。它主要影响 Keep-Alive 的后续复用与空闲连接处理，当前请求仍需要按服务端处理流程完成。

设置了服务端开关，为什么客户端还显示连接池配置？

因为客户端和服务端各自拥有连接管理策略。服务端关闭复用，不代表客户端的 Transport 配置字段会消失；最终连接能否继续使用，还要看双方协议和状态。

SetKeepAlivesEnabled(false) 能代替 Server.Shutdown 吗？

不能。前者是 Keep-Alive 策略，后者是服务生命周期控制。需要停机时，应该用 Shutdown 处理监听器和活跃请求的收尾。