Go HTTP/2HTTP/2 流并发受限时请求排队怎么办

Go HTTP/2 请求在并发升高后出现“前一批完成，后一批才开始”的排队现象，先不要把它归咎于 goroutine 数量不足。最常见的边界是服务端在 SETTINGS 帧中公布了 SETTINGS_MAX_CONCURRENT_STREAMS，客户端已经用满这条连接允许的并发流；如果客户端又选择严格遵守跨连接上限，后续请求就会等待。另一种可能是流已经创建，但 Handler、连接池或下游服务变慢，表现相似却不是 HTTP/2 流上限。

官方文档：https://pkg.go.dev/net/http

先确认请求是否使用 HTTP/2，再把“每连接流上限”“客户端是否允许开新连接”和“后端处理耗时”分开看。服务端调高上限只能解决第一类约束，不能替代数据库或下游接口治理。

• 看到固定批次排队：优先检查对端公布的最大并发流数和客户端等待策略。
• 服务端修复：配置 http.Server.HTTP2.MaxConcurrentStreams，它针对每个客户端连接。
• 客户端修复：配置 StrictMaxConcurrentRequests，在严格限流与新增连接之间做选择。

先确认排队发生在哪一层

故障复盘可以从三个时间点开始记录：请求进入客户端、请求真正发出、服务端 Handler 开始执行。如果等待主要发生在客户端发出之前，且并发数接近某个稳定阈值，才像是流配额或连接选择；如果 Handler 已经开始执行但耗时变长，应继续看下游依赖、CPU、连接池和响应体读取。

在 Go 中可先记录响应协议和请求耗时，不要只看最终状态码。HTTP/2 的多个请求共享一条连接，看到连接数少并不能证明请求没有并发；反过来，HTTP/1.1 连接复用、Transport 的连接限制也可能制造相似的等待。

理解 SETTINGS_MAX_CONCURRENT_STREAMS 的作用范围

SETTINGS_MAX_CONCURRENT_STREAMS 是 HTTP/2 对端告诉你“同一条连接最多同时保持多少个流”的约束。它不是全局请求数，也不是服务端所有 Handler 的总并发。Go 的 HTTP/2 客户端状态中，活跃流和等待中的请求是不同概念；当已发送请求超过对端公布的上限时，超出的请求会等待已有流结束。

因此，不能仅凭“服务端有很多 CPU”就判断流上限应该无限增大。上限提高后，每条连接可能同时持有更多请求、响应体和下游资源；如果真正瓶颈在数据库连接池，排队只是从 HTTP/2 层转移到了数据库层。

服务端怎样调整每条连接的流上限

使用较新的 net/http 配置时，把上限放在 Server.HTTP2 中。示例只展示配置关系，证书、路由和部署方式按现有服务保留：

package main

import "net/http"

func newServer(handler http.Handler) *http.Server {
	return &http.Server{
		Addr:    ":8443",
		Handler: handler,
		HTTP2: &http.HTTP2Config{
			// 这是每条客户端连接允许同时打开的流数，不是全局请求数。
			MaxConcurrentStreams: 128,
		},
	}
}

这里的 128 只是示例值，不能直接当作通用最佳值。调大前要把 Handler 的最大耗时、单请求内存、下游连接池和负载峰值一起估算；如果服务需要限制全局并发，应在应用层使用信号量或队列，而不是把每连接流上限当作全局闸门。

如果项目仍直接使用 golang.org/x/net/http2 的旧配置，字段名同样是 MaxConcurrentStreams，但应先确认 Go 版本和依赖版本的迁移路径。当前官方文档建议普通用户优先使用 net/http 原生 HTTP/2 能力。

客户端要在严格排队和新增连接之间做选择

当客户端收到服务端的流上限后，真正决定“是否一直排队”的是 Transport 的 HTTP/2 策略。较新的 net/http 可以这样表达严格模式：

package main

import "net/http"

func newClient() *http.Client {
	transport := http.DefaultTransport.(*http.Transport).Clone()
	transport.HTTP2 = &http.HTTP2Config{
		// true 表示跨连接也尊重服务端并发边界，超出时等待已有请求完成。
		StrictMaxConcurrentRequests: true,
	}
	return &http.Client{Transport: transport}
}

严格模式适合需要控制对端压力、连接数或请求顺序成本的场景；代价是并发超过上限后，RoundTrip 可能等待。若业务允许额外 TCP/TLS 连接，且服务端按连接分摊流上限，可以考虑关闭严格模式，让 Transport 在已有连接达到上限时建立额外连接。不过这会增加握手、连接管理和对端负载，不能把它当成无限并发开关。

用四个指标确认修复没有掩盖瓶颈

最终确认至少要同时保存协议版本、并发请求数、活跃连接数、Handler 耗时和下游资源占用。若只把 MaxConcurrentStreams 从 64 调到 256，却没有观察数据库池和内存，可能只是把可见排队推迟到更深的一层。

常见问题

MaxConcurrentStreams 是全局并发限制吗？

不是。它描述每条 HTTP/2 连接允许的并发流数；全局限制需要应用层或资源池层的独立控制。

把服务端上限调大就一定不排队吗？

不一定。客户端严格策略、Transport 连接条件、Handler 耗时和下游容量都可能继续产生等待。

为什么关闭严格策略后请求变快了？

可能是客户端使用了额外连接，绕开了单连接流上限；这并不证明后端容量充足，需要继续观察连接数和依赖负载。

这类故障的修复顺序应保持清晰：先证实 HTTP/2 和等待层次，再决定服务端每连接上限，最后选择客户端是否跨连接严格排队。只有指标显示资源仍有余量时，调高并发才是修复，而不是把排队位置向后移动。