买了云服务器，很多人先看配置表上的带宽数字。写着 5Mbps 或 100Mbps，就默认能跑得动。等上线后页面打开慢、文件下载断断续续、接口偶尔超时，才发现配置数字并不能代表实际表现。云服务器网络测速要在上线前后都做，它能告诉你服务是否真的能稳定跑起来。
下面结合几个实际场景，说说怎么测、测什么，以及测出来的数字怎么读。
要测的四个指标
只盯着下载速度一个数字，很容易漏掉问题。至少要看下面四项：
- 带宽：单位时间内能传输的最大数据量，决定大文件下载和并发访问的上限。
- 延迟：数据包从发出到收到回复的时间，影响网页打开速度和远程操作的流畅度。
- 丢包率：传输中丢失的数据比例。丢包多时 TCP 会不断重传，表现为速度忽快忽慢。
- 抖动：延迟的波动幅度。视频通话、实时游戏、在线交易对它最敏感。
带宽高不等于延迟低。一台服务器标称 100Mbps，但到用户所在地区的延迟经常超过 200 毫秒，用户照样觉得网站卡。所以几个指标要放在一起看。
常用的测速工具
日常排查用到的工具都免费，装起来也简单。
- ping：最基础的连通性和延迟测试，丢包情况也能看出来。
- mtr：结合 ping 和 traceroute，逐跳显示哪一段出现延迟或丢包，定位问题很快。
- iperf3：两端都要部署，用来测服务器之间或服务器与本地之间的真实吞吐量，结果更接近实际。
- curl：下载一个已知大小的文件，用耗时和文件大小换算实际下载速度，适合模拟用户的访问体验。
在线测速网站只能反映测速节点到你的网络情况，不一定是真实用户的访问路径。如果用户主要在华南，就选华南节点测，别只看某个北方城市的结果。
案例一：电商小站的图片加载慢
一个做手工饰品的小团队把网站放在华北地区的云服务器上。商品图片每张约 800KB，首页一次要加载二十多张。运营同学反馈，手机上打开首页要等七八秒，电脑上还能接受。
团队先用 ping 测从华南用户常用城市到服务器的延迟，大约 60 毫秒，看起来不高。接着用 mtr 逐跳跟踪，发现某个中间节点丢包明显，晚上高峰时段丢包率能到 5% 以上。这说明问题出在运营商的骨干网络，服务器本身的带宽并没有不够。
解决办法有两个。一是把图片迁到对象存储并开启 CDN，让用户从就近节点取图。二是把图片转成 WebP 格式，单张体积降到 200KB 左右。调整后首页加载时间降到两秒以内，之后没再收到类似反馈。
案例二：跨境接口调用超时
另一个案例来自一家数据采集团队。服务器部署在东南亚某地区，需要频繁调用国内的一个接口。表现是偶尔超时，平均响应时间看着正常，但大约 3% 的请求会失败。
团队用 iperf3 在服务器和国内测试机之间持续测了十分钟，吞吐量能达到标称带宽的八成左右，看起来没问题。但延迟在 150 毫秒到 600 毫秒之间大幅跳动，抖动很大。进一步排查后发现，问题集中在跨境链路的某些时段，拥塞很严重。
他们做了两件事。接口调用加上重试和超时控制，超时阈值从两秒调到五秒。部分非实时任务挪到夜间执行，避开高峰拥堵。调整后失败率降到 0.2% 以下。
测速时的几个实用做法
- 分时段测，至少覆盖早高峰、午间和晚高峰。单次测试很容易被偶然因素干扰。
- 每个指标多测几次取平均值，原始数据也留着，方便之后对比。
- 测之前先确认服务器的 CPU 和磁盘没有满载，否则网络数据可能失真。
- 如果服务商同时给出内网带宽和公网带宽，两者分开测，别混在一起看。
- 发现问题后先通过服务商工单提交，附上 mtr 和 iperf3 的输出，处理会快很多。
测速本身不复杂，难的是定期做，并且把数字和业务体感对上。带宽、延迟、丢包、抖动各自对应不同的问题。如果业务对访问速度敏感，可以每月完整测一次并记录结果。出了问题时手里有前后对比，排查会省不少时间。
