“为啥我网站访问总是时快时慢？”
“前端没改，代码也没动，就是卡。”
“CDN 有加，Ping 正常，难道是运气不好？”
如果你经常在业务高峰期听到类似抱怨，不要急着推锅给网络或者 CDN，也别死盯着 Nginx 日志翻来翻去。很多时候，问题根本不是出在你想象中的那一层。
想搞清楚网站慢在哪儿，你得从 HTTP 请求的每一层下手排查，而不是凭经验拍脑袋猜。本文就来聊聊，如何用 HTTP 分层诊断工具，一步步剖析你的网站到底卡在哪一环。
为什么“请求慢”不能只看整体耗时？
我们先来做个类比：
如果说你的网站是一家餐厅，那么用户发起请求就像点餐——
用户开车进停车场（DNS 解析）
找服务员点单（TCP 连接）
等厨房做菜（后端处理）
上菜过程中被其他顾客卡住（队列/线程瓶颈）
食物到手发现配料出错又退单（应用层逻辑问题）
最终“吃饭慢”的体验，其实包含了很多个过程的耗时，而不只是点完单到上菜这一段。
同样，HTTP 请求从发出到接收响应，是一个分层结构的耗时体系，常见分层包括：
DNS 解析耗时
TCP 握手耗时
TLS 握手耗时
发送请求头耗时
等待响应耗时（TTFB）
接收响应体耗时
如果你只看整体耗时（比如 time_total），就像医生只测体温给病人开药，那只能算玄学运维。
常用的 HTTP 分层诊断工具有哪些？
要想真正搞懂问题在哪，工具必须用对。以下是最实用的几个：
1. curl -w（快速诊断工具）
你可以用以下命令打印所有耗时细节：
bash curl -o /dev/null -s -w "@curl-format.txt" https://example.com
内容示例：
css
DNS解析时间: %{time_namelookup}s
TCP连接时间: %{time_connect}s
SSL握手时间: %{time_appconnect}s
首字节等待: %{time_starttransfer}s
总耗时: %{time_total}s这几项指标是排查性能瓶颈的黄金参考线。
2. Chrome DevTools（前端请求耗时分析）
在浏览器按 F12 打开开发者工具，进入 Network 面板，点击具体请求，Timeline 会详细显示：
StalledDNS LookupInitial ConnectionSSLRequest SentTTFBContent Download
配合各阶段耗时，你能大致判断问题是出在客户端、网络、还是服务端。
3. Wireshark 或 tcpdump（高级抓包分析）
当你怀疑是 TLS 连接反复建立、RTT 波动过大、服务器 RST 多等网络异常问题时，抓包是最后的底牌。
常见请求慢的分层原因分析
知道怎么测还不够，你还得知道不同层的慢意味着什么问题：
DNS 耗时高：
可能是 DNS 服务质量差，缓存失效或运营商劫持。解决方式：
使用可靠的公共 DNS（如 114.114.114.114 / 8.8.8.8）
启用 DNS 缓存服务如
dnsmasq启用 EDNS Client Subnet 适配就近解析
TCP 连接耗时长：
代表三次握手慢，通常是由于：
路由不稳定
跨运营商链路质量差
服务端 SYN-ACK 拒绝（连接数打满）
可用 MTR/TraceRoute 工具排查路径质量，用 CDN 弹性调度应对。
SSL 握手慢：
这跟证书大小无关，而可能是：
TLS 协议协商慢（禁用了 TLS1.3？）
服务端未启用缓存 Session ID/Resumption
客户端和服务端支持算法不匹配
建议启用 TLS 1.3 + 0-RTT，配置 OCSP Stapling 缓解验证慢问题。
TTFB 高（首字节等待慢）：
这是最容易暴露服务端问题的地方，比如：
后端数据库慢查询
应用逻辑阻塞（PHP / Java 执行耗时）
线程池或连接池打满
你可以结合服务端 APM 工具（如 Skywalking、Pinpoint、New Relic）辅助排查。
响应体下载慢：
可能是服务器出口带宽拥堵、CDN 回源慢、GZIP 开启失败等原因。
实战例子：我们怎么一步步查出“请求慢”真相？
有个客户反馈说：“我们网站首页加载总在北京地区卡住，国外正常。”
我们让他用 curl 打了个诊断请求，结果是：
makefile DNS解析时间: 0.02sTCP连接时间: 0.3sSSL握手时间: 0.9s首字节等待: 1.2s总耗时: 3.2s
一眼看出：TLS 握手和首字节等待明显偏高。
抓包后发现，TLS 连接反复失败，SNI 不匹配，服务端返回多次 RST。
根源在于：CDN 厂商的证书配置错误，回源 IP 路由绕到美国节点。
修复后，耗时从 3.2s 降至 0.9s。
如何建立一套完整的 HTTP 分层监控体系？
如果你维护的是高可用网站，建议做如下监控体系建设：
用 curl + bash 自动巡检耗时关键指标，异常就报警
接入网站 APM，定位后端响应瓶颈
利用 Prometheus + Grafana 可视化 HTTP 各阶段指标趋势
异地多点部署 curl 请求监控真实访问体验（配合 观图 之类服务）
豫公网安备41160202000677
