延迟分解是什么
把一次访问的总耗时拆成五段：名称解析、连接建立、加密握手、首字节等待、数据传完。每一段都有大致量级可参考，明显超出预算的那一段，就是下一步该深挖的方向。分解的价值在于把「慢」变成可比较的数字：只看总耗时无法判断要改网络还是改服务端，而分段之后方向往往一眼就能看出来。它还顺带回答一个高频问题——这次访问到底慢在链路，还是慢在业务处理。
基本信息
| 适用平台 | Linux 与 macOS 用命令行请求工具；Windows 上也提供同名工具 |
|---|---|
| 核心手段 | 请求工具的分段计时变量，一次请求即可拿到五段耗时 |
| 参照基准 | 先测一次到目标的往返时延，把各阶段换算成时延倍数再看 |
| 配套手段 | 解析耗时用解析工具对比、逐跳质量用路径探测、吞吐用压测工具 |
| 采样要求 | 同一目标重复多次取中位，单次结果容易受抖动影响 |
| 对比原则 | 两次请求可区分一次性开销（解析与握手）与持续问题 |
典型使用场景
- 接口偶发慢：先确认是服务端处理慢还是链路握手慢
- 首次访问慢、之后变快：多为解析与握手开销，对比第二次请求即可验证
- 跨地域访问体验差：用时延倍数判断是否属于物理距离的必然延迟
- 启用加密后明显变慢：看握手阶段占比，定位证书链与协商问题
- 下载速度不达标：把传输阶段单独测，与链路标称带宽对比
- 回归验证：优化之后重复同一组测量，确认改善量
分段测量
分段测量
curl -sS -o /dev/null -w 'dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://<目标>/
ping -c 5 <目标> # 先取往返时延基准，用于换算各阶段
curl -sS -o /dev/null -w 'size=%{size_download}B speed=%{speed_download}B/s time=%{time_total}s\n' https://<目标>/static/big.bin # 只测传输
for i in 1 2 3; do curl -sS -o /dev/null -w '%{time_total}\n' https://<目标>/; done # 重复采样
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer}\n' --http1.1 https://<目标>/ # 换协议版本对比
mtr -r -c 100 -n <目标> # 逐跳看时延在哪一跳开始抬升
ss -tnp | grep <目标> # 确认连接是否复用，避免重复握手开销阶段与判读参考
| 阶段 | 常见量级参考 | 异常指向 |
|---|---|---|
| 名称解析 | 缓存命中时通常很低 | 解析服务器、缓存与权威链路问题 |
| 连接建立 | 约一个往返时延 | 链路时延、握手报文被丢或被拦 |
| 加密握手 | 一到两个往返时延，会话复用更快 | 证书链拉取、协议协商、服务端处理能力 |
| 首字节等待 | 取决于服务端处理 | 后端慢、排队、锁等待、依赖接口慢 |
| 数据传输 | 约等于数据量除以有效带宽 | 带宽不足、丢包导致降速、窗口受限 |
| 连接复用后的请求 | 省去解析与握手 | 若仍很慢，问题在服务端或传输 |
连接阶段异常时先看往返时延基准：同城通常个位数毫秒，跨省会明显增加，跨国往往从百毫秒起。把绝对数字换算成时延的倍数，才看得出是链路慢还是正常范围。
同一目标测量两次能区分「一次性开销」与「持续问题」：第二次请求省掉了解析与部分握手开销，若仍然很慢，问题更可能在服务端处理或传输阶段。
对比测试要固定条件：协议版本、地址协议族、客户端出口与测试时段不一致时，两组数字没有可比性，很容易得出「改错了」的结论。