Linux性能优化:怎么评估Linux系统网络性能?别靠感觉,拿数据说话

延迟、吞吐、带宽、丢包——Linux 网络性能评估就这四个维度。本文从指标到工具再到实战，给出一套可复用的评估方案。读完你可以直接上手给任何一台 Linux 机器做网络体检。

"服务器上线了，用户反馈说网很慢。"

这是在工位上听到频率最高的一句话，没有之一。每次有人这么说，我都会反问一句：有多慢？延迟多少？吞吐多少？丢包率呢？

对面通常沉默三秒，然后补一句："就……感觉卡。"

这个对话在过去几年里重复了无数遍。说句不好听的，绝大部分的开发者判断网络性能全凭体感**——页面转圈就觉得"慢"，能秒开就觉得"快"。但你问具体指标，一个都答不上来。

今天这篇，就是想把"评估Linux网络性能"这件事说明白。

一、衡量网络性能的四个维度

聊网络性能，得先统一度量衡。工具再多，但底层绕不开的就是这四个东西。

延迟

数据包从 A 到 B 走个来回要多久。单位毫秒，越小越好。

ping 命令测的就是这个。局域网内延迟一般在 1ms 以内，同城机房之间 3-5ms，跨省骨干网 20-40ms，跨国 100-200ms 甚至可能更高。

很多觉得"慢"的场景，可能根本不是带宽不够，是延迟太高了。

吞吐量

单位时间内实际传输的数据量，单位 bps，或者是 Mb/s、Gb/s。

吞吐量不等于带宽。你办了 1000M 宽带，不等于任何时候都能跑满 1000M。带宽是理论上限，吞吐量是实际的表现。

带宽（Bandwidth）

链路的最大传输能力。千兆以太网的带宽是 1Gbps，万兆是 10Gbps。

这里有个要注意的地方，硬件一般称的带宽，往往是用大包（1518 字节）测出来的。如果你传的都是 64 字节小包，实际吞吐可能缩水一个数量级。因为每秒能处理的包数量（PPS）有时比带宽更关键——尤其是对网关、路由器等这类设备。

丢包

数据包在传输过程中丢了。原因有很多：可能网络拥塞、网卡故障、缓冲区溢出等。

丢包的可怕之处在于，在 TCP 协议下，丢一个包带来的延迟远比想象中高。因为TCP 会启动重传和拥塞控制，一个 1% 丢包率的链路，吞吐量可能下降 50% 以上。

四个指标里，最容易忽略的是延迟和丢包，需要特别注意。

二、基础工具的使用

真实环境里，不是所有机器都有权限装额外软件。幸运的是，Linux 自带的工具箱已经能干不少事。

ping —— 最基础的延迟探测工具

ping -c 10 192.168.1.1

看 min/avg/max。正常局域网延迟不超过 3ms。超过 10ms 基本上说明链路有问题。

也能看丢包。如果 ping 显示有丢包，先确认是不是 ICMP 被限制了。

ss 和 netstat

这两个都能看 socket 状态。ss 是 netstat 的现代替代，更快，信息会更多。

ss -ti

重点看这一行：cwnd（拥塞窗口）和 rtt（实时延迟）。cwnd 太小说明带宽没跑满；rtt 突然增大说明链路可能是在排队。

nstat —— 内核网络栈的体检报告

nstat -az

输出一长串，大部分不用管。看这几个：

• TcpRetransSegs
  ：TCP 重传段数。持续增长就是丢包。
• TcpOutSegs
   和 TcpInSegs：发送/接收段数。差值异常说明网络不太稳定。
• UdpInErrors
  ：UDP 接收错误。缓冲区溢出会常见这个错误。

重传率 = TcpRetransSegs / TcpOutSegs。超过 0.5% 就应该告警了；超过 2% 基本可以定性为网络性能有问题。

ethtool —— 物理层的工具

ethtool eth0

看 Speed、Duplex、Link detected。看下是否出现千兆网卡对端协商成了百兆，全双工会话变成了半双工等。

通过这几个工具，在不装第三方软件的情况下，基本面能做到大体心里有数了。

三、使用专业工具进行基准测试

系统自带工具只能定性的了解，定量还要上专门的基准测试工具。

iperf3 — 吞吐量测试

客户端-服务端架构，两端都要安装。

服务端：

iperf3 -s

客户端，测 TCP 吞吐：

iperf3 -c 服务器IP -t 30 -P 4

-t 30：测 30 秒；-P 4：4 个并发流。

输出直奔最后一行，看 Sum 列的 Bitrate。千兆网络下，TCP 吞吐跑到 940-950 Mb/s 算是正常的（TCP/IP 协议头有开销，跑不到 1000 是正常的）。

UDP 模式下：

iperf3 -c 服务器IP -u -b 1000M

看 Jitter也就是抖动 和 Lost/Total Datagrams（丢包率）。UDP 丢包太高就需要关注网络质量了。

netperf

跟 iperf3 定位类似，但 netperf 支持更多测试模式——尤其是 TCP_RR（请求-响应事务数）和 TCP_CRR（连接-请求-响应），更适合评估数据库、API 这类短连接场景。

netserver    # 服务端netperf -H 服务器IP -t TCP_RR -l 30

输出看每秒完成的事务次数，越高越好。

wrk — 测HTTP 应用层压力

上面所有工具都在传输层和网络层。但如果想知道应用是否能支撑业务，需要应用层工具。

wrk -t12 -c400 -d30s http://服务器IP/

输出看 Requests/sec（每秒请求数）和 Latency（延迟分布）。

一般要使用什么工具基本遵循在哪层出问题，就在哪层测。

四、举个评估的流程示例

1.基础链路检查

先确认物理层没问题。

ethtool eth0 | grep -E "Speed|Duplex|Link"ping -c 20 目标IPmtr -r -c 10 目标IP

一般看链路协商速率、延迟、路径上有没有明显的丢包。

2.单流吞吐基线

# 服务端iperf3 -s# 客户端iperf3 -c 目标IP -t 30

单流是最朴素的测试。如果单流都跑不过硬件能力的 80%，后面调多流纯属浪费时间。

3.多流并发 + UDP 边界

# 多流 TCPiperf3 -c 目标IP -t 30 -P 8# UDP 极限iperf3 -c 目标IP -u -b 线速的80% -t 30

UDP 测试则是为了探明丢包边界：带宽打到多少时开始丢，这个阈值就是你的链路上限。

4.应用层验证

wrk -t4 -c100 -d60s http://目标IP/

如果传输层和数据链路层都正常，但业务还是慢——那八成是业务代码的问题。

一份合格评估报告应该包含： 延迟（min/avg/max）、TCP 吞吐量（单流和多流）、UDP 丢包率、HTTP延迟。

回到开头那个场景

下次再有人说"网慢"，别下意识回那句"我感觉也是"。先走一遍体检方案：ping 看延迟，nstat 看重传，iperf3 跑吞吐，wrk 验证应用层。

网络性能评估这件事，本质上就是一套标准动作的重复。能在别人还在"感觉"的时候，给出结论。

如果评估出来有问题，后面我们专门谈网络性能调优这一块，欢迎关注，一起交流