TG咨询做物理机网络吞吐测试时，最容易误判的并不是工具不会用，而是测试条件没有对齐。同一台服务器接入同一台交换机，使用单向TCP、多流UDP或双向流量，结果可能完全不同。要得到可比较的结论，应先确认链路，再固定参数，最后结合CPU、网卡队列和丢包情况分析。
误区一：把网卡标称速率当成实际吞吐
10GbE、25GbE或100GbE表示端口的链路速率，并不等于应用能够获得的有效数据速率。以太网帧、IP头、TCP或UDP头都会产生开销，PCIe通道、交换机端口配置和对端设备也可能成为瓶颈。
进行物理机网络吞吐测试前，应检查两端的协商速率、双工状态、链路错误计数和端口是否出现降速。10GbE链路在配置正常、报文较大、CPU余量充足的情况下，TCP有效吞吐通常会接近链路上限，但不应把某个固定数值当作所有环境的合格线。
误区二：只测一次单连接TCP
单个TCP连接受往返时延、拥塞窗口、接收窗口和中断处理影响明显。跨机房、跨园区或经过防火墙时，单流结果尤其可能偏低；多流测试则可能更接近设备的并行处理能力。
建议的对照方式
- 先使用一条TCP连接建立基线，记录吞吐、重传和延迟。
- 再逐步增加并发流，观察吞吐是否继续增长。
- 当吞吐不再提升，检查CPU占用、网卡队列和交换机端口统计，而不是继续盲目增加连接数。
这也是使用iperf3进行物理机网络吞吐测试时常见的差异来源。单流适合观察应用路径的基本能力，多流适合判断链路和网卡的并行承载能力，二者不能互相替代。
误区三：忽略MTU和报文大小
默认MTU通常为1500字节，启用9000字节巨型帧后，单位数据所需处理的报文数会减少，CPU开销可能下降。但巨型帧必须在发送端、接收端、交换机端口和中间链路上保持一致；只改服务器网卡设置，可能导致分片、丢包或连接异常。
测试时应分别记录1500和9000字节环境下的结果，并确认路径中的设备是否支持对应MTU。UDP测试还要特别注意报文大小，过大的数据报可能直接触发丢包，不能仅凭发送端显示的速率判断网络是否达标。
误区四：把CPU瓶颈误认为网络瓶颈
高吞吐网卡需要CPU处理中断、协议栈和数据拷贝。若测试进程、软中断和网卡队列集中在少数核心，即使链路仍有余量，吞吐也可能提前停止。可以在测试期间观察各核心负载、软中断占用、上下文切换以及网卡丢包计数。
RSS会把接收流量分配到多个CPU核心，网卡多队列则决定可并行处理的队列数量。调整CPU亲和性时，应避免把发送进程、接收进程和全部网卡中断都固定到同一个核心。比较前还要固定电源策略、频率状态和后台任务，否则两次物理机网络吞吐测试的差异未必来自网络。
误区五：只关注吞吐，不看PPS、延迟和丢包
吞吐适合描述大块数据传输能力，但不能代表所有网络业务。小报文场景更容易受PPS限制；例如大量短连接、DNS请求或微服务调用，即使带宽没有跑满，也可能出现较高CPU占用和延迟。
建议同时记录平均吞吐、峰值吞吐、PPS、重传率、丢包率和延迟变化。UDP测试中，发送速率应逐级提高，并以接收端统计为准。只要出现持续丢包，就应先判断网卡队列、交换机缓存或接收处理能力是否不足，而不是把更高的发送速率写成测试成绩。
误区六：混淆单向、双向与收发方向
上传和下载可能经过不同的网卡队列、交换机策略或限速规则。双向测试还会同时消耗两端CPU、PCIe带宽和交换机缓存，因此双向总吞吐不一定等于两个单向结果简单相加。
- 先做发送端到接收端的单向测试。
- 交换角色，再测试反方向。
- 最后进行双向测试，并记录两端资源占用和丢包变化。
如果只有一个方向明显偏低，应检查端口限速、流控、路由策略和网卡统计；如果双向时才下降，则更应关注CPU、PCIe通道、交换机缓存及队列竞争。
一套更可靠的测试流程
- 记录服务器型号、网卡型号、链路速率、交换机端口和测试距离。
- 确认两端时间、MTU、驱动和链路协商状态，清除会影响结果的后台传输任务。
- 使用TCP单流、多流和UDP分档测试，分别保存吞吐、延迟、PPS和丢包结果。
- 重复测试至少数轮，比较中位数或稳定区间，不使用一次瞬时峰值代表最终结论。
- 将结果与CPU、软中断、网卡队列和交换机端口计数关联分析。
真正有价值的物理机网络吞吐测试，应能回答“瓶颈在哪里、在什么条件下出现、是否可以复现”，而不只是给出一个看似漂亮的带宽数字。
常见问题
测试工具应该优先选择TCP还是UDP？
TCP适合观察可靠传输和应用可用吞吐；UDP适合压测PPS、队列和丢包边界。两者最好配合使用。
多流越多，结果就越好吗？
不是。多流可以弥补单流受窗口或时延影响的不足，但过多连接会增加CPU和调度开销，可能掩盖真实瓶颈。
巨型帧一定能提高吞吐吗？
不一定。路径完整支持时，巨型帧可能降低CPU开销；只要有设备不支持，就可能出现分片、丢包或连通性问题。
为什么交换机显示满速，服务器结果却偏低？
交换机端口统计反映链路侧流量，服务器还受到CPU、网卡队列、PCIe带宽、协议栈和测试进程的限制，两者统计口径不同。
测试结果怎样才算可信？
应具备明确的拓扑、固定的MTU和并发参数，并能在多轮测试中保持相近结果，同时有CPU、丢包和重传数据作旁证。结论应注明测试时间、方向和环境。
因此，物理机网络吞吐测试的重点不是追求单次最高数字，而是建立可复现、可解释的测试条件。只有把链路、协议、资源和方向同时纳入分析，结果才适合用于故障定位、容量评估和设备选型。
