Go语言内置的net/http超时设置防止连接耗尽

写Go语言网络服务的人，十有八九都踩过一个坑：服务跑着跑着，突然就无响应了，不报错也不崩溃，就是连不上。查半天日志，发现大量goroutine阻塞，文件描述符被打满。根因往往直指一处——没有给"net/http"的Server设置超时。Go标准库的"net/http"功能强大，但默认的零值配置在生产环境里就是一颗定时炸弹。连接可以永远挂着，慢客户端能把你的整个服务拖垮。

问题核心在于"http.Server"结构体里有四个关键的Timeout字段，它们分别控制着连接生命周期的不同阶段。如果不设置，Go的HTTP服务器会无限期等待，直到客户端主动断开或操作系统强行回收。这在公网环境下尤其危险，因为任何网络波动、恶意慢速攻击、甚至客户端崩溃，都会导致服务端资源被慢慢耗尽。

"ReadTimeout"控制的是从连接被接受开始，到读取完整个请求体（包括头部和Body）的最大时长。这个超时涵盖了客户端发送请求的整个阶段。如果客户端在这个时间内没能把请求完整发过来，服务端就会直接关闭连接。

举个例子，假设你设置"ReadTimeout"为5秒。客户端建立TCP连接后，必须在5秒内完成发送HTTP请求头，并且如果请求带有Body，也得在这5秒内全部发送完毕。这对于防止慢速攻击特别有效——攻击者建立连接后，每隔几秒才发一个字节，企图长期占用连接。有了ReadTimeout，这种伎俩最多只能撑5秒。

实际配置时要注意，ReadTimeout是从连接被Accept的那一刻开始计时的，而不是从收到第一个字节开始。所以如果你的服务需要处理大文件上传，这个值必须设置得足够大，能覆盖客户端在弱网下传完整个文件的时间。一个常见的折中方案是，对于普通API接口设置较短的ReadTimeout（比如10-30秒），而对于上传接口单独调大，或者干脆用不同的Server实例监听不同端口。

"WriteTimeout"限制的是服务端写完整个响应的时间，从读取完请求头之后、准备写响应头开始计时，一直到把响应Body的最后一个字节写入网络缓冲区为止。如果在这个时间内没写完，连接就会被强制关闭。

这个超时很容易被误解。很多人以为WriteTimeout是从开始写第一个字节算起，但实际上它的计时起点是读请求头结束的那一刻。这意味着，如果你的业务处理逻辑耗时很长，WriteTimeout不会把这部分时间算进去——它只管“写”这个动作本身。但这里有个微妙的细节：如果你的Handler在写响应之前做了大量计算，WriteTimeout还没开始计时，但一旦开始写，就必须在限定时间内完成。

对于返回大文件或者流式响应的场景，WriteTimeout必须设置得足够宽松。比如一个视频流接口，可能要持续写几分钟甚至几小时的数据，这时候WriteTimeout就得设成0（表示无限），或者用一个非常大的值。但设为0要谨慎，最好配合其他机制来防止连接泄露，比如在应用层实现心跳检测。

"IdleTimeout"是HTTP/1.1持久连接场景下最重要的参数。它规定了一个空闲连接在被关闭之前可以保持多长时间。所谓“空闲”，指的是连接上没有任何请求正在处理，两端都没有数据传输的状态。

Go的HTTP服务器默认支持Keep-Alive，处理完一个请求后不会立即关闭连接，而是等待客户端复用这条连接发下一个请求。这能显著减少TCP握手开销，提升吞吐量。但问题在于，如果没有IdleTimeout，这些空闲连接会一直占用文件描述符和内存。在高并发场景下，客户端可能因为各种原因不再使用这些连接，而服务端却傻傻地保留着它们。

设置IdleTimeout后，服务端会定期清理超过时限的空闲连接。通常这个值可以设得比ReadTimeout和WriteTimeout大一些，比如60秒到120秒，因为Keep-Alive本身就是为了一段时间内的请求复用。需要注意的是，IdleTimeout的计时是从上一个请求处理完毕开始算的，如果在这期间客户端又发起了新请求，计时器就会重置。

这个字段在Go 1.8版本才加入，但它解决了一个ReadTimeout覆盖不到的痛点。ReadTimeout管的是整个请求的读取，包括Body，而"ReadHeaderTimeout"只限制读请求头的时间。请求头通常很小，应该在极短时间内完成读取。如果客户端建立了连接却迟迟不发请求头，服务端就会一直挂着。

ReadHeaderTimeout的优先级高于ReadTimeout。如果你同时设置了这两个值，读请求头的实际超时时间取两者中较小的那个。这意味着你可以把ReadHeaderTimeout设得很短（比如5-10秒），而把ReadTimeout设得相对长一些来容纳大Body。这样既能快速踢掉只连不发的恶意连接，又不影响正常的大数据量请求。

强烈建议在所有生产服务中都设置ReadHeaderTimeout，哪怕你已经设了ReadTimeout。因为ReadTimeout的计时包含了等待Body的时间，如果Body很大，ReadTimeout可能设得比较长，这就给了攻击者一个窗口期——他们可以建立连接后慢慢发请求头，在ReadTimeout触发前一直占用资源。ReadHeaderTimeout正好堵上了这个漏洞。

理解这四个超时如何协同工作，是正确配置它们的前提。一个HTTP连接的生命周期大致是这样的：

1. 服务端Accept连接，ReadHeaderTimeout和ReadTimeout同时开始计时。

2. 客户端发送请求头，如果在ReadHeaderTimeout内完成，ReadHeaderTimeout停止计时，ReadTimeout继续。

3. 客户端发送请求Body（如果有），必须在ReadTimeout内完成。

4. 服务端读完请求，ReadTimeout停止计时，Handler开始处理业务逻辑。

