吞吐测试基础概念
各位同学好，我是老张。做了十几年网络性能优化，今天咱们来聊聊吞吐测试最基础的东西。别小看这些概念，我见过太多人连吞吐量和带宽都分不清，就开始调优，结果越调越乱。
什么是吞吐量
吞吐量，说白了就是单位时间内实际传输的数据量。你想想看，一条高速公路限速120km/h，但实际能跑多快？那得看车流量、路况、收费站效率。吞吐量就是那个"实际速度"。
在计算机网络里，吞吐量通常用bps（bits per second）来衡量。我习惯看实际场景：
- TCP吞吐量：应用层实际能收到的数据速率
- UDP吞吐量：发送端到接收端的有效载荷速率
- 磁盘吞吐量：读写IO的MB/s
核心要点：吞吐量是"实际测出来的"，不是"理论上标出来的"。我在项目里经常跟开发说：别信网卡标称值，上机跑一跑才知道真本事。
带宽与吞吐量的区别
这两个词经常被混用，但本质完全不同。我做个表格对比一下：
| 维度 | 带宽 | 吞吐量 |
|---|---|---|
| 定义 | 理论最大传输能力 | 实际有效传输速率 |
| 单位 | bps（如1Gbps、10Gbps） | bps 或 pps（包/秒） |
| 影响因素 | 物理介质、调制方式 | 协议栈、CPU、内存、网卡 |
| 典型值 | 1Gbps 网卡 = 1000Mbps | 实际可能只有 600-800Mbps |
| 比喻 | 水管粗细 | 实际水流速度 |
嗯，这里要注意：带宽是上限，吞吐量是下限。我曾经帮一家公司排查问题，他们买了10G网卡，结果吞吐只有2Gbps。老板问我是不是网卡坏了。我说：网卡没坏，是你的协议栈和CPU扛不住。
影响吞吐的关键因素
吞吐量上不去，别急着怪网络。我总结四个核心瓶颈：CPU、内存、网卡、协议栈。咱们一个一个说。
1. CPU
CPU是协议栈的大脑。每个数据包进来，都要经过中断处理、协议解析、数据拷贝。CPU忙不过来，吞吐自然上不去。
- 中断处理：网卡每收一个包就触发中断，CPU得停下手里活去处理。包多了就是"中断风暴"。
- 上下文切换：应用进程和内核之间来回切换，每次切换都有开销。
- 缓存命中率：L1/L2/L3缓存命中率低，CPU就得等内存，性能直接腰斩。
我的经验：做吞吐测试时，先看CPU的%soft和%irq。如果这两个加起来超过30%，CPU大概率是瓶颈。我曾经调一个项目，把中断绑到特定核心上，吞吐直接翻倍。
2. 内存
内存影响吞吐的方式比较隐蔽，但杀伤力很大。你想想看，数据从网卡到应用，要经过多少次内存拷贝？
- 网卡DMA到内核缓冲区
- 内核协议栈处理
- 拷贝到用户空间
- 应用处理
每一步都在吃内存带宽。如果内存频率低、通道少，或者NUMA架构下跨节点访问，吞吐直接打折扣。
避坑指南：我曾经在AMD EPYC平台上做测试，发现吞吐只有Intel的一半。查了半天，原来是内存跨CCD访问，延迟高了30%。解决方案：用numactl绑定内存和CPU在同一NUMA节点。
3. 网卡
网卡不只是"插上去就能用"。现代网卡有很多特性，用好了是神器，用不好是累赘。
| 特性 | 作用 | 注意事项 |
|---|---|---|
| RSS（接收端缩放） | 多队列分发到多CPU核心 | 需要配置哈希策略 |
| TSO/GRO | 减少CPU参与的分段/合并 | 某些场景下反而增加延迟 |
| LRO | 大包合并减少中断 | 可能破坏TCP时间戳 |
| XDP/DPDK | 绕过内核直接处理包 | 需要应用配合改造 |
我个人习惯：拿到新网卡先看固件版本，再看驱动参数。很多性能问题就是驱动默认参数太保守导致的。
4. 协议栈
协议栈是吞吐的"隐形杀手"。Linux内核协议栈默认是为通用场景优化的，不是为高性能吞吐优化的。
- TCP缓冲区：默认只有几十KB，高延迟链路下根本跑不满带宽
- 拥塞控制算法：CUBIC适合长肥网络，BBR适合有丢包的场景
- 套接字选项：SO_RCVBUF、SO_SNDBUF、TCP_NODELAY 这些不调，性能差一大截
- epoll vs select：高并发下epoll是必须的，select撑不住
一句话总结：协议栈调优就是让内核少干活、让网卡多干活、让CPU干对活。
知识体系总览
下面这张图把吞吐测试的核心逻辑串起来了。我建议你保存下来，后面每学一章都回来对照一下。
这张图把今天的内容串起来了。带宽是天花板，吞吐量是实际水位。CPU、内存、网卡、协议栈这四个因素，任何一个掉链子，水位就上不去。
好了，第一章就到这里。记住我今天说的：别迷信标称值，动手测才是王道。后面我们会一步步深入每个因素的调优方法。