一个请求的时间，都花在哪里了？

“网站打开得慢”描述了感受，却没有定位问题。把一次请求拆成几个阶段，才有可以比较的证据。

先画出请求的路径

浏览器需要知道目标地址，建立连接，完成加密协商，再发送请求、等待响应。一个总耗时数字把这些过程叠在一起，很容易让我们把网络问题和应用问题混为一谈。

用一条小命令留下记录

下面的示例用 curl 输出几个累计时间。单位是秒，时间点都从请求开始计算；相邻时间点的差值，比直接比较几个累计数字更有用。

curl -o /dev/null -sS -w '
dns:   %{time_namelookup}
tcp:   %{time_connect}
tls:   %{time_appconnect}
first: %{time_starttransfer}
total: %{time_total}
' https://example.com

让对照条件保持一致

先固定目标地址、网络环境和请求内容，再重复测量。一次异常只能提供线索，多次结果才有助于判断是否稳定复现。使用代理、重定向或连接复用时，计时的含义也会受影响，要在记录里注明。

首字节时间包含服务器处理及网络传输的影响，不能单凭它断言数据库很慢。下一步应结合服务日志和应用指标，继续缩小范围。

继续阅读：curl 官方手册 · write-out