从客户端一侧解读 cURL 的代理计时
解释连接、TLS、首字节与总时间，不把未观测到的上游工作算作仅代理的测量。
假设 cURL 打开一条到普通 HTTP 代理的新 TCP 连接，建立 HTTPS 隧道，并下载一个响应。这些计时描述了 cURL 在该路径上观测到的里程碑。
| 数值 | 从传输开始计量的里程碑 |
|---|---|
| time_connect | 与代理的连接完成 |
| time_appconnect | 相应的 TLS 握手完成 |
| time_starttransfer | 收到响应的第一个字节 |
| time_total | 传输结束 |
下面是一个示例性的 POSIX shell 记录：
curl --proxy http://proxy.example:8080 \
--output /dev/null \
--write-out 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/若要在没有代理凭据的情况下做允许的公开 HTTPS 对比，可以用 HTTP 代理列表中的一条 HTTP 记录替换示例代理。这些数值是累计秒数，不是四个可以相加的独立时长。请把传输错误和响应状态与数字放在一起看：连接失败或隧道被拒时，并没有走到之后的每个里程碑。
相减能告诉你什么
对单个成功响应，time_total 减去 time_starttransfer 描述首字节到达之后剩余的区间。这主要是后续的响应传输和相应的客户端工作，而不是代理连接网站的时间，因为那发生在响应可能到达之前。
同样，time_starttransfer 减去 time_connect 可能包含隧道建立、TLS、上游网络等待、服务器处理以及其他开销。把整个差值称为“代理延迟”，等于把多个组成部分算到同一个参与者头上。
要把代理的上游 DNS、连接和响应等待区分开，需要取得代理一侧的相应观测或跟踪记录。客户端并不会仅因为使用 HTTP CONNECT 就得到那些内部时间戳。
比较时请选择等效的传输。重定向会叠加多个请求的耗时，而连接复用和多路复用会改变所需的准备工作。在把一个代理的数字与另一个相比之前，先记录这些条件。