把慢 HTTP 响应拆解为 DNS、TLS 与服务端耗时

利用 curl 的 write-out 计时器把单个慢请求拆成域名解析、建连、TLS、首字节与传输各阶段，让修复落在正确的层面。

目标

curl 能给请求的每个阶段盖时间戳：域名解析完成、TCP 建连、TLS 完成、收到首字节、传输结束。把它们并排打印，就能回答争论解决不了的问题：慢在网络、握手，还是服务器握着连接思考？一条格式化字符串就是全部工具，无需服务端配合。

步骤要点

用 -w 格式串执行一次带完整计时的请求，输出 dns、connect、tls、ttfb、total 五个累计时间点。
连续执行五次，对比冷热差异：首次 tls 偏高而后续接近 0，说明会话复用正常，TLS 只在冷启动时昂贵。
对同一主机上已知很快的端点（如 healthz）测 ttfb：若只有十几毫秒，网络与 TLS 即被排除，慢的是业务端点本身。
带上 X-Trace-Id 重放慢请求并在服务端日志中检索该 id，把 730 毫秒的服务端耗时定位到具体内部 span 与负责团队。

排错提示

dns 常年几十毫秒就换更近的解析器并检查 TTL 过短问题；连健康检查的 ttfb 都大，先换网络复测排除自身上行带宽再怪罪源站；各次测量波动大时取五次以上的中位数，单次样本会混入路由变化与垃圾回收停顿。注意这些变量是累计时间戳，各阶段成本要与前一项相减得出。

适用边界

计时器只能把耗时归属到阶段，不能给出原因，ttfb 大仍需服务端追踪才能点名罪魁 span；经过代理或 VPN 时 connect 阶段包含的隐藏跳数无法被这些变量拆分。

代码示例

curl -s -o /dev/null -w \
  "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
  https://api.example.com/v1/orders