一句话：TCP 连接刚建立时，发送方并不知道路上能塞多少数据，只能从很小的拥塞窗口（cwnd，congestion window）起步、边发边试探，这叫慢启动（slow start）；之后长期盯着网络状态动态调速的整套机制，统称拥塞控制（congestion control）；BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 提出的一种算法，它不再把"丢包"直接等同于"堵了"。
打个比方：你要往一根不知多粗的水管里注水。稳妥做法是先开一点点阀门，看水出得顺就翻倍再开，直到感觉管子开始憋住。慢启动就是这套动作——它不"慢"，而是起点低、增长快：每收到一次确认，窗口就翻一倍，是指数增长。
关键在于，翻倍是按"轮"算的，一轮就是一次往返。跨洋链路的往返时延（RTT，round-trip time）动辄上百毫秒，同城常常只有几毫秒；而要把链路灌满（取决于带宽时延积，BDP），窗口得涨到很大。同样的轮数，跨洋要多花几十倍的时间。这就是为什么第一次拉一个海外文件，头几秒速度是"爬"上来的，之后才跑满——多线程分块下载之所以有效，本质就是把这段爬坡并行摊薄。
窗口涨满后进入拥塞避免，改成每轮只加一点（加性增），一旦丢包就把窗口砍半（乘性减），即 AIMD。传统算法（Reno、CUBIC 这类）把丢包当作拥塞的唯一信号，可现代路由器缓冲区很深，丢包发生时链路其实早就在疯狂排队，延迟飙升；反过来，无线链路的随机丢包也未必是真堵。
BBR 换了个思路：持续测量"这条路最快能跑多少"和"最小往返时延是多少"，据此把发送速率控制在 BDP 附近，丢包只当参考。
| 对比项 | 传统丢包驱动（Reno/CUBIC） | BBR |
|---|---|---|
| 判断依据 | 有没有丢包 | 实测带宽与最小 RTT |
| 增长方式 | 加性增、乘性减 | 按模型估算的速率发 |
| 典型表现 | 缓冲区深时延迟高、抖动大 | 跨洋长肥管道上吞吐更稳，但共享链路或高丢包场景不一定更好 |
对流媒体、跨洋下载，BBR 常能明显缩短"爬坡"时间；但它不是万能药，各家内核与云厂商的默认设置不同，具体以官方页面为准。
对从业者的现实意义：跨境拉数据集、模型权重、镜像，或跨区调用推理服务时，"首字节之后的那几秒"往往就是慢启动在收费。可用的杠杆有启用 BBR、多连接并行、走 CDN 或专线，以及最朴素的一条——把数据搬到算力旁边。对普通人来说，海外网盘第一次同步慢、后面快，多半是同一回事。