zhuyuhe6661. 为什么带宽测试我会首选 PsPing
PsPing 这个工具我用了很多年，最开始单纯拿它当 ping 的加强版用，测延迟、测端口连通性，比系统自带的 ping 灵活太多。直到有一次做机房链路验收，甲方要求给出两台服务器之间的 TCP 和 UDP 真实吞吐上限数据，我顺手用 PsPing 跑了一遍，结果发现它在带宽测试上的表现比我想象中更靠谱。这篇笔记是系列的第 14.5 篇，专门把 TCP/UDP 带宽测试这部分的操作和思考整理出来，方便自己以后查，也希望能帮到正在折腾网络性能验证的朋友。
适合看这篇笔记的人，主要是三类：一是在 Windows 环境做网络排查、被"用户报网速慢"这类问题缠住的运维；二是做链路割接、专线验收、机房搬迁前后需要留下吞吐数据的网络工程师；三是刚接触网络测试、想搞明白 TCP 和 UDP 打流到底怎么玩、测试结果怎么解读的入门者。PsPing 是 Sysinternals 套件里的小工具，单个 exe 就能跑，不需要安装，非常适合做快速验证。
相比 ping 只能测三层 ICMP 连通性，PsPing 能直接测 TCP 端口连通性、TCP 延迟、TCP 带宽、UDP 延迟和 UDP 带宽。尤其是 UDP 这一块，系统自带的 ping 完全做不到，而很多业务恰恰是 UDP 承载的，比如音视频流、工业协议、游戏同步，这就让 PsPing 成了我 Windows 环境下的常备工具。工具虽小，但能解决大问题，这篇文章我会把完整的测试思路、命令参数、结果解读和常见坑都过一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 吞吐测试工具选型：PsPing、iperf3 与 ping 的定位差异
2.1 三层工具和四层工具不能混用
先说一个很多人容易绕进去的点：ping 测的是三层 ICMP 连通性，PsPing 和 iperf3 测的是四层 TCP/UDP 传输能力，两者不能互相替代。ICMP 不需要监听端口，也不经过 TCP 握手，所以很多防火墙默认放行 ICMP，但对 TCP/UDP 业务端口做严格限制。这就解释了为什么会出现"ping 得通，但业务连不上"的诡异现象。
我自己排查过不少案例，最典型的是一台设备的 8080 端口，ping 通、Telnet 不通、业务系统报连接超时。最后定位到是安全组规则只放行了 ICMP，把 TCP 端口给挡了。所以端口连通性和带宽测试，一定要用四层工具来做，ping 只能作为最基础的存活判断，不能拿它当业务连通性依据。
TCP 层面的测试绕不开三次握手。客户端向服务端发起连接时，要经历 SYN、SYN-ACK、ACK 三个阶段。如果中间链路质量差，握手包丢失重传，建立连接的时间就会明显变长。PsPing 测 TCP 延迟时，统计的就是包括握手在内的完整连接往返时间，这就比 ICMP ping 多了对中间设备处理能力的感知。做带宽测试时，长连接一旦建立，后续的吞吐表现主要受拥塞控制、接收窗口、丢包重传等因素影响，这也是 TCP 测试数据比 UDP 更容易出现波动的原因。
2.2 为什么 Windows 场景下我优先选 PsPing
iperf3 是跨平台打流工具里的老大哥，功能强大，参数丰富，能测 TCP、UDP、带宽、抖动、丢包率，还有 JSON 输出方便脚本处理。但它有几个在 Windows 环境下的痛点：一是需要在客户端和服务端分别部署，服务端要手动启动，Windows 上经常要配防火墙例外，不然客户端连不上；二是 iperf3 对新版本兼容性有要求，跨版本测试可能出现协议不匹配；三是它默认只测单向流量，要想测双向得额外加参数。
PsPing 的优势恰恰在简单直接。它和 ping 一样的命令行风格，一台机器当服务端、一台机器当客户端，不需要额外装服务，双方只要都能访问目标端口就能测。在 Windows Server 上做快速验证时，从 Sysinternals 下载解压就能用，不需要管理员权限，不需要安装服务，特别适合现场排障。如果你要长期做性能基准测试、要出自动化报告，那 iperf3 更合适；如果是临时验证、快速定位、Windows 环境为主，PsPing 的性价比非常高。
我个人的习惯是两者都装，PsPing 负责快速排查和现场验证，iperf3 负责正式的性能基准测试，两边对照着看数据，不容易被单一工具的偏差误导。
2.3 工具准备：下载、放置和基本用法
PsPing 的获取方式很简单，从微软 Sysinternals 官网下载 PsTools 工具包，里面包含 psping.exe。也可以直接搜 Sysinternals PsPing 的独立下载链接，拿到一个 psping.exe 文件。我习惯把它放到 C:\Windows\System32 或者自己建一个 C:\Tools 目录并加到 PATH 环境变量里，这样在任何目录下都能直接敲 psping 命令，不用每次写全路径。
第一次运行建议先敲 psping -? 看一下帮助信息，确认版本和参数。老版本和新版本在 UDP 带宽测试的参数上略有差异，这一点务必留意。我见过有同事拿着旧版命令去跑新版，结果 --b 参数不识别，报了参数解析错误，还以为是网络问题。先看帮助，永远是排错的第一步。
3. TCP 带宽测试：从三次握手到吞吐上限的实测方法
3.1 TCP 模式和 UDP 模式的本质区别
TCP 带宽测试的基础是可靠的字节流传输，测试过程中，PsPing 会在客户端和服务端之间建立一个真实的长连接，然后持续发送数据。数据的发送速度并非一味求快，而是由 TCP 协议栈的拥塞控制机制动态调节。网络顺畅时，发送窗口不断增大，吞吐逐步爬升；一旦出现丢包，协议栈会主动降速重传，吞吐立刻回落。这就意味着，TCP 带宽测试结果反映的是"在可靠传输约束下的实际可用带宽"，和业务系统真实体验最接近。
UDP 则完全不同，它不保证送达，不处理重传，不维护连接状态。发送端按固定速率往链路上丢数据包，能不能到、到了多少，全靠链路质量。UDP 带宽测试的价值，在于能直接压出链路的物理承载上限，同时观察在超过上限时丢包率如何变化。我在测试中经常看到 TCP 跑到 900Mbps 就上不去了，但 UDP 能以 1.5Gbps 的速度发送，只是丢包率到了 30%，这种对比能非常清楚地说明链路瓶颈在哪里。
3.2 先确认连通性再谈带宽
正式做带宽测试之前，我建议先跑一轮 TCP 端口连通性测试，确认四层链路是通的。命令格式很简单，在目标地址后面直接带端口号即可：
bash复制psping -t -i 0 192.168.1.100:8080
这里的 -t 表示持续测试直到手动停止，-i 0 表示连续发送不间隔。如果端口通，会看到类似 TCP connect to 192.168.1.100:8080: Succeeded 的输出，并附带连接耗时。如果不通，会显示 Failed 或者超时。这一步看似多余，但能帮你在做带宽测试前就排除端口不通、防火墙拦截、服务未启动等低级问题，省得后续数据没法解释。
测完连通性，再用 TCP 模式做带宽测试。PsPing 的 TCP 带宽测试本质上还是连续发送数据包，和 iperf3 的 stream 模式类似，但参数更少、更容易上手：
bash复制psping -t -i 0 -w 5 192.168.1.100:8080
-w 5 表示先预热 5 秒再做统计。为什么要预热？因为 TCP 连接刚建立时，拥塞窗口还处于慢启动阶段，前面几秒的吞吐不会到达上限，如果不预热，算出来的平均值会被拉低，数值不真实。我一般在压测时会给足 10 到 20 秒预热，正式测试至少跑 30 秒，这样得到的数据才稳定可信。
3.3 用参数控制传输速率和包大小
PsPing 的 TCP 测试默认会以尽可能快的速度发包，但也可以通过 -l 指定数据包大小来模拟不同业务特征。比如模拟网页小包交互，可以用 -l 512；模拟文件传输大包，可以用 -l 1400。这里有一个细节需要注意：-l 的单位是字节，需要根据链路 MTU 来合理设置。以太网默认 MTU 是 1500 字节，去掉 IP 头和 TCP 头，TCP 载荷最大约 1460 字节，如果你设置 -l 2000，数据包会被 IP 层分片，反而可能降低吞吐。
想要控制发送速率，可以配合 -i 参数，单位为秒。-i 0 表示不等待、连续发送，测的是最高吞吐；-i 0.1 表示每 100 毫秒发一个包，模拟低速率交互场景。实际项目中，如果只是验证链路带宽，直接用 -i 0 即可。如果要做业务模拟，则要结合应用的实际发包特征来调整 -l 和 -i。
3.4 带宽时延积（BDP）与 TCP 窗口的关系
TCP 吞吐上限不是由带宽单独决定的，而是由带宽和往返延迟共同决定，这个乘积就是带宽时延积（Bandwidth-Delay Product, BDP）。简单理解，TCP 是"发出去等确认"的协议，在等待 ACK 的这段时间里，链路上能有多少数据在飞，取决于带宽乘以延迟。如果接收窗口比 BDP 小，发送端永远等 ACK，带宽再大也跑不满。
BDP 的计算公式是：BDP = 带宽（bit/s） × 往返时延（s）。举个例子，带宽是 1Gbps，RTT 是 10 毫秒，那么 BDP = 1Gbps × 0.01s = 10Mbit，换算成字节约 1.25MB。也就是说，TCP 接收窗口至少要大于 1.25MB，才能充分利用这条链路。Windows 默认开启了 TCP 自动调优，一般情况下会动态调整窗口，但你手动配置过相关注册表或者公司安全策略禁用了自动调优，测试带宽时就会遇到吞吐上不去的现象。
遇到这种情况，可以在客户端检查当前 TCP 全局参数：
bash复制netsh interface tcp show global
重点看接收窗口自动调优级别（Receive Window Auto-Tuning Level）是否处于 Normal 或 Enabled。如果你发现它是 Disabled，可以尝试临时开启：
bash复制netsh interface tcp set global autotuninglevel=normal
此外，netsh interface tcp set global timestamps=enabled 这个参数也值得关注。TCP 时间戳选项会在每个包上多占 12 字节，对带宽影响不大，但在某些 NAT 或防火墙设备上，开启时间戳会导致部分包被丢弃，吞吐出现周期性下跌。如果测出来数据忽高忽低，可以试试关闭时间戳：
bash复制netsh interface tcp set global timestamps=disabled
这属于排查型操作，不是所有环境都适用，但实测中确实遇到过不少因为时间戳问题导致吞吐异常的案例。
3.5 一次标准的 TCP 带宽测试流程
我把一次完整的测试流程整理成清单，方便你在现场照着操作：
- 服务端确认目标端口有服务在监听，或者用 PsPing 对端做监听测试。
- 客户端先跑连通性测试：psping -t -i 0 服务器IP:端口。
- 开启带宽测试：psping -t -i 0 -w 10 服务器IP:端口。
- 记录稳定后的吞吐值，观察至少 30 秒。
- 如果需要测反向流量，交换客户端和服务端角色再测一轮。
- 多次测试取平均值，排除偶发波动。
测试过程中，我会用任务管理器或者性能监视器同时观察 CPU 和网卡利用率。如果 CPU 已经跑满而吞吐还没到上限，说明瓶颈在主机性能而非链路，这个数据不能代表真实网络能力。如果网卡利用率已经接近 100%，那链路基本拉满了，再往上压已经没有意义。
4. UDP 带宽测试：压出链路真实上限与丢包观察
4.1 PsPing 的 UDP 测试模式和参数
UDP 带宽测试是 PsPing 相对冷门但很有价值的功能。它的命令格式和 TCP 模式类似，但多了 -u 参数表示 UDP 模式，同时用 -b 指定目标带宽，用 -l 指定 UDP 数据包大小：
bash复制psping -u -b 100000000 -l 1400 192.168.1.100:9000
这里的 -b 100000000 表示目标带宽是 100Mbps，单位是 bit/s，注意不是 Byte/s。-l 1400 表示每个 UDP 包的数据载荷是 1400 字节。为什么用 1400？因为以太网 MTU 是 1500，去掉 IPv4 头 20 字节和 UDP 头 8 字节，UDP 载荷最大可以到 1472 字节，留一点余量给 VLAN Tag 等额外开销，1400 是常见的安全值。
实际测试中，UDP 打流和 TCP 不同，发送端会按照你设定的 -b 参数恒定速率发包，不管对端能不能处理。因此在测试之前，要根据被压测设备的性能合理设置带宽值，不要一上来就压 10Gbps，否则可能直接把对端机器打到 CPU 跑满、网卡缓冲溢出。我习惯从低到高逐级加压，先跑 100Mbps，再 200Mbps、500Mbps、1Gbps，每档跑 10 秒，观察丢包率变化，再决定要不要继续加压。
4.2 UDP 丢包率：判断链路承载能力的关键指标
UDP 测试最关键的输出就是丢包率。PsPing 会统计发送包数、接收包数、丢包数和平均延迟。当发送速率低于链路承载上限时，丢包率接近 0；一旦超过上限，丢包率会快速攀升。这个拐点，就是链路的真实吞吐上限。
举个例子，有一次我验证一段机房互联链路，带宽标称是 1Gbps，用 TCP 测试稳定在 940Mbps，紧接着用 UDP 测试从 800Mbps 开始压，到 950Mbps 时丢包率为 0.1%，到 1Gbps 时丢包率跳到 2%，到 1.2Gbps 时丢包率到了 18%。这个结果说明链路承载能力大约在 950Mbps，不会达到标称 1Gbps。后来和运营商核对，才知道中间有一段线路是共享带宽，高峰期确实有损耗。
UDP 测试中，延迟数据也有参考价值。当链路未饱和时，UDP 延迟和 TCP 延迟接近；链路饱和时，UDP 延迟会因为中间设备排队而明显增大。如果丢包率上升的同时延迟也飙升，基本可以确认瓶颈在中间网络设备的转发能力，而不只是线路带宽。
4.3 UDP 测试的注意事项：别把压测做成攻击
UDP 打流是一个高强度的发包行为，在测试时要特别注意两点：一是控制好带宽值，二是选择好测试时间窗口。很多网上的教程和演示喜欢用 UDP 洪水攻击做例子，这不是正常的性能压测，而是攻击行为，会打挂目标设备，还可能触发 IDS/IPS 告警，我强烈不建议在非授权环境下做这种操作。
正规的链路压测，应该选择在业务低峰期进行，并且提前和相关团队沟通，获得授权后再执行。PsPing 的 UDP 测试是持续发包，如果你设置了过高的 -b 值，目标机器可能直接被压垮，造成业务中断。我见过一次事故，同事在办公网里用 UDP 打流测吞吐，一个 500Mbps 的流量直接把核心交换机的 CPU 打满，全网断网十分钟，教训非常深刻。压测之前一定要评估测试范围、流量大小、时间窗口，做到可控才动手。
4.4 TCP 与 UDP 结果怎样对照解读
在同一链路上分别做 TCP 和 UDP 测试，你会得到两组数值。最理想的状态是两者接近，说明链路干净，TCP 协议开销在合理范围内。如果 TCP 远低于 UDP 的稳吞吐，问题大概率出在以下几个方面：
第一，TCP 接收窗口太小，限制了在途数据量，吞吐上不去；第二，链路存在中间设备丢包，导致 TCP 频繁重传降速，而 UDP 不重传，丢包只是被统计出来，不影响发送速率；第三，发送端或接收端的 CPU 处理能力不足，TCP 协议栈开销比 UDP 大很多，CPU 跑满了之后 TCP 吞吐无法继续增长，UDP 因为协议栈开销小还能继续发。
我自己判断链路是否存在隐患，习惯这样做：先跑 UDP 测试找到丢包拐点，再用 TCP 验证业务是否受影响。如果 TCP 吞吐明显低于 UDP 丢包拐点，说明链路存在丢包或者中间设备处理问题，需要抓包定位；如果 TCP 吞吐和 UDP 拐点接近，说明链路承载能力确实到了上限。这种组合测试法比单一测试更能反映全貌。
5. 吞吐上限分析：影响带宽测试结果的那些隐藏因素
5.1 MTU、分片和 PMTU 黑洞
带宽测试结果不理想时，第一个要怀疑的是 MTU。数据中心内部通常使用 9000 字节巨型帧，互联网链路的 MTU 则是 1500 字节。如果两端 MTU 配置不一致，大包会被中间设备丢弃或分片，导致 TCP 性能严重下降，而小包流量看起来正常。这就是为什么有些场景下，用小包测延迟没问题，一用大包测带宽就惨不忍睹。
PsPing 的 -l 参数能帮你快速定位 MTU 问题。你可以在同一链路上分别用 -l 1400 和 -l 8000 测带宽，对比结果。如果小包带宽正常，大包带宽骤降，或者大包延迟异常升高，基本可以判断是 MTU 不一致造成的。更典型的场景是 PMTU 黑洞：防火墙或安全设备丢弃了 DF 标志置位的分片包，却不返回 ICMP 差错消息，导致 TCP 连接建立成功，但大数据包传输时被静默丢弃，吞吐极低。
遇到这种情况，可以尝试在客户端调整 TCP 最大段大小（MSS），或者在网卡属性里手动把 MTU 调到 1400 再测试。如果带宽恢复正常，说明路径上存在 MTU 限制设备，需要进一步和网络团队确认。注意，修改 MTU 会影响所有流量，要在业务低峰期操作。
5.2 中间设备的会话限制和带宽策略
防火墙、负载均衡、流量整形设备都会对流经的流量做控制，这些控制策略往往会对带宽测试结果产生直接影响。常见的隐藏因素包括：防火墙的会话数限制，超出限定值后新连接被丢弃；负载均衡的会话保持策略，导致长连接被强制切断；流量整形设备的带宽限速，即使物理链路有 1Gbps，策略只放行 300Mbps。
判断是否存在带宽策略限制，最简单的办法是看 UDP 测试的丢包拐点。如果带宽正好卡在一个整数值，比如 100Mbps、500Mbps，丢包率突然从 0 跳到 10%，大概率是策略限速。要是拐点在一个比较散的值，比如 937Mbps，那更可能是物理带宽或协议开销的自然上限。这个经验帮助我区分过好几次"运营商限速"和"线路质量问题"。
另外，NAT 设备对 UDP 流量的处理方式也要注意。很多 NAT 会话表对 UDP 的空闲超时设置很短，如果 UDP 打流是突发性的，中间设备可能已经把会话表项清掉了，后续报文被丢弃。测试持续流转时没问题，但一停再发，前几秒的包可能全部丢失。做 UDP 测试时，我建议至少连续跑 60 秒以上，才能观察出会话表老化导致的丢包问题。
5.3 WSL2、虚拟机、容器环境下的测试误区
现在很多开发环境是 Windows 上跑 WSL2、虚拟机或者 Docker 容器，在这些环境里做网络性能测试要格外小心，因为虚拟化网络的转发路径和物理网络完全不同。
以 WSL2 为例，它默认使用 NAT 模式，Windows 宿主机和 WSL2 之间有一层虚拟交换机。在 WSL2 里跑 iperf3 或者 PsPing 测 UDP 和 Windows 宿主机的 Windows 通讯，得到的吞吐数据受虚拟网卡和 NAT 转发性能影响，不能代表物理网卡的真实能力。我实测过 WSL2 里的 UDP 通讯，单向吞吐经常比宿主机直连低 20% 到 30%，延迟也偏高 1 到 2 毫秒。如果这时候拿 WSL2 的测试数据去评估物理链路，结论就会完全跑偏。
容器环境也是一样。Docker 默认的 bridge 网络通过 NAT 转发，流量会经过 iptables 规则处理，性能损耗不小。我在排查容器网络带宽问题时，习惯先在宿主机上直接测试物理网卡，再进容器测试，两步数据一对比，就能把虚拟化层消耗的带宽算出来。记住，带宽测试的最终目标，应该是反映承载真实业务的物理链路能力，而不是虚拟化中间层的转发能力。
5.4 对照测试法：把问题定位到具体环节
有一次客户反馈两台服务器之间传输文件速度只有 50MB/s，而链路标称是万兆。我用 PsPing 分别做了三次测试：第一次直接测客户两台服务器的 TCP 吞吐，第二次我找了一台同网段的其他机器做对照，第三次在两台服务器同机柜的交换机上做端口镜像抓包。最终发现是客户服务器网卡驱动版本太老，开启硬件卸载功能后 TCP 校验和计算报错导致大量重传。更新驱动后，吞吐立刻从 50MB/s 提升到 900MB/s 以上。
这个案例说明了对照测试法的重要性。带宽不达标时，不要急着下结论说是链路问题，先按下面的顺序逐一排除：
- 服务端和客户端的网卡速率、双工模式、驱动版本是否正常。
- 用同网段的第三台机器做测试，排除单台主机问题。
- 检查中间设备的端口统计和错误计数，看是否有 CRC 错误或丢弃计数增长。
- 用 UDP 测试排除 TCP 协议栈的干扰，确认链路物理承载能力。
每层都做了对照之后，瓶颈通常就能浮出水面。最怕的是不做对照，直接拿一组数据去质疑链路运营商，结果来回扯皮好几轮才发现是主机问题，浪费大量时间。
6. 常见问题与排查技巧实录
6.1 端口被占用：bind: only one usage of each socket address
在做 TCP 或 UDP 测试时，偶尔会报 bind: only one usage of each socket address 这类错误。这个错误的本质是端口已经被其他进程占用，新进程无法绑定同一个端口。常见触发场景有两个：一是上一个测试进程没有正常退出，端口仍被占用；二是测试端口和业务端口冲突，被业务进程占用了。
排查方法很简单，Windows 下用 netstat 查看端口占用情况：
bash复制netstat -ano | findstr 8080
找到占用端口的进程 ID 后，再用 tasklist 确认是哪个进程：
bash复制tasklist | findstr 12345
如果是残留的测试进程，直接结束进程；如果是业务进程占用了端口，换一个测试端口就行。我曾经遇到过 Docker 容器端口映射失败的问题，报错信息是 ports are not available: exposing port tcp 0.0.0.0:xxxx，排查后发现是主机上已有其他进程占用了该端口，和 PsPing 测试报错同源，处理方法也是一样的。这种问题看起来吓人，实际上几分钟就能定位。
6.2 TCP 能 ping 通但连不上：防火墙和安全组的典型症状
TCP 能 ping 通但业务连不上，是我遇到最多的一个排查场景。ping 通说明三层网络是通的，连不上说明四层以上有问题。用 PsPing 能帮你在几分钟内区分出问题到底出在哪一层。
比如测试命令 psping -t -i 0 192.168.1.100:502，如果返回 TCP connect to 192.168.1.100:502: Failed，可能的原因有三种：目标端口没有服务监听、防火墙拦截了 TCP 502 端口、中间设备策略丢弃了 SYN 包。先确认目标服务有没有监听，再用 tcpdump 或 Wireshark 在服务端抓包，看有没有 SYN 包到达服务端。如果 SYN 包到了但服务端没有回应 SYN-ACK，问题在服务端防火墙或服务本身；如果 SYN 包根本没到，问题在中间防火墙或路由策略。
这个场景在工控领域尤其常见，比如 Modbus TCP 用的是 502 端口，经常出现能 ping 通交换机但 ModScan 连不上的问题，原因基本都是防火墙只放行了 ICMP，没放行 TCP 502。C# 或 Java 程序里做 TCP 通信封装时，也经常因为对端防火墙拦截而报连接超时，先断开后自动重连的逻辑越写越复杂，根治办法还是先把网络策略的正确性确认清楚。
6.3 测试结果忽高忽低：TCP 自动调优与时间戳的坑
带宽测试结果忽高忽低，是最容易让人抓狂的问题。排除链路本身波动后，我有两个重点排查方向。
第一是 TCP 接收窗口自动调优。Windows 默认开启自动调优，但它并不总是最优解。在某些硬件网卡或老版本系统上，自动调优可能失效，导致接收窗口始终保持默认值，吞吐被限制。可以用 netsh interface tcp show global 查看当前状态，再对照测试数据判断是否要手动关闭或调整。我在高带宽低延迟的内网环境里，经常需要把接收窗口调大才能跑满万兆带宽。
第二是 TCP 时间戳参数。在部分路由器和防火墙上，带有时间戳选项的 TCP 包会被特殊处理，造成 ACK 延迟或丢包。如果你测试时发现吞吐波形呈周期性锯齿状，可以尝试关闭 TCP 时间戳：netsh interface tcp set global timestamps=disabled。这个参数修改后立即生效，不需要重启，非常适合做 A/B 对照验证。我有个客户就是这种情况，TCP 吞吐从 80Mbps 波动到 400Mbps，关闭时间戳后稳定在 950Mbps，问题彻底解决。
另外，测试时最好关闭网卡节能模式。有些笔记本或低功耗服务器的网卡支持节能以太网（EEE），空闲时降低速率，流量突发时再提升，导致测试结果前后差异很大。在网卡高级设置里把"节能以太网"和"绿色以太网"关闭，再测一次，数据通常会稳定很多。
6.4 测试报告应该记录哪些数据
最后聊聊测试记录。做过链路验收的都知道，测试报告里的数据如果不够完整，出了问题回溯时根本没法定位。我习惯在每次带宽测试时至少记录以下信息：
| 记录项 | 说明 |
|---|---|
| 测试时间 | 精确到分钟，方便和业务告警时间关联 |
| 客户端/服务端 IP | 写明网卡和所在位置 |
| 测试工具及版本 | PsPing 版本不同参数可能有差异 |
| 测试命令 | 完整保留命令文本，不要只写结果 |
| TCP/UDP 带宽值 | 分开记录，分别取稳定值 |
| 丢包率和延迟 | 尤其是 UDP 测试的丢包拐点 |
| 网卡速率/CPU 利用率 | 辅助判断瓶颈在主机还是链路 |
| 中间设备 | 交换机型号、防火墙策略等，方便后续排查 |
有了这份记录，就算过了几个月再有人问起链路情况，也能快速还原当时的测试环境和条件。我自己的习惯是测试完立刻把输出保存成文本文件，标注好测试编号，这份原始数据比任何总结性描述都更有说服力。
写在最后：一点个人经验
从最开始只会敲 psping -t 测连通性，到现在能用它完整评估一条链路的 TCP/UDP 吞吐上限，中间踩过不少坑。让我印象最深的不是命令本身，而是在一次压测中把核心交换机 CPU 打满导致全网中断的事故，从那以后，我每次做链路压测都会先做风险评估、控制测试窗口、提前沟通协调，再急的问题也不能拿生产环境的安全去赌。
我个人在实际操作中的体会是，PsPing 虽然小巧，但它把三层探测和四层性能测试做进了同一个工具里，排查问题时不用来回切换工具，效率极高。如果你还在用系统自带 ping 做网络验证，强烈建议花十分钟下载一个 PsPing 试试，从端口连通性到 TCP 延迟再到 UDP 吞吐，一条命令就能出数据，你会回来感谢它的。