latency、bandwidth 和 throughput 有什么区别？

Question

IT Interview Practice · Accepted Answer

这三者描述不同的东西，却不断被混淆。**latency（延迟）**是*时延*——一个数据单元从 A 到 B 需要多久（以时间衡量，例如 ms）。**bandwidth（带宽）**是*容量*——一条链路能承载的最大数据速率（例如 Gbps）。**throughput（吞吐量）**是你在实践中*实际*达到的速率，通常低于 bandwidth。一个水管的类比能让它豁然开朗：

```text
   ├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
   ╔══════════════════════════════════════════════════════════════════════════╗
   ║  width of pipe = BANDWIDTH (max capacity)                                  ║
   ║  water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth)      ║
   ╚══════════════════════════════════════════════════════════════════════════╝
```

至关重要的是，**更宽的水管并不会让它更短**：增加 bandwidth 不会降低 latency。一条粗壮的跨大西洋链路仍有约 80 ms 的来回延迟，由距离和光速所决定——你无法花钱钻到它之下。这就是为什么主导交互式应用体感的是 latency 而非 bandwidth：每一个来回（DNS、TCP 握手、TLS，然后是请求）都要付出 latency 代价，而它们会累加。

latency 与 throughput 通过 **Bandwidth-Delay Product**（BDP = bandwidth × round-trip time）相互作用，即为把水管填满而“在途中”所需的数据量。在一条高带宽、高延迟的“long fat network”上，一个像 TCP 这样等待 ACK 的协议除非其窗口至少达到 BDP，否则无法填满水管——于是 throughput 最终*受 latency 限制*，而非 bandwidth。这就是为什么一条 TCP 流跨越长距离时往往即便在快速链路上也表现不佳，以及为什么并行、更大的窗口和 CDN（缩短距离，从而缩短 latency）都有帮助。

## 为什么这很重要

把这三者混为一谈是最常见——也最有后果——的性能错误之一：团队购买更多 bandwidth 去解决实际上是 latency 的问题，却看不到任何改善。高级洞见是 **latency 是由物理（距离）设定的下限**，你要从架构上去攻克它——把服务器/CDN 放得离用户更近、减少来回（连接复用、HTTP/3、缓存）、批量化请求——而 bandwidth 往往只需直接扩容。理解 BDP 能解释那些反直觉的结果，比如一条“快速”链路却给出缓慢的单流传输，这正是你在设计或调试高性能、地理分布式系统时被期待具备的那种推理。

为什么这很重要

相关问题