拥塞

慢启动在 TCP 发送端探索路径可承受的未确认数据量时，逐步扩大拥塞窗口。数据充足且确认模式合适时，经典行为是在多个往返间近似指数增长。“每个 RTT 翻倍”是有用的简化模式，不是无条件计时器规则。窗口变化依赖传输反馈和实现的增长条件，不能只根据连接已经打开多久，就推断它获得了多少发送预算。 慢启动需要数据及合适的 ACK 反馈。文章中的 Reno 观察展示负载依赖性，并不承诺每个 RTT 翻倍，也不能证明广域网性能。 坏掉的样子 connect 之后等待，不会自动把拥塞窗口预热。应用没有发送数据时，就没有支持这种增长的数据确认。很小的交换，也可能在用满已有发送预算之前便结束。期待每个短请求都出现大幅翻倍序列，是把受应用数据量限制的传输误认成持续积压的发送端。缺少明显增长，并不自动说明慢启动没有工作或连接存在故障。 现代系统初始窗口也不统一为一到两个段。RFC 6928 描述了允许更大初始窗口的实验性扩展，本次 Linux 发送端起步为十个段。单位同样重要：Linux TCP_INFO 的 snd_cwnd 以段为单位，许多协议说明则用字节描述拥塞窗口。推算未确认数据量之前，应同时查看发送 MSS，避免将段数直接当成字节数或当前实际在途段数。 慢启动并非总要持续到第一次丢失，之后统一彻底缩回起点。慢启动阈值帮助决定启动增长与拥塞避免，具体实现还可能采用额外启动检测；重传超时恢复也不同于快速恢复。把同一条示意曲线套到所有算法、丢失信号和工作负载，即使读到了真实指标，也可能作出错误诊断。首先需要确认当前连接处于哪个阶段。 快速验证 将脚本保存为 check-slow-start.py，准备 Docker 后运行 python3 check-slow-start.py。一次性环境使用 Python 3.11.16 和 iproute2 6.1.0，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持嵌套命名空间。客户端和目标通过新建 veth 相连，netem 在两个方向的出口各添加十毫秒延迟，全部变更仅作用于虚拟端点： ...