1.1 两种不同的”太快”#

TCP 发送方面临两个独立的速率约束：

• 接收方约束：接收方的处理速度有限，缓冲区有限。如果发送方发送速率超过接收方的处理能力，数据会被丢弃。这是流控要解决的问题。
• 网络约束：网络中间的路由器缓冲区有限。如果所有发送方的总速率超过链路带宽，路由器队列溢出，数据包被丢弃。这是拥塞控制要解决的问题。

两者看似相似——都是”发太快导致丢包”——但本质不同：流控是端到端的问题，只需要发送方和接收方协调；拥塞控制是全局问题，需要所有发送方共同协作，而网络中间设备不会直接告诉发送方”我拥塞了”。

1.2 1986 年的拥塞崩溃#

1986 年 10 月，互联网发生了第一次有记录的拥塞崩溃（congestion collapse）。从 Lawrence Berkeley Laboratory 到 UC Berkeley 的吞吐量从正常的 32 Kbps 暴跌到 40 bps——下降了近 1000 倍。

原因令人深思：当路由器开始丢包时，TCP 发送方会超时重传。但当时的 TCP 没有拥塞控制机制——重传的数据包与原始数据包竞争同一拥塞链路，导致更多丢包、更多重传，形成恶性循环。网络中充斥着重传数据包，有效吞吐量趋近于零。

这次事件直接催生了 Van Jacobson 在 1988 年提出的 TCP 拥塞控制算法（即 TCP Tahoe），奠定了现代拥塞控制的基础。

1.3 流控与拥塞控制的分工#

发送方实际使用的发送窗口是 rwnd 和 cwnd 中的较小值：发送窗口 = min(rwnd, cwnd)。流控说”接收方还能接收多少”，拥塞控制说”网络还能承受多少”，取两者中更保守的限制。

2.1 接收窗口的工作原理#

TCP 使用滑动窗口（sliding window）机制实现流控。接收方在每次 ACK 中携带接收窗口（rwnd）字段，告诉发送方”我还有多少缓冲区可用”。

滑动窗口的核心逻辑：

1. 发送方收到 ACK 后，窗口左沿右移（已确认的数据释放）
2. 接收方应用读取数据后，rwnd 增大，窗口右沿右移
3. 发送方发送数据后，可用窗口缩小
4. 发送方不能发送超过 min(rwnd, cwnd) 的数据

2.2 零窗口探测#

当接收方缓冲区满时，rwnd = 0，发送方必须停止发送。但接收方缓冲区释放后如何通知发送方？TCP 设计了零窗口探测（Zero Window Probe）机制：

1
# Linux 零窗口探测相关参数
2
sysctl net.ipv4.tcp_keepalive_time      # 7200s，保活探测间隔
3
sysctl net.ipv4.tcp_keepalive_intvl     # 75s，探测间隔
4
sysctl net.ipv4.tcp_keepalive_probes    # 9，探测次数
5

6
# 零窗口探测专用参数
7
sysctl net.ipv4.tcp_retries2            # 15，数据重传最大次数

发送方在收到 rwnd = 0 的 ACK 后，启动持续计时器（persist timer）。计时器超时后，发送方发送一个 1 字节的探测数据段，触发接收方重新通告窗口。如果 rwnd 仍为 0，重新启动计时器，且计时器指数退避。

2.3 糊涂窗口综合征#

糊涂窗口综合征（Silly Window Syndrome, SWS）是流控中一个经典的效率问题：当接收方缓冲区快满时，应用每次只读取少量数据，导致 rwnd 只有一小段可用空间；发送方立即发送小数据段填充这段空间，结果网络中充斥着低效的小包。

解决方案是双端的：

• 接收方：不立即通告小窗口，等到窗口达到合理大小（MSS 或缓冲区一半）再通告（Clark 方案）
• 发送方：不立即发送小数据段，等到积累足够数据再发送（Nagle 算法）

1
# Nagle 算法默认开启，可关闭（低延迟场景如游戏、SSH）
2
sysctl net.ipv4.tcp_nodelay             # 0=开启Nagle, 1=关闭
3

