「慢」的排查顺序
「慢」是全链路问题：从域名解析到数据传完的每一段都可能贡献时间。正确姿势是先量化再分层——用一次请求的分段计时把总耗时拆成解析、连接、握手、首包与传输五段，哪一段异常就往哪一层查。分段的意义是把「慢」从一个感受变成可比较的数字：同一目标连续采样三次取中位，改动前后的对比才有意义。如果各段都正常而总量很大，多半是并发竞争或服务端资源问题，而不是网络。
基本信息
| 适用 | 页面打开慢、接口响应慢、下载慢 |
|---|---|
| 第一步 | 量化：慢多少、只慢个别站点还是全部、下载慢还是打开慢 |
| 核心工具 | curl -w 分段计时、dig 计时、mtr 逐跳统计、iperf3 吞吐 |
| 判读顺序 | 名称解析 → 连接建立 → 握手 → 首包 → 传输 |
| 前置检查 | 客户端是否走代理、走 IPv4 还是 IPv6、是否首次访问 |
| 非网络因素 | 客户端 CPU 与内存占用、浏览器插件、安全软件扫描、代理链路 |
十步排查清单
- ① 量化现象：慢多少？所有站点还是单个站点？下载慢还是打开慢？
- ② 名称解析：dig 计时，解析慢会拖慢一切应用
- ③ 连接建立：看握手阶段耗时，偏慢指向网络时延或拥塞
- ④ 握手阶段：偏慢指向证书链、加密套件协商或服务端 CPU
- ⑤ 首包时间：远大于连接耗时说明服务端处理慢
- ⑥ 传输阶段：用总耗时与下载字节数反推有效吞吐
- ⑦ 逐跳质量：mtr 长跑看丢包与时延在哪一跳恶化
- ⑧ 带宽实测：iperf3 有效吞吐与链路标称对比
- ⑨ 对照测试：换协议、换客户端、换出口验证影响范围
- ⑩ 前推结论：把 ① 到 ⑨ 的数字写在一起，慢的那一段自然浮现
curl 分段量化
curl 分段量化
curl -s -o /dev/null -w 'DNS %{time_namelookup}s TCP %{time_connect}s TLS %{time_appconnect}s TTFB %{time_starttransfer}s 总 %{time_total}s 速率 %{speed_download}B/s\n' https://<目标>/
dig @8.8.8.8 <域名> +stats # 换 DNS 服务器对比解析耗时
mtr -r -c 100 -n <目标> # 逐跳看时延从哪一跳开始抬升
iperf3 -c <目标> -t 20 -P 4 # 有效吞吐与链路标称对比
for i in 1 2 3; do curl -s -o /dev/null -w '%{time_total}\n' https://<目标>/; done # 重复采样取中位分段耗时与指向
| 指标 | 含义 | 异常指向 |
|---|---|---|
| 名称解析耗时 | 解析域名花的时间 | 解析慢会拖慢所有应用，先用其他 DNS 服务器对比 |
| 连接耗时 | TCP 三次握手耗时 | 偏大指向网络时延、拥塞或链路质量差 |
| 握手耗时 | 加密握手耗时 | 偏大指向证书链过长、协商开销或服务端 CPU 紧张 |
| 首字节时间 | 从请求发出到收到第一个字节 | 远大于连接耗时说明慢在服务端处理 |
| 整段耗时 | 从发起到结束的总时间 | 结合下载字节数反推有效吞吐 |
对比测试要保证公平：一台客户端走 IPv6、另一台走 IPv4 时，路径与质量可能完全不同；代理、安全软件扫描与首次连接的握手开销同样会显著抬高耗时。换客户端复测时，这几项条件要逐一确认。
「慢」要分成两种形态：每个请求都稳定偏慢，多与路由、解析或服务端容量有关；偶发几个请求特别慢，则更像丢包、队列排队或后端依赖抖动。两种形态的排查手段不同，别用同一套清单硬套。
重复请求能区分一次性开销与持续问题：第二次访问省掉了解析与部分握手开销，若仍然很慢，问题更可能在服务端处理或传输阶段，而不是解析与建连环节。