1. 吞吐测试基础：吞吐量定义、测试目的、测试场景分类

吞吐测试，说白了就是看你的网络设备或系统到底能扛多少流量。我入行那会儿，有个老前辈跟我说过一句话，我一直记着——「你调得再花哨，吞吐上不去，一切都是白搭」。这么多年下来，我越来越觉得这话在理。

这一章咱们先把地基打牢。吞吐量的概念、为什么要测它、以及最常见的两种测试场景，我都会结合自己的实际经验来讲。嗯，咱们开始吧。

1.1 吞吐量到底是个啥？

吞吐量（Throughput），单位时间内成功传输的数据量。常见的单位有 bps（比特每秒）、pps（包每秒）。

注意我强调的「成功」二字。不是发了多少，而是对方收到了多少。重传的、丢了的，都不算。

我在项目中遇到过好几次，厂商拿着带宽参数吹得天花乱坠，一上真实流量就露馅。所以，别信参数，信实测。

1.2 为什么要测吞吐？

你想想看，一个网络设备买回来，你总得知道它到底能扛多少活吧？测试目的其实就三个核心点：

• 验证性能基线——给设备定个「能力上限」，以后出问题好对比。
• 发现瓶颈——到底是CPU扛不住，还是网卡先跪了？吞吐测试能帮你定位。
• 验收交付——供应商说能跑10G，你测出来只有6G，那得找他算账。

我曾经帮一家客户做数据中心验收，厂商信誓旦旦说所有链路都支持25G。结果我一测，某条链路的吞吐死活上不去，最后发现是光模块不兼容。你说，如果不测，这坑谁填？

1.3 测试场景分类：南北向 vs 东西向

吞吐测试不能一把抓，得看流量怎么走。我一般把场景分成两大类：南北向和东西向。这两个词最早是从数据中心架构里来的，但放到任何网络场景都适用。

1.3.1 南北向吞吐

南北向，就是流量从外部进入内部，或者从内部发到外部。典型场景：

• 用户访问Web服务器
• VPN网关接入
• 负载均衡器处理公网流量

南北向测试的核心关注点是：防火墙、负载均衡、WAF 等边界设备的吞吐能力。这些设备通常要做深度包检测、NAT转换、SSL卸载，性能损耗很大。

我记得有一次帮一个电商平台做压测，他们的防火墙宣称能跑40G。结果我模拟真实用户流量一打，到15G就开始丢包。查了半天，发现是策略规则太多，CPU全耗在规则匹配上了。这就是典型的南北向瓶颈。

1.3.2 东西向吞吐

东西向，就是流量在内部网络之间横向流动。典型场景：

• 服务器之间的数据同步
• 分布式存储的副本复制
• 微服务之间的RPC调用

东西向测试的核心关注点是：交换机、网卡、线缆、操作系统协议栈的转发能力。这里没有复杂的策略处理，拼的就是纯转发性能。

1.4 两种场景的测试差异

我把南北向和东西向的测试要点整理成了一张表，方便你对照：

对比维度	南北向	东西向
测试对象	防火墙、负载均衡、VPN网关	交换机、网卡、OS协议栈
流量特征	连接数多、包大小混合	大流量、大包为主
主要瓶颈	CPU处理能力、规则匹配	背板带宽、PCIe带宽
测试工具	Spirent、IXIA、iperf（带连接模拟）	iperf、netperf、DPDK-pktgen
典型指标	并发连接数、新建连接速率	线速转发、零丢包率

你可能会问，为什么东西向测试更关注大包？因为内部传输的数据块通常很大，比如数据库同步、日志传输。而南北向的流量里，小包（比如HTTP请求）占比很高，小包对设备的CPU压力更大。

1.5 本章知识体系总览

下面这张图，我把本章的核心逻辑串起来了。你可以把它当作一个思维导图来看：

1.6 一个小提醒

吞吐测试不是一锤子买卖。同一个设备，不同包长、不同协议、不同连接数，测出来的结果可能天差地别。我个人的习惯是：先测一个基准（比如64字节小包、1500字节大包），然后再根据实际业务场景调整参数。

另外，千万别在现网直接测吞吐。我曾经见过有人图省事，在业务高峰期跑iperf，结果把核心交换机的CPU打满，业务全挂了。测试环境一定要隔离，这是底线。