5. Handler处理完毕，开始写响应，WriteTimeout开始计时。

6. 响应写完，WriteTimeout停止计时，IdleTimeout开始计时。

7. 如果在IdleTimeout内有新请求到来，跳回步骤1，所有计时器重置。

8. 如果IdleTimeout到期，连接关闭。

这个模型里有一个关键点：业务处理时间不受任何超时控制。如果你的Handler卡在数据库查询或者外部RPC调用上，ReadTimeout和WriteTimeout都管不了它。这就是为什么还需要在Handler内部使用"context.Context"来传递超时控制，通过"http.Request.Context()"可以拿到请求上下文，当客户端断开连接时这个Context会被取消，你可以据此中断处理逻辑。

一个经过实战检验的配置模板是这样的：

srv := &http.Server{
    Addr:              ":8080",
    ReadTimeout:       15 * time.Second,
    ReadHeaderTimeout: 5 * time.Second,
    WriteTimeout:      30 * time.Second,
    IdleTimeout:       120 * time.Second,
    Handler:           mux,
}

这个配置的含义是：客户端必须在5秒内发完请求头，15秒内发完整个请求（含Body），服务端必须在30秒内写完响应，空闲连接保留2分钟。对于绝大多数REST API服务，这是一组比较均衡的数值。

常见的反模式包括：只设置ReadTimeout和WriteTimeout，忽略了ReadHeaderTimeout和IdleTimeout；把WriteTimeout设得过大，导致慢客户端长时间占用写缓冲区；把IdleTimeout设成0（无限），在高并发下文件描述符迅速耗尽；或者反过来，把IdleTimeout设得太短（比如几秒），导致Keep-Alive完全失效，每个请求都要重新握手，延迟和CPU开销都上去了。

还有一个容易被忽略的细节：如果你在前面挂了反向代理（比如Nginx），这些超时值需要和代理的超时配置协调。比如Nginx的"proxy_read_timeout"如果比Go服务的WriteTimeout短，Nginx会先断开连接，Go服务写响应时会遇到broken pipe错误。反过来，如果Go服务的ReadTimeout比Nginx的"proxy_send_timeout"短，Go服务会先断开，Nginx那边收到502。这些超时值最好保持一个合理的层级关系：代理层的超时略大于应用层，让应用层先触发超时，这样错误信息更清晰。

Server级别的四个Timeout是粗粒度的全局控制，但实际业务中经常需要接口级别的超时策略。比如某个导出报表的接口允许执行60秒，而其他接口最多10秒。这时候就需要在Handler内部使用Context超时：

func handler(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 10*time.Second)
    defer cancel()
    
    result, err := doSomething(ctx)
    if err != nil {
        http.Error(w, "timeout", http.StatusGatewayTimeout)
        return
    }
    w.Write(result)
}

这里用"r.Context()"作为父Context，当客户端断开连接或Server级别的超时触发时，这个Context会自动取消，你的业务逻辑就能及时感知并退出。自己再包一层WithTimeout，可以实现比Server级别更短（但不能更长）的超时控制。注意，Server级别的超时触发后，"r.Context()"会被取消，但你的Handler代码可能还在执行——Context取消只是一个信号，需要你的代码主动检查并响应。

超时设置能防止单个连接占用过久，但如果攻击者同时建立海量连接，即使每个连接都按时超时，在超时触发前的那段时间窗口里，资源依然可能被打满。所以超时策略需要配合连接数限制使用。Go的"net/http"没有内置连接数限制，但你可以通过自定义Listener来实现：

type limitListener struct {
    net.Listener
    sem chan struct{}
}

func (l *limitListener) Accept() (net.Conn, error) {
    l.sem <- struct{}{}
    conn, err := l.Listener.Accept()
    if err != nil {
        <-l.sem
        return nil, err
    }
    return &limitConn{Conn: conn, release: func() { <-l.sem }}, nil
}

这个模式用带缓冲的channel作为信号量，Accept时获取一个信号，连接关闭时释放。把最大并发连接数控制在一个合理范围内，配合超时设置，才能构建真正健壮的服务。

优雅关闭同样重要。"http.Server"提供了"Shutdown"方法，它不会暴力切断现有连接，而是先关闭所有空闲连接，然后等待活跃连接处理完毕。但如果没有设置超时，活跃连接可能永远处理不完，Shutdown就会一直阻塞。所以Shutdown通常配合一个带超时的Context使用：

ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
    log.Fatal("forced shutdown:", err)
}

这里30秒的超时是给活跃连接的最后期限，超时后还没处理完的连接会被强制关闭。这个值应该大于WriteTimeout，给正在写响应的连接留足时间。

超时配置不是一劳永逸的，需要根据实际运行数据持续调优。关键指标包括：连接被超时关闭的频率、平均请求处理时长、文件描述符使用量、以及goroutine数量。如果发现ReadTimeout触发的频率异常高，可能是客户端网络质量差，或者ReadTimeout设得太短。如果IdleTimeout后连接数下降不明显，检查是否有连接泄露——比如Handler里启动了goroutine但没有正确退出，导致连接一直不进入空闲状态。

Go的"net/http"还提供了"ConnContext"钩子，可以在每个连接建立时注入自定义Context，方便做连接级别的追踪和超时控制。结合"net.Conn"的"SetDeadline"方法，甚至可以实现比Server级别更动态的超时策略，比如根据当前系统负载自动调整超时阈值。

说到底，"net/http"的超时设置是Go服务稳定性的基石。默认的零值不是“没有限制”的慷慨，而是“没有保护”的脆弱。四个Timeout各司其职，覆盖了连接从建立到关闭的全生命周期，但业务处理超时还需要Context来兜底。把这些配置好，你的Go服务才能在公网的惊涛骇浪中站得稳。