4
# 延迟 ACK（与 Nagle 交互可能产生额外延迟）
5
sysctl net.ipv4.tcp_delack_min          # 40ms，延迟ACK最小超时
6
sysctl net.ipv4.tcp_ato_min             # 200ms，延迟ACK自适应最小值

3.1 拥塞窗口的增长曲线#

TCP 拥塞控制的核心状态变量是拥塞窗口（cwnd），它决定了发送方在未收到 ACK 之前能向网络注入多少数据。cwnd 的增长分为两个阶段：

• 慢启动（Slow Start）：cwnd 从 1 MSS 开始，每收到一个 ACK，cwnd 增加 1 MSS。一个 RTT 内所有段被确认后，cwnd 翻倍——指数增长。名称”慢启动”是相对于”一开始就发送整个窗口”而言，并非增长速度慢。
• 拥塞避免（Congestion Avoidance）：当 cwnd 达到慢启动阈值（ssthresh）后，切换为线性增长——每个 RTT cwnd 增加 1 MSS。

3.2 ssthresh 的作用#

ssthresh 是慢启动和拥塞避免的分界线：

1
# Linux 拥塞控制相关参数
2
sysctl net.ipv4.tcp_init_cwnd          # 初始拥塞窗口（默认10）
3
sysctl net.ipv4.tcp_no_metrics_save    # 0=缓存上次cwnd, 1=不缓存
4

5
# 查看当前连接的 cwnd 和 ssthresh
6
ss -ti dst 10.0.0.1
7
# 输出示例：
8
# cubic cwnd:32 ssthresh:24 send 45.2Mbps ...

3.3 初始拥塞窗口的演进#

初始拥塞窗口（initcwnd）的值经历了重要变化：

• RFC 2581（1999）：initcwnd = 1 MSS
• RFC 3390（2002）：initcwnd = min(4 MSS, 4380 字节)
• RFC 6928（2013）：initcwnd = 10 MSS

从 1 MSS 到 10 MSS 的提升，反映了对现代网络的认知：当今互联网的带宽延迟积远大于早期，1 MSS 的初始窗口导致短连接在慢启动阶段就结束了，永远无法充分利用带宽。

4.1 三个重复 ACK 的含义#

超时重传的代价很大——RTO 通常在数百毫秒到秒级，期间连接完全空闲。TCP 设计了快速重传（Fast Retransmit）机制，用重复 ACK 来检测丢包，避免等待超时。

当接收方收到乱序数据段时，会立即发送对最后一个按序字节的 ACK。如果段 3 丢失，段 4、5、6 到达时接收方都会发送对段 2 的 ACK——产生三个重复 ACK。发送方收到三个重复 ACK 后，立即重传丢失的段，无需等待超时。

4.2 快速恢复算法#

快速重传之后，发送方进入快速恢复（Fast Recovery）阶段，而非回到慢启动：

1. 设置 ssthresh = cwnd / 2
2. 设置 cwnd = ssthresh + 3 MSS（3 MSS 对应 3 个重复 ACK 已离开网络）
3. 每收到一个重复 ACK，cwnd 增加 1 MSS（允许发送新数据）
4. 收到新数据的 ACK 时，cwnd = ssthresh，进入拥塞避免

快速恢复的核心思想：三个重复 ACK 说明网络仍在传递数据（只是丢了一个包），所以不需要像超时那样激进地降低发送速率。

4.3 Reno 与 NewReno 的区别#

NewReno 的改进看似微小，但在高延迟、高丢包率网络中效果显著。考虑一个窗口内丢失两个数据段的情况：Reno 只能恢复第一个，第二个必须等超时重传；NewReno 可以在一次快速恢复中依次恢复两个丢包，避免数百毫秒的等待。

1
# Linux 默认使用 NewReno 的改进版（内置于各拥塞控制算法）
2
sysctl net.ipv4.tcp_recovery           # 快速恢复模式
3

4
# 查看当前拥塞控制算法
5
sysctl net.ipv4.tcp_congestion_control
6
# 输出：tcp_congestion_control = cubic

5.1 Cubic：丢包驱动的巅峰#

Cubic 是 Linux 内核 2.6.19 以来的默认拥塞控制算法，也是目前互联网上部署最广泛的算法。它的核心改进是让 cwnd 的增长与 RTT 无关——之前的算法（如 Reno、BIC）在长 RTT 链路上增长过慢。

