吞吐量与吞吐率：从定义到实战
吞吐量这个词，做网络的人天天挂在嘴边。但真要问清楚它到底是什么，很多人反而说不明白。我见过不少刚入行的工程师，把带宽和吞吐量混为一谈，结果排查性能问题时走了不少弯路。
说白了，吞吐量（Throughput） 是单位时间内成功传输的数据量。而 吞吐率 通常指吞吐量的速率，比如每秒多少兆字节（MB/s）。两者本质是一回事，只是吞吐率更强调时间维度。
核心定义：吞吐量 = 成功传输的数据量 / 传输时间
单位：bps（比特每秒）、B/s（字节每秒）、pps（包每秒）
举个例子。你家宽带是100Mbps，但实际下载文件只有10MB/s。100Mbps是带宽，10MB/s才是吞吐量。中间差了近10倍，对吧？这就是我们要解决的问题。
影响吞吐量的三大因素
我在项目中排查过无数次吞吐量问题，总结下来，核心因素就三个：窗口大小、拥塞控制、以及链路质量。咱们一个一个说。
1. 窗口大小：TCP的流量阀门
TCP窗口大小，决定了发送方在收到确认前能发多少数据。窗口太小，发送方就得频繁等待ACK，吞吐量自然上不去。
我记得有一次帮客户优化一个跨洋传输的场景。两地延迟150ms，窗口默认只有64KB。你算算：
- 理论最大吞吐量 = 窗口大小 / RTT = 64KB / 0.15s ≈ 427KB/s
- 实际带宽明明是100Mbps，却只能跑出3.4Mbps
这就是典型的窗口瓶颈。后来把窗口调到2MB，吞吐量直接飙到13MB/s以上。
经验公式：理想窗口大小 ≥ 带宽 × RTT
比如100Mbps链路、RTT=100ms，窗口至少需要 100Mbps × 0.1s = 10Mb ≈ 1.25MB
2. 拥塞控制：网络的自我保护
拥塞控制是TCP的"刹车系统"。当网络出现丢包时，TCP会主动降低发送速率。这本来是好事，但有时候刹车踩得太狠，吞吐量就起不来了。
我遇到过最典型的场景：某业务在内网跑得好好的，一上公网就慢得像蜗牛。查了半天，发现是公网链路上偶尔有丢包，TCP Reno算法一检测到丢包，就把拥塞窗口砍半。丢包率只有0.1%，吞吐量却掉了50%以上。
常见的拥塞控制算法对吞吐量的影响：
| 算法 | 特点 | 适用场景 |
|---|---|---|
| Cubic | 高带宽长链路表现好 | 数据中心、广域网 |
| BBR | 基于带宽和RTT探测，不依赖丢包 | 高延迟、有丢包的公网 |
| Reno | 传统算法，丢包敏感 | 低延迟内网 |
注意：不要盲目切换拥塞控制算法。BBR虽然对丢包不敏感，但在某些场景下会抢占其他流的带宽。我曾经在生产环境吃过这个亏，后来加了公平性限制才解决。
3. 链路质量与协议开销
除了窗口和拥塞控制，链路本身的丢包率、延迟抖动、以及协议头开销，都会影响实际吞吐量。
举个例子。你用TCP传1MB数据，加上TCP头（20字节）、IP头（20字节）、以太网头（14字节），实际在链路上传输的数据量是1MB + 协议开销。如果MTU是1500字节，有效载荷只有1460字节，协议开销占比约2.6%。
这还不算应用层协议的开销。HTTP/1.1的每个请求都要建立连接、发送请求头，这些都会吃掉吞吐量。
如何测量吞吐量
测量吞吐量，我建议分三步走：工具选型、场景设计、结果分析。
常用测量工具
- iperf3：最经典的吞吐量测试工具。支持TCP/UDP，可以指定窗口大小、并行流数
- netperf：比iperf更灵活，支持多种协议和测试模式
- wrk / ab：专门测HTTP吞吐量，适合Web场景
我个人最常用的是iperf3。命令简单，结果直观。比如测两个节点间的TCP吞吐量：
# 服务端
iperf3 -s
# 客户端
iperf3 -c 192.168.1.100 -t 30 -P 4这个命令会跑30秒，用4个并行流。为什么要并行流？因为单流可能受限于窗口大小或CPU，多流能压出链路的真实上限。
测量时的避坑指南
我曾经犯过一个低级错误：用iperf3测WiFi吞吐量，结果只有标称带宽的30%。查了半天，发现是测试机和服务器的CPU都在跑其他任务，iperf3进程被限频了。嗯，这个坑我踩过，你们别踩。
测量注意事项：
- 确保CPU、内存不是瓶颈（用top、vmstat监控）
- 关闭防火墙、流量整形等干扰因素
- 多次测试取平均值，排除偶然波动
- 记录RTT和丢包率，辅助分析
吞吐量知识体系
下面这张图，是我自己总结的吞吐量知识框架。从定义到影响因素，再到测量方法，一目了然。
这张图把吞吐量的核心脉络理清楚了。你从中心出发，先理解定义，再掌握三个影响因素，最后学会怎么测量。每一步都有对应的工具和方法。
我的建议：遇到吞吐量问题，先别急着调参数。用iperf3测一下基线，看看实际值离理论值差多少。然后对照上面的三个因素，一个一个排查。80%的问题出在窗口大小和拥塞控制上。
吞吐量这个话题，说深了可以写一本书。但作为实战工程师，你只要记住：定义要清楚、因素要排查、测量要规范。下次遇到"网速慢"的问题，你就能快速定位到底是哪一环出了问题。
想要更多资料，联系可可