延迟怎么拆段
把一个请求的总耗时拆成段：DNS 解析、TCP 连接、TLS 握手、发送、等待首字节（TTFB）、接收。用户抱怨「接口慢」时先看慢在哪一段——解析慢查 DNS，连接慢看网络与距离，TTFB 慢是服务端处理（应用、数据库、下游依赖），接收慢是响应体过大或带宽不足。服务端内部再逐层拆：网关、应用、缓存、数据库、下游。
基本信息
| 客户端分段 | curl 的 -w 可输出解析、连接、握手、首字节、总耗时五段 |
|---|---|
| 服务端分段 | 网关到应用到数据库与下游，用链路追踪的 span 拆分 |
| 关键口径 | TTFB 反映服务端处理，总耗时等于 TTFB 加传输时间 |
| 常用手段 | curl -w、浏览器性能面板、链路追踪、日志埋点 |
| 定位顺序 | 先分段，再进最慢的那段继续拆，逐层收窄 |
| 干扰因素 | 客户端带宽、代理、CDN 缓存命中、连接复用状态 |
curl 分段测量
curl 分段测量
curl -o /dev/null -s -w "dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" \
https://api.example.com/v1/orders
# 读法：starttransfer 之前的时间接近服务端处理；之后是回包传输典型使用场景
- 「接口慢」投诉的首次定位：先分段再谈优化
- 接入 CDN 或网关前后：对比各段耗时变化
- 尾延迟解剖：看 p99 的慢主要贡献在哪一段
- 移动网络评估：高延迟链路上连接复用收益明显
- 优化收益核算：改动前后各段各自降了多少
分段读法
| 分段 | 含义 | 慢时的怀疑 |
|---|---|---|
| dns | 域名解析耗时 | 解析器或配置问题 |
| connect | TCP 握手耗时 | 网络质量与物理距离 |
| appconnect | TLS 握手耗时 | 证书链与握手参数 |
| starttransfer | 首字节等待 | 服务端处理与排队 |
| total 减 starttransfer | 内容传输 | 响应体大小与带宽 |
连接复用会省掉解析、握手与 TLS 段：首请求与保活复用的请求要分开测，混在一起会把复用收益算错。
分段要看分位：均值全绿也可能有少数请求在某一段异常（例如跨机房路由抖动），p99 才是抓这类问题的网。
别用平均总耗时定责：把网络与服务端混成一锅，归因错误会让优化资源全部打偏。