Cubic 的窗口增长函数：

$W(t) = C \times (t - K)^3 + W_{max}$

其中：

• $C = 0.4$（默认 Cubic 参数）
• $W_{max}$ 是上次丢包时的 cwnd
• $K = \sqrt[3]{W_{max} / C}$ 是窗口增长到 $W_{max}$ 所需的时间
• $t$ 是距上次丢包的时间

Cubic 的增长曲线呈三次函数形状：丢包后先快速增长（凹函数阶段），接近 $W_{max}$ 时减速（凸函数阶段），超过 $W_{max}$ 后缓慢探索（凹函数阶段），直到再次丢包。

1
# Cubic 参数调整
2
sysctl net.ipv4.tcp_cubic_beta           # 0.7，乘法减少因子
3
sysctl net.ipv4.tcp_cubic_fast_converge  # 1，快速收敛开关
4

5
# 切换到 Cubic 算法
6
sysctl -w net.ipv4.tcp_congestion_control=cubic

5.2 BBR：模型驱动的革命#

BBR（Bottleneck Bandwidth and Round-trip propagation time）由 Google 的 Neal Cardwell 等人在 2016 年提出，彻底改变了拥塞控制的范式：不再以丢包作为拥塞信号，而是通过显式建模网络的瓶颈带宽和最小 RTT 来控制发送速率。

BBR 的两个核心参数：

• BtlBw（Bottleneck Bandwidth）：路径瓶颈带宽，通过测量交付速率的最大值估计
• RTprop（Round-trip propagation time）：路径最小 RTT，通过测量 RTT 的最小值估计

BBR 的发送速率由这两个参数决定：发送速率 = BtlBw，在途数据量 = BtlBw × RTprop（即带宽延迟积 BDP）。

BBR 的四个状态：

1. Startup：类似慢启动，以 2x 速率增长，直到交付速率不再增长（发现 BtlBw）
2. Drain：排空 Startup 阶段积累的队列，将发送速率降至 BtlBw
3. ProbeBW：稳态阶段，以 BtlBw 发送，周期性地以 1.25x 速率探测更高带宽
4. ProbeRTT：定期降低发送速率（4 个 MSS），探测更小的 RTprop

5.3 Cubic 与 BBR 的对比#

1
# 启用 BBR（需要内核 4.9+）
2
echo "bbr" | sudo tee /etc/sysctl.d/99-bbr.conf
3
sysctl -p /etc/sysctl.d/99-bbr.conf
4

5
# 验证 BBR 已启用
6
sysctl net.ipv4.tcp_congestion_control
7
sysctl net.ipv4.tcp_available_congestion_control
8
# 输出应包含 bbr
9

10
# 查看当前连接使用的拥塞控制算法
11
ss -ti | grep -E "cubic|bbr"

6.1 慢启动对短流的影响#

互联网上大多数 TCP 连接是短流——一个网页请求可能只有几十 KB 数据。慢启动的指数增长意味着短流往往在慢启动阶段就结束了，永远无法达到可用带宽。

假设路径带宽 100 Mbps、RTT 50ms、MSS 1460 字节：

• 带宽延迟积 BDP = 100 Mbps × 50ms = 625 KB ≈ 428 MSS
• 从 initcwnd = 10 MSS 开始，需要约 6 个 RTT 才能超过 BDP
• 6 个 RTT = 300ms，在此期间传输的数据量约 10+20+40+80+160+320 = 630 MSS ≈ 920 KB

对于 100 KB 以下的短流，慢启动阶段就结束了，带宽利用率极低。这正是 QUIC与HTTP/3 引入 0-RTT 技术的动机之一——复用之前连接的拥塞信息，跳过慢启动。

6.2 TCP 公平性#

TCP 拥塞控制的一个隐含目标是公平性——所有 TCP 连接应公平共享瓶颈链路。Cubic 的 AIMD（加法增乘法减）策略天然趋向公平：增窗时线性增长，减窗时减半，多条连接最终收敛到公平分配。

但公平性并非总是成立：

