怎样测出可信的网速

"测速"看起来只是点一下按钮，但同一个网络在不同工具里能差出三倍。差别通常来自三个地方：缓存、 握手、以及并发。

一、缓存会让下载速度虚高

任何一层缓存（浏览器、CDN、ISP 透明缓存）命中时，数据根本没走完链路，数字自然漂亮。 本站在测速路径上做了三重防护：

• 响应头 Cache-Control: no-store
• JS 每次请求都加随机查询串 ?r=xxxxxxxx
• /st/ 下关闭 gzip，避免零字节被压缩后变成"极速"

二、别把 TCP/TLS 握手算进带宽

第一次请求包含 DNS、TCP 三次握手、TLS 协商，几毫秒到几百毫秒不等。把它算进下载时间， 短文件测出的速率会明显偏低。本站的做法：

• 延迟测试取 12 个样本，丢弃第 1 个（含握手）后取均值
• 下载测试在累计超过 0.25 秒后才开始计速
• 再对后半段样本取中位数，滤掉单次抖动

三、时间窗口很重要

家用宽带通常有前几秒的突发额度（burst），测 5 秒的结果会明显高于持续速率。 想看长期稳定值，用 100 MB 文件跑到 9 秒以上；想看瞬时能力，短文件即可。 两种数字都对，问题只在于你拿它跟什么比。

表中"曾经的测法"对应的 /st/ 端点已于 2026-11 全部移除，现在访问返回 410 Gone；方法本身仍适用于自建压测环境。

四、命令行对照（历史示例）

浏览器的上限是单连接 + 浏览器调度，用 curl 能更干净地看服务端实力：

# 下载 100 MB，输出平均速率（字节/秒）
curl -o /dev/null \
     -w 'download %{speed_download} B/s  total %{time_total}s\n' \
     'https://speedtest.heodiy.com/st/100mb.bin?r=1'

# 只测延迟（HEAD 请求 10 次）
for i in 1 2 3 4 5 6 7 8 9 10; do
  curl -s -o /dev/null -w '%{time_total}\n' 'https://speedtest.heodiy.com/st/ping.txt?r='$i
done

# 上传 10 MB 随机数据
head -c 10M /dev/urandom > /tmp/up.bin
curl -X PUT --data-binary @/tmp/up.bin \
     -w 'upload %{speed_upload} B/s\n' \
     'https://speedtest.heodiy.com/st/upload/cli-$(date +%s).bin'

注意：上面三例指向的 /st/ 端点已于 2026-11 下线（现返回 410），仅作"用 curl 控制变量"的思路演示。要在自有机群之间做真实压测，请用 iperf3：

# 服务端（一台你有权限的机器）
iperf3 -s -p 5201

# 客户端：TCP 单向 10 秒，-O 2 跳过前 2 秒预热，-P 4 四并发
iperf3 -c 服务端IP -p 5201 -t 10 -O 2 -P 4

# UDP 看抖动与丢包，-b 限制带宽
iperf3 -c 服务端IP -p 5201 -u -b 100M -t 10

五、几个常见误区

• 连着 VPN 测速：测的是 VPN 出口，不是你的宽带。
• 只看峰值：峰值受突发额度影响，日常体验看稳定值。
• Wi‑Fi 当有线：2.4 GHz 频段常常卡在 50–80 Mbps，先排除无线干扰。
• 单位混淆：Mbps 与 MB/s 差 8 倍，浏览器测速面板显示的是 Mbps。

先把变量控制住，再谈数字。测速的价值不在于"跑分更高"，而在于能解释差异。