为什么ping的延迟低，网速却不一定快？

几年前，我判断服务器网速快慢的方法很简单。

打开终端，敲一行：

ping
 服务器IP

延迟低，就是网速好。延迟高，就是网速差。

直到最近，我才意识到没那么简单。

一、70ms，反而比 120ms 更慢

我有两台日本服务器。

一台直连延迟 70ms 一台绕路延迟 120ms

按常识判断，70ms 应该网速更快。

结果却是：

我连 70ms 那台的下载速度更慢，120ms 那台反而能跑满带宽。

这我才意识到：延迟，根本不是网速的全部。

二、ping 到底在测什么？

ping 默认使用的是 ICMP 互联网控制消息协议。

它做的事情很简单：

发一个很小的数据包（通常 64 字节）
等对方回一个应答
计算往返时间（RTT）

它测的是网络反应快不快。

但它根本没有测：

带宽有多大
能持续传输多少数据
丢包后如何重传
拥塞时如何控制速率

换句话说，ping 测的是响应能力，不是运输能力。

三、第一次升级：我开始自己造测速环境

当我开始怀疑 ping 时，我做了一件很原始的事。

我在服务器上放了一个文件，然后直接用 Python 起了一个 HTTP 服务：

python
 -m http.server
8000

没有 nginx，没有优化。

就这么简单。

然后我在 Windows 里用 curl 下载：

curl -o
NUL

http
:
//服务器IP:8000/testfile

那是我第一次看到我连接的服务器的真实下载速度。

HTTP 基于 TCP 传输控制协议。

而 TCP 是一个复杂的系统：

慢启动
拥塞控制
窗口大小
丢包重传

下载测速测的是在持续传输下，这条链路能运多少数据。

这和 ping 完全是两个世界。

四、第二次震荡：多线程的真相

后来我发现单线程跑不满带宽。

于是我开始做 HTTP 多线程下载。

结果又出现问题。

同一台服务器，同一条线路，不同版本的终端跑出来的结果差异很大。

原来测速不仅取决于服务器，也取决于客户端。

CPU 性能、线程调度、Socket 数量、TCP 栈实现，都会影响结果。

甚至测速工具本身，也可能成为瓶颈。

五、最后，我换成了 iPerf3

当我意识到 HTTP 本身也会带来变量时，我最终改用了 iPerf3。

那时候我才真正开始理解链路能力。

我开始看到网络的多个维度：

延迟
带宽
丢包
抖动

原来网速不只是一个数字，而是一个系统。

六、回归正题：延迟低，为什么网速却不一定快？

答案其实很简单：

延迟决定响应速度
带宽决定运输能力

就像：

摩托车启动很快
但货车才能拉更多货

启动速度和运载能力，从来不是一回事。

我真正升级的，不是测速方法，而是认知模型。

从用延迟判断网速，到理解协议、拥塞控制、客户端能力、链路结构。

如果你之前也是 ping 一下就下结论。

现在，或许你可以试一下 iPerf 。