• 不同 RTT 的连接：RTT 短的连接 ACK 回得快，cwnd 增长更快，占据更多带宽
• TCP vs UDP：UDP 不做拥塞控制，可能抢占 TCP 带宽
• BBR vs Cubic：BBR 不以丢包减窗，在有缓冲区的链路上可能比 Cubic 多占 2-3 倍带宽
• 多路径：MPTCP 子流共享瓶颈时需要特殊处理

6.3 缓冲区膨胀#

缓冲区膨胀（Bufferbloat）是现代网络中一个被忽视的问题：路由器和交换机的缓冲区越来越大，数据包在队列中等待时间过长，导致 RTT 飙升。

Cubic 的”填满缓冲区”策略加剧了 Bufferbloat：cwnd 持续增长直到丢包，而大缓冲区意味着丢包发生时队列已经很长，RTT 可能从 50ms 膨胀到 500ms 甚至更高。交互式应用（SSH、游戏、视频会议）的延迟因此急剧恶化。

BBR 的设计天然对抗 Bufferbloat：它不依赖丢包信号，而是通过 RTprop 估计最小 RTT，尽量不产生队列。但 BBR v1 在与 Cubic 共存时可能过度占带宽，BBR v2/v3 做了改进。

6.4 显式拥塞通知#

ECN（Explicit Congestion Notification，RFC 3168）让路由器在队列快满时标记数据包（而非丢弃），发送方看到标记后降低发送速率，避免丢包和重传。

1
# 启用 ECN
2
sysctl net.ipv4.tcp_ecn                # 0=禁用, 1=启用, 2=仅入向
3

4
# 查看当前 ECN 状态
5
sysctl net.ipv4.tcp_ecn
6

7
# Wireshark 过滤 ECN 标记的包
8
# tcp.flags.ecn == 1 或 ip.tos.ecn == 0x01

ECN 使用 IP 头部的 TOS 字段中的 2 位：00 = 不支持 ECN，01/10 = 支持 ECN，11 = 拥塞经历（CE）。TCP 头部也有 ECE 和 CWR 标志用于协商和通告。

7.1 用 iperf3 测试带宽#

1
# 服务端
2
iperf3 -s -p 5201
3

4
# 客户端：基本带宽测试
5
iperf3 -c server_ip -p 5201 -t 30
6

7
# 客户端：指定拥塞控制算法
8
iperf3 -c server_ip -p 5201 -t 30 -C bbr
9

10
# 客户端：输出 JSON 格式（便于脚本分析）
11
iperf3 -c server_ip -p 5201 -t 30 -J > result.json

7.2 用 ss 观察拥塞窗口#

1
# 查看所有 TCP 连接的拥塞控制信息
2
ss -ti
3

4
# 过滤特定连接
5
ss -ti dst 10.0.0.1
6

7
# 输出字段解读：
8
# cwnd     = 拥塞窗口
9
# ssthresh = 慢启动阈值
10
# rtt      = 往返时延
11
# rttvar   = RTT 方差
12
# bbr      = BBR 参数（bw, mrtt）
13
# send     = 发送速率估计
14

15
# 持续监控（每秒刷新）
16
watch -n 1 'ss -ti dst 10.0.0.1'

7.3 用 tcp_probe 追踪 cwnd 变化#

1
# 加载 tcp_probe 内核模块
2
sudo modprobe tcp_probe
3
sudo chmod 444 /proc/net/tcpprobe
4

5
# 监控特定端口的 cwnd 变化
6
sudo cat /proc/net/tcpprobe > /tmp/cwnd_trace.log &
7
CAT_PID=$!
8

9
# 运行 iperf3 测试
10
iperf3 -c server_ip -p 5201 -t 10
11

12
# 停止监控
13
kill $CAT_PID
14

15
# 分析 cwnd 变化
16
# 日志格式：timestamp src dst sport dport cwnd ssthresh
17
awk '{print $1, $6, $7}' /tmp/cwnd_trace.log | head -20

7.4 Wireshark TCP 流图#

Wireshark 提供了强大的 TCP 流可视化功能：

1
# 抓取 TCP 流量
2
sudo tcpdump -i eth0 tcp port 5201 -w tcp_congestion.pcap
3

