166 lines
5.6 KiB
Markdown
166 lines
5.6 KiB
Markdown
---
|
||
tags: [计算机网络, 带宽, 延迟, RTT, 吞吐量, BDP]
|
||
create time: 2026-05-17 22:40
|
||
---
|
||
|
||
# 带宽、延迟、RTT、吞吐量
|
||
|
||
## 概述
|
||
|
||
理解网络性能的核心指标，是优化应用的前提。带宽决定"管道有多粗"，延迟决定"跑一程要多久"，RTT 是往返一次的时间，而吞吐量是实际能搬多少数据。它们之间的关系经常影响系统架构设计。
|
||
|
||
## 核心定义
|
||
|
||
### 带宽（Bandwidth）
|
||
|
||
单位时间内能传输的**最大比特数**，通常用 bps（bits per second）表示：
|
||
|
||
```
|
||
1 Gbps = 10⁹ bits/s = 125 MB/s（注意：bit vs Byte）
|
||
```
|
||
|
||
| 链路类型 | 理论带宽 | 实际可用 |
|
||
|----------|---------|---------|
|
||
| 千兆以太网 (GbE) | 1 Gbps | ~940 Mbps（协议开销） |
|
||
| Wi-Fi 6 (802.11ax) | 9.6 Gbps | ~1.2–2 Gbps（理论峰值） |
|
||
| SATA III | 6 Gbps | 600 MB/s 实际 |
|
||
| PCIe 4.0 x16 | 32 Gbps | ~3.9 GB/s |
|
||
|
||
> [!tip] bit vs Byte：记住除 8
|
||
> 运营商说的 "100M 宽带" 是 **100 Mbps**。换算成下载速度约 `100 ÷ 8 ≈ 12.5 MB/s`。
|
||
|
||
### 延迟（Latency / Propagation Delay）
|
||
|
||
信号从发送端传播到接收端所需的时间，仅取决于**物理距离和介质光速**：
|
||
|
||
$$\text{Prop. Delay} = \frac{\text{Distance}}{v}$$
|
||
|
||
其中 $v$ 是传播速度。光纤中光速约为 $2 \times 10^8$ m/s（真空中光速的 2/3）。
|
||
|
||
| 场景 | 典型延迟 |
|
||
|------|---------|
|
||
| 同机房内 | 0.1–1 ms |
|
||
| 同城（同一城市数据中心） | 1–5 ms |
|
||
| 跨省（国内） | 20–40 ms |
|
||
| 跨洋（中美） | 80–150 ms |
|
||
| 卫星轨道（LEO） | 20–40 ms |
|
||
| TCP 握手 + TLS 1.3 | 1~2 RTT（额外 RTT × 加密计算时间） |
|
||
|
||
### RTT（Round-Trip Time）
|
||
|
||
从发送方发出数据包到收到确认应答的总时间。**RTT = 2 × 单向延迟 + 排队处理时间 + 传输时间**。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["t=0ms: 发送 SYN"] -->|"传播+路由器处理"| B["t=5ms: 到达服务端"]
|
||
B -->|"处理+准备响应"| C["t=5.1ms: 服务端回发 SYN-ACK"]
|
||
C -->|"传播+路由器处理"| D["t=10.2ms: 客户端收到 → RTT = 10.2ms"]
|
||
|
||
style A fill:#DDA0DD,color:#000
|
||
style D fill:#98FB98,color:#000
|
||
```
|
||
|
||
### 吞吐量（Throughput）
|
||
|
||
单位时间内**实际成功传输的数据量**，受限于最窄环节：
|
||
|
||
$$\text{Throughput} = \min(\text{带宽}, \text{拥塞窗口限制}, \text{应用处理能力})$$
|
||
|
||
实际吞吐量永远 ≤ 带宽。常见瓶颈：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["磁盘IO<br/>可能 < 网卡"] --> B["TCP收发缓冲区"]
|
||
B --> C["网络带宽"]
|
||
C --> D["对端带宽"]
|
||
D --> E["对端CPU/应用"]
|
||
|
||
F["中间路由拥塞"] -.-> C
|
||
G["丢包重传"] -.-> C
|
||
|
||
style C fill:#FFD700,color:#000
|
||
style F fill:#FF6B6B,color:#fff
|
||
style G fill:#FF6B6B,color:#fff
|
||
```
|
||
|
||
> [!question] 为什么我的千兆网卡只跑到 100MB/s？
|
||
> 因为千兆以太网理论上限是 `1Gbps ÷ 8 = 125MB/s`，去掉以太网帧头、IP 头、TCP 头等协议开销后，纯 Payload 大约 **94 MB/s**。如果还用了 HTTPS/TLS，CPU 加解密还会进一步限制吞吐量。
|
||
|
||
## 带宽时延积（BDP）
|
||
|
||
**BDP（Bandwidth-Delay Product）** 定义了链路上"在途"数据的最大量——这是维持满带宽所需的发送缓冲大小：
|
||
|
||
$$\text{BDP} = \text{Bandwidth} \times \text{RTT}$$
|
||
|
||
### 实际意义
|
||
|
||
假设带宽 1 Gbps，RTT = 100 ms：
|
||
|
||
$$\text{BDP} = 10^9 \text{ bps} \times 0.1s = 10^8 \text{ bits} = 12.5 \text{ MB}$$
|
||
|
||
这意味着：
|
||
- TCP 发送窗口至少要有 **12.5 MB**，才能填满这条管道
|
||
- 如果窗口太小，TCP 会频繁停下来等 ACK，吞吐量上不去
|
||
- 这就是 Linux 的 `net.core.rmem_max` / `wmem_max` 要调大的原因
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Pipe["管道: 1Gbps, RTT=100ms<br/>BDP = 12.5MB"]
|
||
|
||
Small["发送窗口 1MB ❌<br/>只能填 8% 管道 → 吞吐量 ≈ 80Mbps"]
|
||
Big["发送窗口 25MB ✅<br/>填满管道 → 吞吐量 ≈ 1Gbps"]
|
||
|
||
Pipe --> Small
|
||
Pipe --> Big
|
||
|
||
style Small fill:#FF6B6B,color:#fff
|
||
style Big fill:#98FB98,color:#000
|
||
```
|
||
|
||
### 各场景 BDP 速查
|
||
|
||
| 链路 | 带宽 | RTT | BDP |
|
||
|------|------|-----|-----|
|
||
| 局域网 | 1 Gbps | 0.5 ms | 62.5 KB |
|
||
| 同机房 | 10 Gbps | 1 ms | 1.25 MB |
|
||
| 同省 | 1 Gbps | 20 ms | 2.5 MB |
|
||
| 跨洋 | 100 Mbps | 150 ms | 1.875 MB |
|
||
|
||
## 延迟 vs 带宽的典型对比
|
||
|
||
| 场景 | 带宽瓶颈还是延迟瓶颈？ | 说明 |
|
||
|------|---------------------|------|
|
||
| 大文件传输 | 带宽 | 传输时间长，RTT 占比小 |
|
||
| 小请求/高频交互（RPC） | 延迟 | 每个请求 2~3 RTT，带宽几乎不占 |
|
||
| 视频流 | 带宽 | 持续大量数据传输 |
|
||
| DNS 查询 | 延迟 | 单次查询仅几十字节 |
|
||
| Web 首屏加载 | 两者兼有 | TCP+TLS握手（延迟）+ HTML/CSS/JS 下载（带宽） |
|
||
|
||
## Go 中的实践示例
|
||
|
||
```go
|
||
// 设置 TCP 连接保持活跃，定期检测死链接
|
||
tcp := net.ListenConfig{
|
||
Control: func(network, address string, c syscall.RawConn) error {
|
||
return c.Control(func() {
|
||
// 开启 keepalive，每 30s 探测一次
|
||
syscall.SetsockoptInt(int(c.Fd()), syscall.SOL_SOCKET,
|
||
syscall.SO_KEEPALIVE, 1)
|
||
})
|
||
},
|
||
}
|
||
|
||
// HTTP Transport 的连接池配置
|
||
transport := &http.Transport{
|
||
MaxIdleConns: 100, // 最多空闲连接数
|
||
MaxIdleConnsPerHost: 10, // 每个 host 最多 10 个空闲
|
||
IdleConnTimeout: 90 * time.Second, // 空闲超时释放
|
||
}
|
||
```
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/NETWORK/OSI与TCP-IP模型对比]] — 网络分层中各层的角色
|
||
- [[hhs/NETWORK/TCP状态机详解]] — TCP 的拥塞控制直接影响吞吐量
|
||
- [[hhs/NETWORK/TCP内核参数调优]] — BDP 对应内核参数 rmem/wmem
|