机场试用打开网页慢，问题在首字节还是下载？
机场试用打开网页慢，问题在首字节还是下载？
同一个节点可能出现两种完全不同的“慢”：页面很久才开始显示，但显示后很快完成；或者页面马上有反应，后续图片和文件却一直加载。前者更像连接、握手或服务端首字节等待偏长，后者更像持续传输能力不足。做机场推荐或试用记录时，把这两种情况混成一个“总耗时”，很容易选错节点。
先记录三个值
准备一个你确实会访问、且允许测试的 HTTPS 地址。每次只请求同一个地址，不在两轮之间切换节点，也不要一边更新系统或下载大文件。Windows 自带的 curl.exe 可执行：
curl.exe -L -o NUL -sS -w "connect=%{time_connect} first=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n" "https://example.com/"
macOS 或 Linux 把 NUL 换成 /dev/null。其中 time_connect 是从开始到 TCP 连接完成的累计时间，time_starttransfer 是从开始到收到第一个字节的累计时间，time_total 是整个操作的总时间。curl 官方手册还说明，首字节时间已经包含此前的连接和协议准备阶段。
用差值判断慢在哪里
不要只比较三个累计数，而要算两个差值：
first - connect：连接完成后，到第一个字节到达前等了多久。这个值持续偏大，可能与 TLS、代理转发、目标站响应或节点到目标站的路径有关。total - first：收到首字节后，传完正文用了多久。这个值偏大且下载字节数相近，才更像持续吞吐不足。
例如 A 节点的 first=0.8、total=0.9，B 节点的 first=0.2、total=1.8。A 是启动等待较长，B 是正文传输较慢。只看总耗时会错过这个差别。
做一组可以复查的对照
每个候选节点连续测 5 次，记录中位数，并把失败也写入表格。首次请求可能受 DNS、连接复用和缓存影响，因此不要拿单次最佳值做结论。保持目标 URL、网络、设备和时间窗口一致；若目标页面会动态变化，同时记录 bytes，正文大小差异过大的一轮不参与横向比较。
测试小页面可以观察首字节，但不足以判断长时间下载。若你的真实需求包含文件下载，再补一组固定大小、来源可靠的测试文件，并设置流量上限。机场试用的目标是验证自己的任务，不是制造峰值。
验收标准
完成后应能回答三件事：哪一段占主要时间；同一节点 5 次结果是否稳定；换节点后变化发生在首字节前还是正文传输阶段。如果只能得到“某次总耗时更短”，这组测试还不足以支持机场推荐结论。
评论