2. 网络性能测量基础
网络性能优化离不开可量化的测量。带宽、时延、抖动、丢包率和吞吐量是五个最核心的指标，它们分别回答不同的问题：链路能承载多少数据、数据走一趟要多久、到达节奏是否稳定、中途丢了多少、实际有效传输速率是多少。理解它们的定义、测量方法和误差来源，是后续所有优化工作的前提。
五个指标的定义与相互关系
带宽（Bandwidth）指链路或接口在单位时间内理论上能传输的最大数据量，通常以 bit/s 为单位，是链路的物理或配置上限。例如千兆以太网接口带宽为 1 Gbit/s。吞吐量（Throughput）则是实际成功传输的有效数据速率，永远小于或等于带宽。二者之间的差距，正是优化要压缩的空间。
时延（Latency）是数据从源到目的所经历的时间，由四部分组成：发送时延（数据长度/带宽）、传播时延（距离/光速）、处理时延（设备转发决策）和排队时延（缓冲区等待）。抖动（Jitter）是时延的变化程度，即相邻数据包时延的波动，对语音、视频、实时控制影响极大。丢包率（Packet Loss Rate）是丢失包数占总发送包数的比例，直接触发 TCP 重传，是吞吐量下降的常见根因。
这五个指标并非孤立：丢包会引发重传，重传占用带宽并抬高时延；排队时延增大又会导致抖动上升。测量时必须同时观察，才能定位真正的瓶颈。
测量方法与工具选择
带宽测量通常不需要主动发包，直接读取接口协商速率或链路规格即可。在 Linux 上可用 ethtool eth0 查看 Speed 字段，在交换机上查看端口状态。若需测量端到端可用带宽，则使用 iperf3 在两端建立 TCP 或 UDP 流，观察报告中的 Bitrate。
时延测量最常用的是 ICMP ping。执行 ping -c 100 10.0.0.1 后，关注输出中的 min/avg/max/mdev 四个值：avg 是平均往返时延（RTT），mdev 是平均偏差，可粗略反映抖动。注意 ping 测的是往返时延，若需单向时延，必须两端时钟同步，使用 owamp 或 TWAMP 协议。
抖动测量有两种常见做法：一是用 ping 连续发包，计算相邻 RTT 差值的绝对值或标准差；二是用 iperf3 的 UDP 模式，报告中的 Jitter 字段直接给出。对于实时业务，通常关注 95 分位抖动而非平均值。
丢包率测量可用 ping 的统计行：100 packets transmitted, 98 received, 2% packet loss。更精细的路径级丢包定位用 mtr，它逐跳显示丢包率，能区分是本地链路还是中间某跳的问题。注意 ICMP 可能被限速，mtr 的丢包率需结合 TCP 探测交叉验证。
吞吐量测量用 iperf3 最直接。TCP 模式下：
iperf3 -c 10.0.0.1 -t 30 -P 4-t 30 表示持续 30 秒，-P 4 表示 4 条并行流。UDP 模式下加 -u -b 100M 指定目标速率，报告会同时给出吞吐量、抖动和丢包率，一次测量覆盖三个指标。
误差分析与测量注意事项
测量结果的可信度取决于对误差的控制。最常见的误差来源有六类：
- 时钟不同步：单向时延测量中，两端时钟偏差会直接叠加到时延结果上。若偏差 10 ms，测得的单向时延就可能有 10 ms 的系统误差。解决方法是使用 NTP 或 PTP 同步，或改用往返时延规避。
- 采样周期过短：只发 10 个包测丢包率，1 个包丢失就是 10%，统计意义不足。一般建议至少 100 个包，抖动测量建议 1000 个以上。
- 中间设备缓存：大缓冲区会吸收突发，使短时测量看不到丢包，但排队时延已经升高。测量时应同时观察时延和丢包。
- 工具自身开销：高速率下 iperf3 的 CPU 占用可能成为瓶颈，导致测得的吞吐量低于链路真实能力。应监控两端 CPU，必要时用多线程或专用测试仪。
- 背景流量干扰：测量期间若有其他业务占用链路，结果不可复现。应在维护窗口或隔离环境测量。
- ICMP 限速：许多设备对 ICMP 响应做限速，ping 和 mtr 的丢包率可能虚高。应以 TCP/UDP 探测为准。
一次完整的测量示例
假设要评估一条从办公网到云服务器的链路质量。第一步，用 ethtool 确认本地接口为 1000 Mbit/s。第二步，ping -c 200 -i 0.05 云服务器IP，得到 avg RTT 28 ms、mdev 4 ms、丢包 0.5%。第三步，mtr -r -c 100 云服务器IP，发现第 7 跳丢包 3%，但后续跳丢包回落，说明该跳可能只是 ICMP 限速，并非真实丢包。第四步，iperf3 -c 云服务器IP -t 30 -P 4，TCP 吞吐量 320 Mbit/s，远低于 1000 Mbit/s，结合 RTT 28 ms 可判断是 TCP 窗口受限而非链路带宽不足。第五步，iperf3 -c 云服务器IP -u -b 200M -t 30，UDP 报告抖动 6 ms、丢包 1.2%，说明链路在 200 Mbit/s 下已开始出现排队。
这组数据指向的结论是：链路带宽充足，但时延偏高导致 TCP 吞吐量上不去，同时抖动和轻微丢包会影响实时业务。优化方向应是调整 TCP 窗口或启用 BBR 拥塞控制，而非扩容带宽。这正是测量驱动优化的典型路径——先量化，再判断，最后才动手。