4
# 在 Wireshark 中打开后：
5
# 1. Statistics → TCP Stream Graphs → Round Trip Time Graph
6
# 2. Statistics → TCP Stream Graphs → Throughput Graph
7
# 3. Statistics → TCP Stream Graphs → Window Scaling Graph
8
# 4. Statistics → TCP Stream Graphs → Time-Sequence (Stevens)
9

10
# Wireshark 显示过滤器
11
tcp.analysis.retransmission          # 重传数据段
12
tcp.analysis.duplicate_ack           # 重复 ACK
13
tcp.analysis.fast_retransmission     # 快速重传
14
tcp.window_size == 0                 # 零窗口
15
tcp.flags.ecn == 1                   # ECN 标记

7.5 Python 模拟拥塞窗口变化#

1
"""模拟 TCP Reno 拥塞窗口变化"""
2
import matplotlib.pyplot as plt
3

4
def simulate_tcp_reno(max_rtt=50, loss_rtt=20, mss=1460):
5
    """模拟 TCP Reno 的 cwnd 变化"""
6
    cwnd = 1  # 初始 cwnd（MSS）
7
    ssthresh = float('inf')
8
    cwnd_trace = []
9

10
    for rtt in range(max_rtt):
11
        cwnd_trace.append(cwnd)
12

13
        if cwnd < ssthresh:
14
            # 慢启动：指数增长
15
            cwnd *= 2
16
        else:
17
            # 拥塞避免：线性增长
18
            cwnd += 1
19

20
        # 模拟丢包事件
21
        if rtt == loss_rtt:
22
            ssthresh = max(cwnd // 2, 2)
23
            cwnd = 1  # 超时丢包，回到慢启动
24

25
    return cwnd_trace
26

27
def simulate_tcp_newreno(max_rtt=50, loss_rtt=20):
28
    """模拟 TCP NewReno 的 cwnd 变化"""
29
    cwnd = 1
30
    ssthresh = float('inf')
31
    cwnd_trace = []
32
    fast_recovery = False
33

34
    for rtt in range(max_rtt):
35
        cwnd_trace.append(cwnd)
36

37
        if fast_recovery:
38
            # 快速恢复中
39
            cwnd += 1  # 收到重复 ACK
40
            if cwnd >= ssthresh + 3:
41
                fast_recovery = False
42
                cwnd = ssthresh
43
        elif cwnd < ssthresh:
44
            cwnd *= 2
45
        else:
46
            cwnd += 1
47

48
        if rtt == loss_rtt:
49
            ssthresh = max(cwnd // 2, 2)
50
            cwnd = ssthresh + 3  # 快速恢复
51
            fast_recovery = True
52

53
    return cwnd_trace
54

55
# 运行模拟
56
reno = simulate_tcp_reno()
57
newreno = simulate_tcp_newreno()
58

59
# 绘图
60
fig, ax = plt.subplots(figsize=(10, 5))
61
ax.plot(reno, label='TCP Reno', marker='o', markersize=3)
62
ax.plot(newreno, label='TCP NewReno', marker='s', markersize=3)
63
ax.set_xlabel('RTT 轮次')
64
ax.set_ylabel('cwnd (MSS)')
65
ax.set_title('TCP Reno vs NewReno 拥塞窗口变化')
66
ax.legend()
67
ax.grid(True, alpha=0.3)
68
plt.tight_layout()
69
plt.savefig('tcp_cwnd_simulation.png', dpi=150)
70
print("模拟完成，图表已保存")

8.1 拥塞控制算法演进总览#

8.2 拥塞事件与响应#

8.3 Linux 拥塞控制 sysctl 参数#

从滑动窗口的端到端流控，到基于丢包的 Reno/Cubic，再到模型驱动的 BBR，TCP 拥塞控制走过了一条从”被动反应”到”主动建模”的演进之路。但 TCP 的拥塞控制始终受限于一个架构约束：拥塞控制状态与传输层绑定，连接切换路径时状态全部丢失。

这正是 QUIC 要解决的核心问题之一。在 QUIC与HTTP/3 中，将看到 QUIC 如何通过连接 ID 实现连接迁移、如何将拥塞控制从内核搬到用户空间实现快速迭代、以及 HTTP/3 如何在 QUIC 之上消除 HTTP/2 的队头阻塞——TCP 拥塞控制的经验与教训，全部沉淀在了 QUIC 的设计之中。