VPS买完服务器标注的带宽是不是真跑满?VPS服务器的线路质量怎么样?晚高峰延迟会不会很高?很多时候,供应商的配置参数和真实使用体验之间有明显差距。通过测速,你可以验证承诺的带宽是否达标,排查网站响应慢的原因,甚至判断是否有必要更换线路更优的服务器。对于游戏、实时通信这类对网络敏感的场景,测速更是必须做的功课。
最简单的方法,不需要额外安装任何工具。测延迟用ping
ping -c 10 www.baidu.com
重点关注两个指标:一是time数值,代表数据包往返时间,通常50ms以内算正常,超过100ms就要注意了;二是丢包率,0%丢包是理想状态,超过2%说明线路质量有问题。不过ping只能测延迟,不能测带宽。
测下载速度用wget或curl
想知道服务器从某个节点下载文件有多快?直接下个大文件测一测最直观。终端会显示实时速度,比如看到“15.2 MB/s”,换算成Mbps需要乘以8,大约是120Mbps。小技巧:可以同时测试不同地区的测速文件,对比哪个节点速度更快,这对选择服务器位置很有参考价值。
专业测速工具
speedtest-cli测公网带宽最方便,这是Speedtest官方推出的命令行工具,用法和网页版一样简单。安装方法:
Ubuntu/Debian
sudo apt install speedtest-cli
CentOS/RHEL
sudo yum install speedtest-cli
一键测速:
speedtest-cli
只输出关键数据(适合脚本调用):
speedtest-cli --simple
指定国内节点测回国速度:
speedtest-cli --list | grep -i china
speedtest-cli --server 节点ID
speedtest-cli会自动选择最近的服务器,测试结果包含Ping值、下载速度和上传速度,覆盖面广,非常适合快速评估服务器到全球各个节点的带宽质量。
iperf3是测两台服务器之间的真实带宽
speedtest测的是到公共节点的带宽,而iperf3可以测试你自己控制的两台服务器之间的实际传输速度,结果更贴近业务真实场景。两家都需安装。
两台服务器都安装
sudo apt install iperf3 -y
在接收端(服务端)启动监听:
iperf3 -s
在发送端(客户端)执行测试:
基础测试,默认10秒
iperf3 -c 服务端IP
测试30秒,取更稳定的平均值
iperf3 -c 服务端IP -t 30
测试反向带宽(服务端→客户端,即下载速度)
iperf3 -c 服务端IP -R
多并发流测试,模拟真实多用户场景
iperf3 -c 服务端IP -P 4
测试UDP带宽和丢包率
iperf3 -c 服务端IP -u -b 100M
iperf3输出中重点关注Bandwidth(实际传输速率)和Retr(TCP重传次数)。重传次数越低说明线路质量越好。UDP模式下则关注Lost/Total的丢包率。
mtr:持续监控延迟和丢包
mtr结合了ping和traceroute的功能,可以实时显示数据包经过每一跳路由的延迟和丢包情况。
安装
sudo apt install mtr -y
交互模式(实时刷新)
mtr 目标IP
报告模式(运行100个包后输出结果)
mtr --report --report-cycles 100 目标IP
mtr输出中,Loss%列显示丢包率,Avg列显示平均延迟。如果某一跳之后丢包率突然升高,说明问题就出在那个网络节点上。
一键测速脚本:省时省力的综合方案
如果你觉得手动跑上面这些工具太麻烦,社区里有不少一键脚本,一条命令就能测完CPU、内存、磁盘和网络带宽,并给出综合报告。
bench.sh(秋水逸冰脚本) :最经典的一键脚本,显示系统信息、IO测试(取三次平均值)、全球多节点测速。
wget -qO- bench.sh |
SuperBench:在bench.sh基础上增加了服务器虚拟化架构检测和国内三网(电信、联通、移动)测速节点。
curl -LsO https://raw.githubusercontent.com/FunctionClub/ZBench/master/ZBench-CN.sh && ZBench-CN.sh
测速结果怎么解读?
拿到测速结果后,怎么判断服务器到底行不行?一个简单直接的判断方法是:找个测试IP,白天ping一下,晚上8点再ping一次。如果延迟从50ms飙到200ms以上,丢包率超过3%,说明这线路不太适合做面向国内用户的服务。
以下是一些参考标准:
| 测试项目 | 优秀 | 合格 | 需优化 |
| Ping延迟(国内-美西) | <150ms | 150-200ms | >200ms |
| 下载速度(标称带宽占比) | >90% | 70%-90% | <70% |
| 晚高峰丢包率 | <1% | 1%-3% | >3% |
| TCP重传次数 | <10 | 10-50 | >50 |
测速之后还能做什么?
测速不光是发现问题,更是为了解决问题。如果你发现服务器网络表现不佳,有几个优化方向可以尝试。
开启BBR拥塞控制算法。BBR是Google开发的TCP拥塞控制算法,相比传统的CUBIC算法,在有一定丢包的网络环境下(比如跨太平洋链路),BBR能更充分地利用带宽,提升传输速度20%-300%。
检查内核版本(需4.9以上)
uname -r
开启BBR,编辑sysctl.conf文件
sudo nano /etc/sysctl.conf
在文件末尾添加:
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
保存后应用:
sudo sysctl -p
更换线路。如果开启BBR后效果仍然不佳,可能需要考虑更换服务器地域或选择CN2 GIA、9929这类优质线路。
测速不是跑一次就完事。不同时间段的网络状况差异很大,建议做几次测试取平均值。同时记录历史数据建立性能基线,方便后续对比。
购买新服务器后第一时间跑一遍完整的测试,确认配置达标。后续每隔一段时间再测一次,监控性能是否稳定。结合自己的业务场景选择测试重点——数据库为主的服务器多测磁盘IO,面向国内用户的网站多测回国路由和晚高峰丢包。掌握了这些方法,你的服务器到底行不行,自己就能判断。
CN
EN