wonder/cs-note

Fork 0

Files

T

wonder 30d312ac35 Init

2026-05-24 11:42:38 +08:00

5.6 KiB

Raw Blame History

tags, create time

带宽、延迟、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 × 单向延迟 + 排队处理时间 + 传输时间。

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{应用处理能力})

实际吞吐量永远 ≤ 带宽。常见瓶颈：

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 要调大的原因

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 中的实践示例

// 设置 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

5.6 KiB Raw Blame History Unescape Escape