TCP 慢启动观察
连接刚建立时发送方并不知道链路能承受多少数据，于是从一个不大的拥塞窗口起步，每收到确认就成倍扩大发送量，这就是慢启动。抓包上表现为初期发送量快速爬升。按 RFC 6928 的建议，初始窗口约为十个最大报文段，因此小文件请求往往还没爬升完就结束了。
基本信息
| 适用平台 | TCP 协议行为，所有主流实现 |
|---|---|
| 初始窗口 | 约 10 个最大报文段（RFC 6928 的建议值） |
| 观察方式 | 时序图上看连接最初一段的发送量爬升 |
| 相关机制 | 拥塞避免、快速重传与快速恢复 |
典型使用场景
- 解释小请求为何慢：爬坡阶段本身要占掉可观的时间
- 评估长肥管道：高延迟链路上爬升时间更长
- 对比连接复用：复用连接可以跳过热身阶段
- 观察拥塞事件：丢包后窗口回落，会再次进入类似阶段
- 排查吞吐不及预期：确认测试时长是否覆盖了爬升过程
观察方式
观察方式
# 时序图：连接起始处发送量快速抬升
# 小文件请求通常受限在慢启动阶段
# 长肥管道上爬升时间不可忽视
# 相关机制：拥塞避免与快速重传阶段对照
| 阶段 | 窗口变化 | 触发条件 |
|---|---|---|
| 慢启动 | 每轮确认后成倍增长 | 连接建立或超时重传后 |
| 拥塞避免 | 每轮线性增长 | 超过慢启动阈值之后 |
| 快速重传 | 丢包后立即重发 | 收到多个重复确认 |
| 快速恢复 | 窗口减半后继续 | 与快速重传配合 |
使用连接复用（持久连接、连接池）能有效摊薄慢启动的成本。反复建连的短请求场景里，每次都要重新爬坡，累积开销相当明显。
在时序图上看到连接初期「先慢后快」是慢启动的正常特征，不要误判为网络抖动或丢包。
初始窗口的取值是实现相关的建议值，不同操作系统与内核版本可能不同。跨版本对比前先确认参数，避免把实现差异当成链路差异。