Go Transport 每主机连接上限怎样导致排队

Go Transport.MaxConnsPerHost 设置的是每主机总连接数上限，包含拨号中、活动和空闲连接。没有可用连接且数量达到上限时，新拨号需要等待；因此并发请求可能在获得连接之前就变慢，而不是全部时间都花在上游处理上。

排队不是只由这个数字决定：连接能否复用、响应体是否释放、协议和共享 Transport 的方式都会改变现象。下面以本地 HTTP/1 小实验解释，不运行代码、不报告实测数据。官方参数地址：https://pkg.go.dev/net/http#Transport。

先限定同一个 Transport 与 HTTP/1

先保证多个请求确实共享同一个 Transport、访问同一地址。两个 Client 使用同一 Transport 时共享该池；每个请求都新建 Transport，则是在建立独立的池，无法用一个池的上限解释全部请求。

本例选择 httptest.NewServer 提供的明文 HTTP/1 服务，返回很小的正文。在 HTTP/1 的常见非流水线使用方式中，一条连接不能同时供多个普通请求任意并行使用；当活动连接占满可用数量，其他请求需要等待复用机会或拨号名额。HTTP/2 一条连接可以承载多个流，所以连接上限不是请求并发数上限，不能直接拿本例的观察方式套过去。

配置连接上限而不是空闲池上限

正文只围绕 MaxConnsPerHost；其他字段用于说明不能混淆的职责。增大空闲连接保留数量，不能直接取消总连接上限造成的拨号等待。反过来，0 表示不限制，也不意味着网络、系统和上游可以无限承载请求。

若已有空闲连接能立即复用，就不必仅因计数已达到上限而等待新增拨号。所谓“每主机”也不要机械理解成一个域名对应一个 IP 的全局配额：当前实现的连接分组涉及连接方式、代理、协议和地址。本文无代理、同一个本地 URL，故意避免这些混杂因素。

写一个可观察连接获取的小实验

将完整程序存为 main.go，读者可在独立目录自行运行。它只有六个请求、一个本地测试服务，共享上限为 2 的 Transport。500 毫秒是代码设置的服务等待条件，不是实测网络耗时；5 秒是本例时间预算，不是生产推荐。

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "net/http/httptest"
    "net/http/httptrace"
    "sync"
    "time"
)

func main() {
    // 本地明文测试服务使用 HTTP/1，延迟仅用于构造观察条件。
    server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        timer := time.NewTimer(500 * time.Millisecond)
        defer timer.Stop()
        select {
        case 

启动通道让请求在相近条件下开始，但 goroutine 调度和连接分配顺序不保证按 id 排列。程序不会向第三方服务发请求。日志回调只使用固定请求 id、固定开始时刻和回调参数，不在并发 trace 回调之间共享可写时间变量。

如果响应读取成功并关闭，连接有机会继续服务等待请求；若复用失败，Transport 可能需要其他可用名额拨号。实际日志不能据代码直接预写成“恰好三批、每批两条、耗时固定”，本文没有提供这样的伪输出。

区分等连接与等响应的耗时

GetConn 在创建连接或从空闲池获取连接之前触发，即使池里已有可用连接也会触发；GotConn 表示成功获得连接。二者附近的等待值得观察，但它可能包含连接池等待、DNS、TCP 或 TLS 等活动，并非纯队列计时器。

本例打印“从请求启动到 GotConn”的耗时，还包含调用准备和调度。结合 ConnectStart、ConnectDone 观察拨号是否发生，再看是否复用以及请求完成时间，才更接近判断原因。连接复用且获得连接仍较晚，在本例约束下支持“连接资源等待”的解释；它本身不是证明所有线上慢请求都由上限引起。

请求失败时可能没有 GotConn 回调，应以 Do 返回的错误记录失败，不能把缺少回调算成零等待。httptrace 回调也可能从不同 goroutine 调用；扩展记录器时应保护共享状态。

改变一个变量再解释差异

读者自行对照时，保持服务等待、请求数量、协议与释放逻辑不变，只把连接上限从 2 调整到 6。若连接获取等待减少，说明原上限可能是该实验的限制条件；但服务处理、CPU 与调度也影响总耗时，不能据此推导普遍的倍数提升。

再尝试更短的请求时间预算时，一些请求可能在获得连接前就超时。连接上限只限制连接数量，不限制排队请求数量；它不是完整的背压机制。应用仍需控制提交的并发工作和等待预算，本文不扩展另一个队列实现。

线上调整时还要先确认协议、共享池和响应体释放情况。若上游本身负载高，增大连接数可能把更多压力推过去，并不保证提高吞吐。

释放响应体并保存判断清单

Client.Do 返回响应，不代表响应体已经消费完。HTTP/1 下正文未读完或未关闭，会影响连接复用与后续请求获取连接。小响应读到 EOF 后及时关闭，是本例完整释放方式；不要为追求复用对无限流或未知大响应无条件读到 EOF。

本例等待全部 goroutine 结束，再由 defer 清理空闲连接与本地测试服务。CloseIdleConnections 只关闭空闲连接，不是强制终止正在使用的全部连接，因此不能用它来“清掉所有排队请求”。长期服务应复用 Client 与 Transport，不每请求关闭整池。

• 确认请求共用同一 Transport，并确认目标地址与代理配置。
• 区分总连接上限、空闲池容量和请求并发限制。
• 确认协议，HTTP/2 流并发不能简单等同于连接数。
• 及时处理响应体，记录获取连接与请求失败，不只看总耗时。
• 单变量调整配额，保留上游承载边界，不声称必然提升吞吐。

MaxConnsPerHost 为 1，会把所有请求都串行吗？

不能无条件这么说。HTTP/1 在本例约束下会明显限制同时占用的连接；HTTP/2 的多流并发并不由一条连接数量直接决定。

设置上限后等待是否会立即报错？

达到限制时新增拨号等待，不是立即拒绝所有新请求。请求可因自身取消、时间预算或其他错误结束，不能把配额当作立即拒绝策略。

为什么加大 MaxIdleConnsPerHost 后仍然慢？

它只涉及空闲连接保留；如果活动连接占满总上限，或者上游响应慢、正文释放晚，仍可能等待。

相关资料：https://pkg.go.dev/net/http#Transport；https://pkg.go.dev/net/http/httptrace#ClientTrace；https://go.dev/src/net/http/transport.go。先把“获得连接之前”和“获得连接之后”的问题拆开，再决定是否调整连接配额。