3. 带宽与吞吐量：一对容易混淆的“兄弟”
做网络优化这么多年，我经常被问到同一个问题：“带宽和吞吐量到底有什么区别？”
说实话，我刚入行那会儿也搞混过。有一次给客户做方案，信誓旦旦地说“我们带宽是100M，吞吐量肯定没问题”。结果上线后，实际传输速度只有30M。客户当场就炸了。嗯，那次教训让我彻底搞明白了这两个概念。
3.1 带宽概念
带宽，说白了就是“管道的粗细”。
在计算机网络里，带宽指的是单位时间内能传输的最大数据量。单位通常是bps（比特每秒），或者更常见的Mbps、Gbps。
带宽的本质：理论上的最大传输能力。
就像一根水管，带宽就是它的直径。直径越大，理论上能流过的水就越多。
举个例子：
- 100Mbps带宽 = 每秒最多能传100兆比特
- 1Gbps带宽 = 每秒最多能传1000兆比特
我个人习惯把带宽看作“高速公路的限速牌”。它告诉你这条路最快能跑多快，但实际能不能跑那么快，是另一回事。
3.2 吞吐量概念
吞吐量就实在多了。它衡量的是“实际传输了多少数据”。
还是用水管打比方：带宽是水管的理论直径，吞吐量是实际流出来的水量。
吞吐量的本质：实际传输的有效数据量。
单位也是bps，但它是真实测出来的，不是算出来的。
我在项目中遇到过很多次：客户买了100M带宽，但实际下载速度只有5MB/s（约40Mbps）。他们觉得被坑了。其实不是，这里面有协议开销、网络拥塞、服务器限制等各种因素。
小技巧：用 iperf 工具可以快速测出真实的吞吐量。
# 服务端
iperf -s
# 客户端
iperf -c 192.168.1.100 -t 30这个命令会给你一个真实的吞吐量数值，比任何理论值都靠谱。
3.3 带宽与吞吐量的关系
它们的关系，我用一句话总结：带宽是上限，吞吐量是现实。
为什么会这样？你想想看：
- 带宽是物理层的能力，是硬件决定的
- 吞吐量是应用层的结果，受软件、协议、环境共同影响
我曾经做过一个实验：
| 场景 | 带宽 | 吞吐量 | 利用率 |
|---|---|---|---|
| 理想环境（局域网） | 1Gbps | 940Mbps | 94% |
| 跨运营商 | 100Mbps | 30Mbps | 30% |
| 高延迟链路（卫星） | 50Mbps | 5Mbps | 10% |
看到没？同样的带宽，不同的场景，吞吐量天差地别。
避坑指南：我曾经给一个视频直播平台做优化。他们抱怨“100M带宽不够用”。我一测，实际吞吐量只有20M。问题出在TCP窗口设置上，跟带宽半毛钱关系没有。所以，别一上来就加带宽，先查吞吐量。
3.4 影响吞吐量的因素
影响吞吐量的因素太多了。我挑几个最常见的说说：
3.4.1 网络延迟
延迟越大，吞吐量越低。这是TCP协议的特性决定的。TCP需要确认包，延迟高了，确认就慢，发送方就得等。
3.4.2 丢包率
丢包是吞吐量的杀手。哪怕1%的丢包率，也能让吞吐量下降50%以上。因为TCP会触发拥塞控制，主动降低发送速度。
3.4.3 协议开销
每个数据包都有头部开销。TCP/IP头部、以太网头部，加起来至少54字节。如果你传的数据包很小，开销占比就很高。
举个例子：
传64字节的小包，有效数据只有64字节，但总包大小是118字节（含头部）。
利用率 = 64/118 ≈ 54%
也就是说，一半的带宽都浪费在头上了。
3.4.4 应用层设计
这个我深有体会。有一次优化一个文件传输系统，发现每次只传1KB数据就断开连接。重新建立TCP连接的开销比传输本身还大。改成批量传输后，吞吐量直接翻了5倍。
3.4.5 硬件瓶颈
别小看硬件。CPU处理不过来、内存不够、磁盘IO慢，都会拖累吞吐量。我记得有个项目，千兆网卡只能跑出200M，最后发现是PCIe总线带宽不够。
3.5 知识体系总览
下面这张图，把带宽和吞吐量的关系梳理清楚了：
我的经验之谈：
做性能优化，别盯着带宽看。带宽是运营商给你的承诺，但吞吐量才是你真正能用的。
我一般先测吞吐量，再分析瓶颈。80%的情况下，问题都不在带宽上。
好了，带宽和吞吐量就讲到这里。记住一句话：带宽是理论，吞吐量是实践。两者之间的差距，就是你要优化的空间。
一句话总结：
带宽决定你能跑多快，吞吐量决定你实际跑多快。别把上限当现实，也别把现实当上限。
想要更多资料，联系可可