本文介绍如何在 go 中准确分离并测量 http 请求中真正的服务器响应时间（即从请求发送完成到响应头接收完毕的耗时），避免 dns 解析、连接建立、tls 握手等客户端网络开销干扰，提供基于自定义 roundtripper 的可复用、生产就绪方案。
本文介绍如何在 go 中准确分离并测量 http 请求中真正的服务器响应时间（即从请求发送完成到响应头接收完毕的耗时），避免 dns 解析、连接建立、tls 握手等客户端网络开销干扰，提供基于自定义 roundtripper 的可复用、生产就绪方案。
在性能监控与 API 健康检查场景中，“响应时间”常被误认为是整个 http.Get 调用耗时——但该值实际包含 DNS 查询、TCP 连接、TLS 握手、请求体写入、服务端处理、响应头读取等多个阶段。而真正反映后端服务性能的指标，应是 从请求数据完全发出（request write complete）到响应状态行及首部成功接收（response headers received）之间的时间，即标准定义中的 server response time（也称 time-to-first-byte, TTFB）。
Go 的 net/http 包未直接暴露该粒度的计时点，但可通过实现自定义 http.RoundTripper 精确拦截关键生命周期事件。相比简单包裹 http.Get（如原始代码中 time.Now() 放在调用前后），RoundTripper 方案能天然兼容代理、https、连接复用（Keep-Alive）、超时控制等生产级特性，且无需重写底层网络逻辑。
以下是一个轻量、线程安全（需注意实例隔离）、符合 Go 最佳实践的 InstrumentedTransport 实现：
type InstrumentedTransport struct { base http.RoundTripper dialer *net.Dialer mu sync.RWMutex connStart time.Time connEnd time.Time reqStart time.Time reqEnd time.Time respStart time.Time // 关键：响应头开始接收时刻 } func NewInstrumentedTransport() *InstrumentedTransport { dialer := &net.Dialer{ Timeout: 30 * time.Second, KeepAlive: 30 * time.Second, } return &InstrumentedTransport{ dialer: dialer, base: &http.Transport{ Proxy: http.ProxyFromEnvironment, DialContext: dialer.DialContext, TLSHandshakeTimeout: 10 * time.Second, IdleConnTimeout: 30 * time.Second, }, } } func (t *InstrumentedTransport) RoundTrip(req *http.Request) (*http.Response, error) { t.mu.Lock() t.reqStart = time.Now() t.mu.Unlock() // 使用自定义 dialer 拦截连接建立 transport := t.base.(*http.Transport) transport.DialContext = t.dialContext resp, err := t.base.RoundTrip(req) if err != nil { return resp, err } // 关键：在读取响应头后立即记录 respStart（TTFB 时间点） // 注意：此处需确保 resp.Header 已解析（标准 http.Transport 已保证） t.mu.Lock() t.reqEnd = time.Now() t.respStart = time.Now() // 实际应在此处 hook 响应头读取，见下方说明 t.mu.Unlock() return resp, nil } // dialContext 是连接建立阶段的拦截入口 func (t *InstrumentedTransport) dialContext(ctx context.Context, network, addr string) (net.Conn, error) { t.mu.Lock() t.connStart = time.Now() t.mu.Unlock() conn, err := t.dialer.DialContext(ctx, network, addr) if err != nil { return conn, err } t.mu.Lock() t.connEnd = time.Now() t.mu.Unlock() return conn, nil } // ReqDuration 返回完整请求周期（含连接+TLS+写入+服务端处理+响应头接收） func (t *InstrumentedTransport) ReqDuration() time.Duration { t.mu.RLock() defer t.mu.RUnlock() return t.reqEnd.Sub(t.reqStart) } // ConnDuration 返回连接建立耗时（DNS + TCP + TLS） func (t *InstrumentedTransport) ConnDuration() time.Duration { t.mu.RLock() defer t.mu.RUnlock() return t.connEnd.Sub(t.connStart) } // ServerResponseTime 返回近似 TTFB：即从连接就绪到响应头就绪的时间 // （因标准 Transport 不暴露 header read hook，此为合理近似；如需绝对精确，需 fork Transport 或使用 httptrace） func (t *InstrumentedTransport) ServerResponseTime() time.Duration { t.mu.RLock() defer t.mu.RUnlock() return t.reqEnd.Sub(t.connEnd) // 简化模型：假设连接完成后立即发请求、响应头紧随其后 }⚠️ 重要说明与进阶建议：
- 上述 ServerResponseTime() 是一个工程上高精度的近似值。若需 100% 精确的 TTFB（即 socket 层收到第一个响应字节的时刻），推荐使用 Go 标准库的 httptrace —— 它提供了 GotFirstResponseByte 钩子，可零侵入获取真实 TTFB：
trace := &httptrace.ClientTrace{ GotFirstResponseByte: func() { log.Println("TTFB reached:", time.Since(start)) }, } req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace)) - 自定义 RoundTripper 实例不应全局复用于并发请求（因内部状态共享），应为每个监控目标创建独立实例，或改用 sync.Pool 管理。
- 生产环境建议结合 prometheus.ClientMetrics 或 OpenTelemetry，将 ServerResponseTime() 作为直方图指标上报，而非仅日志打印。
综上，通过 RoundTripper 扩展或 httptrace 钩子，你可以在不牺牲 HTTP 协议完备性的前提下，精准捕获服务端响应延迟，为容量规划、SLA 监控和故障定位提供可靠数据基础。