如何在 Go 中处理高并发请求下的网络延迟优化

在 Go 语言里搞高并发，很多人想当然地以为 goroutine 一开，延迟就能自动降下来。但现实往往很骨感——Go 本身并不负责降低网络延迟，它只负责执行你的指令。真正决定延迟的，是连接怎么复用、超时怎么设、并发怎么控、协议怎么选这几件事。这些事不改，goroutine 开得越多，延迟反而可能抖得越厉害。

先说结论：问题的根源，大部分时候不在 Go 语言，而在 net/http 库的默认配置和你的使用方式。下面我们逐个拆解。

为什么 http.Client 的默认配置会让延迟飙升

每次随手写个 http.Get() 或者新建一个 http.Client 实例，背后都藏着一座冰山。每发起一次请求，就得走完一次完整的 TCP 三次握手，如果是 HTTPS 还得加上 TLS 协商。这一套流程下来，50 到 300 毫秒就没了。高并发时，大量连接同时争抢本地端口，严重时甚至会直接报 connect: cannot assign requested address，连接都建立不起来。

更隐蔽的问题藏在默认参数的细节里：

• MaxIdleConns 和 MaxIdleConnsPerHost 默认值都是 100，看着够用是吧？但如果你没设置 IdleConnTimeout，空闲连接就永远不会被主动回收，长期占用端口资源，导致连接池实际上成了“僵尸池”。
• ForceAttemptHTTP2 默认是 true，但它只有在 TLS 连接下才生效。如果业务场景是纯 HTTP/1.1，那 HTTP/2 的多路复用优势完全没有，队头阻塞的问题该在还在。
• 最容易被忽略的是 ResponseHeaderTimeout。这个参数如果不显式设置，默认值为 0，意味着无限等待。一旦某个后端响应头卡住，整条连接池里的连接都会跟着“陪绑”，后续请求要么排队等，要么被迫新建连接，延迟自然飙升。

必须调整的 Transport 参数组合

既然默认配置是个坑，那怎么填？下面是一套经过实战检验的组合，特别适合 QPS 在 100 到 1000 之间、调用单一内部 API 的场景：

tr := &http.Transport{
    MaxIdleConns:        100,
    MaxIdleConnsPerHost: 30,
    MaxConnsPerHost:     50,
    IdleConnTimeout:     30 * time.Second,
    DialTimeout:         3 * time.Second,
    TLSHandshakeTimeout: 3 * time.Second,
    ResponseHeaderTimeout: 5 * time.Second,
    ExpectContinueTimeout: 1 * time.Second,
}

这套配置里有几个关键点需要注意：

• MaxIdleConnsPerHost 设成 30 是核心。这个数字应该略高于你对单个下游服务的典型并发请求数。比如你压测时发现并发峰值是 25，那设成 30 就正好，既能保证有富余连接，又不至于浪费资源。
• IdleConnTimeout 设成 30 秒是个不错的平衡点。时间太短，比如 5 秒，连接刚建立就释放，造成频繁重连，反而增加延迟；时间太长，比如 90 秒，连接池会变得“虚胖”，端口耗尽的概率大大增加。
• ResponseHeaderTimeout 必须显式设置，建议不超过 5 秒。这是防止因为某一个慢后端拖垮整条连接的关键防线。

goroutine 并发数不是越多越好

很多人刚开始优化时，第一个念头就是“多加 goroutine”。这是个很天然的直觉，但也很容易跑偏。不加控制地启动几百个 goroutine，大概率会导致本地端口耗尽（net.Dial 失败）、TCP 拥塞丢包，或者直接把下游服务打崩溃。这时候你看到的不是延迟降低，而是长尾毛刺和雪崩式的异常。

正确的做法是给并发踩刹车：

• 用 golang.org/x/sync/semaphore 做限流，比如 sem := semaphore.NewWeighted(50)，每次请求前 sem.Acquire(ctx, 1)。这样能保证并发的请求数量始终在可控范围内。
• 重试机制要用对。只针对临时错误进行重试，比如 net.OpError、context.DeadlineExceeded，或者 HTTP 状态码 502 和 503。所有 4xx 错误都不要重试，那是业务层面的问题，重试只会让问题更严重。
• 只有幂等接口才适合加指数退避重试。如果是非幂等操作，比如 POST /orders，应该在业务层用状态机加异步补偿来做，而不是指望靠 HTTP 重试来掩盖问题。

真正降延迟的替代方案

当你的应用对延迟极其敏感，而且你能控制上下游协议时，可以考虑绕过 net/http 这层：

• 内部服务调用，直接用 gRPC。它基于 HTTP/2 和 Protocol Buffers，序列化之后的体积比 JSON 小 60% 到 80%，加上头部压缩和多路复用，天生就是为低延迟场景设计的。
• 如果场景极简，比如只是固定格式的内部通信，直接用 net.Conn 直连 TCP，省掉 HTTP 解析、状态机、header 构建这些开销，性能会有非常明显的提升。
• 不要在热路径上做 DNS 解析。预解析好域名并缓存 net.IP 值，或者禁用 cgo（设置 CGO_ENABLED=0），避免 getaddrinfo 阻塞 M，是很容易被忽略但效果极好的优化手段。

最后要说的是，延迟毛刺不一定出在 Go 代码里。很多时候问题藏在 MySQL 连接池打满、Redis 的阻塞命令，甚至是容器的 CPU quota 被超额分配。所以，在动手优化之前，最好先用 go tool trace 确认一下：你的 goroutine 到底是卡在 net.Read 上，还是 chan send 上？知道瓶颈在哪，才能对症下药。