Go HTTP/2 怎样限制并发流

如果一个 Go HTTP/2 服务在单条连接上同时承载很多请求，真正要限制的通常不是“所有请求的总数”，而是同一个客户端连接可以保持的并发流数量。Go 1.24 及以后可以把这个边界写进 http.Server.HTTP2，使用 HTTP2Config.MaxConcurrentStreams 发布服务端限制。

先记住一个容易混淆的结论：MaxConcurrentStreams 是每个 HTTP/2 连接的流上限，不是全局 handler 并发闸门。想限制所有连接共享的业务并发，仍应在 handler、信号量或连接池层单独设计。

先把“并发流”与“全局并发”分开

HTTP/2 把多个请求复用到一条连接上，每个正在处理的请求对应一个 stream。服务端通过 SETTINGS 向对端声明 SETTINGS_MAX_CONCURRENT_STREAMS。当客户端已经占满这条连接的额度，后续请求会受到 HTTP/2 连接协商和实现策略的影响，而不是简单地排进一个全局 Go 队列。

因此排查时先问三个问题：限制是想作用于单条连接，还是所有客户端连接的总量；服务是否真的协商成 HTTP/2；客户端是否因为连接复用或新建连接而观察到不同表现。

用 Server.HTTP2 设置服务端上限

在 Go 1.24+ 的标准库中，可以把配置挂到 http.Server.HTTP2。下面示例把每条 HTTP/2 连接的并发流上限设为 64：

package main

import (
	"log"
	"net/http"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/work", func(w http.ResponseWriter, r *http.Request) {
		// 这里模拟一个占用 stream 的处理入口；业务并发仍需单独治理。
		w.WriteHeader(http.StatusNoContent)
	})

	server := &http.Server{
		Addr:    ":8443",
		Handler: mux,
		HTTP2: &http.HTTP2Config{
			// 该值约束每条 HTTP/2 连接可同时打开的 stream 数。
			MaxConcurrentStreams: 64,
		},
	}

	// 生产环境应在此处补齐证书、优雅退出和错误分类处理。
	if err := server.ListenAndServeTLS("server.crt", "server.key"); err != nil {
		log.Fatal(err)
	}
}

配置的关键不是数字本身，而是它的作用域：一个客户端如果建立了多条 HTTP/2 连接，每条连接都有自己的流额度。把这个值调小可以限制单连接的并发压力，但不能代替服务级限流。

零值、版本和旧配置要先确认

MaxConcurrentStreams 为零时，标准库会采用至少 100 的默认值。零值不是“完全禁止并发流”，也不是“无限制”。如果业务需要更小的硬边界，必须显式设置正整数；如果业务依赖更大的额度，也要结合单请求资源消耗重新评估。

这个字段属于较新的 net/http.HTTP2Config，写文章或升级代码时要先确认编译环境。旧项目如果仍然直接配置 golang.org/x/net/http2.Server，不要把两套配置结构混写；迁移时应按当前 Go 版本的标准库文档逐项替换，并确认实际启用的 HTTP/2 实现。

还有一个常见误区：流上限限制的是并发 stream，不等于正在运行的 goroutine 数，也不等于响应体字节数。慢请求、上传大小和业务队列需要分别配置。

不要把客户端 Transport 开关当成服务端限制

HTTP2Config 也可以挂到客户端 Transport，但字段语义不同。StrictMaxConcurrentRequests 用来决定客户端面对单连接额度时，是否严格跨所有连接等待：打开时更接近一个跨连接的请求并发限制；关闭时，Transport 可能在已有连接达到额度后再打开额外连接。

它只属于 Transport，不是服务端 MaxConcurrentStreams 的替代品。服务端应设置 http.Server.HTTP2.MaxConcurrentStreams；客户端是否新建连接，则应在客户端 Transport 侧单独判断。

按三层清单观察配置是否生效

1. 协议层：确认请求链路确实使用 HTTP/2，不能把 HTTP/1.1 的连接池现象直接归因于 stream 上限。
2. 连接层：观察客户端是否复用一条连接，还是在达到单连接额度后建立了新连接。多连接会让“每条连接 64 条”看起来不像“全局最多 64 条”。
3. 业务层：如果目标是保护数据库、CPU 或下游 API，应在 handler 或资源池层增加独立的并发控制，并把等待、拒绝和超时记录下来。

用这三层证据排查，通常能快速判断是 HTTP/2 没启用、连接作用域理解错了，还是把协议参数误当成了业务限流器。

小结：这样设置才不会混淆边界

• Server.HTTP2.MaxConcurrentStreams 控制每条服务端 HTTP/2 连接的 stream 上限。
• 零值会使用至少 100 的默认值；全局 handler 并发要另行控制。
• Transport.HTTP2.StrictMaxConcurrentRequests 是客户端跨连接等待策略，不是服务端配置。

常见问题

设置 64 后，服务端是不是最多只能处理 64 个请求？
不是。它针对单条 HTTP/2 连接；多个客户端或多条连接可以分别拥有额度。若要限制总请求数，需要额外的服务级并发控制。

为什么把值设为 0 后仍然有很多并发流？
零值会回到标准库默认值，并非禁用并发。需要明确边界时请设置正整数，并同时确认连接是否被复用。