Go http.Server.ReadHeaderTimeout 怎样防止慢请求头

Go HTTP 服务遇到“客户端连上了，却迟迟发不完请求头”时，最直接的处理是给 http.Server.ReadHeaderTimeout 设置一个明确的正数，例如 3*time.Second。它只约束请求头读取阶段；请求体、响应写入和 Keep-Alive 空闲等待仍要看其他字段。这样可以收敛慢请求头占用的连接，而不会把所有慢请求都粗暴地当成同一种超时。

把 ReadHeaderTimeout 放进显式的 http.Server 配置

不要直接使用 http.ListenAndServe 的快捷入口来承载生产超时策略，先构造一个 http.Server，把字段写在同一处，方便审查和交接。下面的配置只演示请求头保护，其他超时按业务阶段分别填写：

package main

import (
    "log"
    "net/http"
    "time"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
        // 头部读取已经完成，Handler 只处理业务响应。
        w.WriteHeader(http.StatusNoContent)
    })

    server := &http.Server{
        Addr:              ":8080",
        Handler:           mux,
        ReadHeaderTimeout: 3 * time.Second, // 限制请求头的读取窗口。
        ReadTimeout:       15 * time.Second, // 覆盖整个请求读取阶段的总预算。
        WriteTimeout:      10 * time.Second, // 限制响应写入阶段，按接口调整。
        IdleTimeout:       60 * time.Second, // 限制 Keep-Alive 等待下一请求。
        MaxHeaderBytes:    1 

这里的关键不是“3 秒一定正确”，而是把策略从零值变成可解释的配置。对一个正常客户端来说，3 秒应覆盖请求行和请求头的传输；对明显分段发送的连接，它则提供一个明确的回收窗口。

分清请求头超时与请求体、写响应、空闲连接

几个字段的名字相近，但保护的阶段不同。Go 文档说明，ReadHeaderTimeout 读取完请求头后会重置连接读取 deadline；它为零时使用 ReadTimeout，如果回退链路仍是零或负数，则没有对应的读取超时。

因此，Handler 里读取 r.Body 很慢，并不能靠 ReadHeaderTimeout 解决；反过来，客户端连请求头都没有发完时，Handler 也还没有机会执行。先按阶段定位，才能避免把超时值不断调大。

用慢速请求头验证连接是否被及时收敛

验证时只需要制造“请求头尚未结束”的连接，不必把它误写成真实攻击或运行截图。下面的 Go 小程序分两次写入请求头，中间等待超过服务端阈值；它的目的只是观察连接是否在读取窗口内被关闭：

package main

import (
    "fmt"
    "net"
    "time"
)

func main() {
    conn, err := net.DialTimeout("tcp", "127.0.0.1:8080", time.Second)
    if err != nil {
        panic(err)
    }
    defer conn.Close() // 验证结束后释放测试连接。

    fmt.Fprint(conn, "GET /healthz HTTP/1.1\r\nHost: localhost\r\n")
    time.Sleep(4 * time.Second) // 故意超过服务端的 3 秒请求头窗口。
    _, err = fmt.Fprint(conn, "Connection: close\r\n\r\n")
    if err != nil {
        fmt.Printf("header write stopped: %v\n", err)
        return
    }
    fmt.Println("header completed")
}

预期是慢连接在头部完成前已经被服务端关闭，后续写入可能得到网络错误，也可能只表现为对端提前断开。不要用“必须返回 408”作为唯一判断；连接级 deadline 的结果受协议阶段、客户端行为和网络栈影响。对照发送完整请求的客户端，确认正常请求仍能进入 /healthz，才算验证了保护范围。

结合头部大小、TLS 和生产流量校准参数

参数校准先看真实请求头的形成方式：认证头、Cookie 和链路追踪字段较多时，跨地域客户端需要更宽的窗口；内网服务、头部短且连接数高时，可以更积极地收敛。MaxHeaderBytes 负责大小，不能用更短的时间代替它。

还要注意 TLS 握手：Go 的服务器实现会在 TLS 握手相关阶段综合考虑正数的 ReadHeaderTimeout、ReadTimeout 和 WriteTimeout，因此过小的值可能把慢握手误判为头部问题。生产中建议记录超时关闭、431 头部过大和正常请求三类指标，再按客户端网络与头部大小分布做灰度调整。

• 先显式设置 ReadHeaderTimeout，再决定是否需要更大的 ReadTimeout 总预算。
• 头部大小由 MaxHeaderBytes 管，响应写入由 WriteTimeout 管，Keep-Alive 由 IdleTimeout 管。
• 任何值都要和正常客户端的最慢网络、TLS 握手以及认证头长度一起验证。

常见问题

ReadHeaderTimeout 为 0 是不是表示立即超时？

不是。它为零时会使用 ReadTimeout；如果 ReadTimeout 也没有正值，则请求头没有独立的读取时间上限。

它能限制上传请求体的速度吗？

不能。请求头读完后，Handler 才可能读取 r.Body；上传阶段需要单独设计整体读取预算或业务层的请求体策略。

为什么慢请求不一定得到固定的 408？

因为这里首先是连接读 deadline 到期，客户端可能观察到 EOF、连接关闭或写入错误。判断配置是否生效，应结合服务端指标、日志和完整请求对照，而不是只看一个状态码。