症状：clone 800MB 仓库跑了 8 小时

团队成员 Z 上周反馈：凌晨拉一个 800MB 的私有仓库，clone 速度稳定在 30KB/s，跑了快 8 小时还没完。第二天早上才发现是跨境链路丢包导致 TCP 反复重传。

30KB/s 这个数字其实挺荒唐的：

• 他买的是上海电信 1000M 宽带，下行理论上限 125MB/s
• GitHub 服务器在美西 AWS us-west-2，带宽充足
• 链路 RTT 只有 168ms（不算高）
• 丢包率只有 4-6%（也不算很高）

带宽没用满，RTT 不高，丢包"不严重"——为什么速度会低到 30KB/s？

根因：TCP 拥塞控制在丢包场景的"雪崩"

罪魁祸首是 TCP 的拥塞控制算法——尤其是 Cubic（Linux 默认）和 Reno（老版本 Windows）。

这两个算法的核心逻辑是："丢包 = 网络拥塞 = 应该降速"。它们的设计假设是：丢包几乎一定是因为路由器缓冲溢出。

这个假设在 2000 年之前是对的——那时候网络设备缓冲很小。但今天：

• 跨境海缆 RTT 高（150-300ms）
• 海缆缓冲区很大（数百 MB）
• 随机丢包（无线干扰、海缆质量）经常发生

结果就是：跨境链路上丢包几乎都不是拥塞引起的，但 TCP 看到丢包就疯狂降速——窗口减半、再减半、再减半……

一个真实案例：

1. TCP 窗口已经爬到 64 个 MSS（约 96KB）
2. 链路丢了 1 个包（0.1% 概率）
3. Cubic 检测到 dup ACK，把窗口减半 → 32 MSS
4. 下一个 RTT 又丢 1 个包 → 16 MSS
5. 再下一个 RTT 再丢 → 8 MSS
6. 速度从 8MB/s 一路降到 1MB/s，最后稳定在 30KB/s

解法一：BBR 拥塞控制算法

BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 在 2016 年开源的新一代拥塞控制算法。它的核心思路完全不同：

• 不依赖丢包判断拥塞
• 通过测量带宽和 RTT 反推"瓶颈点"
• 主动估算最优发送速率

BBR 在跨境场景下表现惊人：

1. 不会因为随机丢包就降速
2. 通过"探测带宽"周期性找出实际可用带宽
3. 避免在深缓冲区中"排队"，减少延迟

快连如何使用 BBR

Linux 内核 4.9+ 已内置 BBR v1，6.6+ 内置 BBR v3。快连客户端在连接建立时自动开启 BBR（如果操作系统支持），并在我们的边缘节点也启用 BBR v3。

# Linux 启用 BBR v3
sudo sysctl net.ipv4.tcp_congestion_control=bbr
sudo sysctl net.core.default_qdisc=fq
# 验证
sysctl net.ipv4.tcp_congestion_control
# 应输出: net.ipv4.tcp_congestion_control = bbr

解法二：应用层 FEC 修补

但 BBR 也无法解决应用层协议本身的设计问题。Git 的 smart HTTP 协议一次传输一个 pack 文件，如果这个文件中有 1% 的包丢失，整个文件就必须重传——而不是只重传丢失的那 1%。

我们的解法是在快连的边缘节点做应用层 FEC：

1. 把 Git 的 pack 文件切成 64KB 的小块
2. 每个小块加 8KB 的 Reed-Solomon 校验块
3. 接收端只要小块收到 64KB 中任意 56KB 就能还原
4. 丢包时不需要重传整文件

代价是总流量增加 12.5%（从 800MB → 900MB），但换来的 clone 速度提升是几十倍，完全划算。

实测对比：四种方案的 clone 速度

2026 年 8 月 30 日，我们对一个 800MB 的私有仓库做了四种方案对比。

方案	平均速度	峰值速度	总耗时	评分
裸连 + Linux 默认 Cubic	32 KB/s	180 KB/s	8 小时 12 分	不可用
裸连 + 手动开 BBR	1.2 MB/s	3.8 MB/s	11 分 18 秒	可接受
通用加速工具 + TCP 优化	2.4 MB/s	5.6 MB/s	5 分 36 秒	良好
快连（BBR v3 + 应用层 FEC）	8.1 MB/s	12.4 MB/s	1 分 39 秒	优秀

同样是 clone 同一个仓库，裸连需要 8 小时，快连 1 分 39 秒。250 倍的差距不是带宽换来的——是协议优化换来的。

症状：clone 800MB 仓库跑了 8 小时

团队成员 Z 上周反馈：凌晨拉一个 800MB 的私有仓库，clone 速度稳定在 30KB/s，跑了快 8 小时还没完。第二天早上才发现是跨境链路丢包导致 TCP 反复重传。

30KB/s 这个数字其实挺荒唐的：

• 他买的是上海电信 1000M 宽带，下行理论上限 125MB/s
• GitHub 服务器在美西 AWS us-west-2，带宽充足
• 链路 RTT 只有 168ms（不算高）
• 丢包率只有 4-6%（也不算很高）

带宽没用满，RTT 不高，丢包"不严重"——为什么速度会低到 30KB/s？

根因：TCP 拥塞控制在丢包场景的"雪崩"

罪魁祸首是 TCP 的拥塞控制算法——尤其是 Cubic（Linux 默认）和 Reno（老版本 Windows）。

这两个算法的核心逻辑是："丢包 = 网络拥塞 = 应该降速"。它们的设计假设是：丢包几乎一定是因为路由器缓冲溢出。

这个假设在 2000 年之前是对的——那时候网络设备缓冲很小。但今天：

• 跨境海缆 RTT 高（150-300ms）
• 海缆缓冲区很大（数百 MB）
• 随机丢包（无线干扰、海缆质量）经常发生

结果就是：跨境链路上丢包几乎都不是拥塞引起的，但 TCP 看到丢包就疯狂降速——窗口减半、再减半、再减半……

一个真实案例：

1. TCP 窗口已经爬到 64 个 MSS（约 96KB）
2. 链路丢了 1 个包（0.1% 概率）
3. Cubic 检测到 dup ACK，把窗口减半 → 32 MSS
4. 下一个 RTT 又丢 1 个包 → 16 MSS
5. 再下一个 RTT 再丢 → 8 MSS
6. 速度从 8MB/s 一路降到 1MB/s，最后稳定在 30KB/s

解法一：BBR 拥塞控制算法

BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 在 2016 年开源的新一代拥塞控制算法。它的核心思路完全不同：

• 不依赖丢包判断拥塞
• 通过测量带宽和 RTT 反推"瓶颈点"
• 主动估算最优发送速率

BBR 在跨境场景下表现惊人：

1. 不会因为随机丢包就降速
2. 通过"探测带宽"周期性找出实际可用带宽
3. 避免在深缓冲区中"排队"，减少延迟

快连如何使用 BBR

Linux 内核 4.9+ 已内置 BBR v1，6.6+ 内置 BBR v3。快连客户端在连接建立时自动开启 BBR（如果操作系统支持），并在我们的边缘节点也启用 BBR v3。

# Linux 启用 BBR v3
sudo sysctl net.ipv4.tcp_congestion_control=bbr
sudo sysctl net.core.default_qdisc=fq
# 验证
sysctl net.ipv4.tcp_congestion_control
# 应输出: net.ipv4.tcp_congestion_control = bbr

解法二：应用层 FEC 修补

但 BBR 也无法解决应用层协议本身的设计问题。Git 的 smart HTTP 协议一次传输一个 pack 文件，如果这个文件中有 1% 的包丢失，整个文件就必须重传——而不是只重传丢失的那 1%。

我们的解法是在快连的边缘节点做应用层 FEC：

1. 把 Git 的 pack 文件切成 64KB 的小块
2. 每个小块加 8KB 的 Reed-Solomon 校验块
3. 接收端只要小块收到 64KB 中任意 56KB 就能还原
4. 丢包时不需要重传整文件

代价是总流量增加 12.5%（从 800MB → 900MB），但换来的 clone 速度提升是几十倍，完全划算。

实测对比：四种方案的 clone 速度

2026 年 8 月 30 日，我们对一个 800MB 的私有仓库做了四种方案对比。

方案	平均速度	峰值速度	总耗时	评分
裸连 + Linux 默认 Cubic	32 KB/s	180 KB/s	8 小时 12 分	不可用
裸连 + 手动开 BBR	1.2 MB/s	3.8 MB/s	11 分 18 秒	可接受
通用加速工具 + TCP 优化	2.4 MB/s	5.6 MB/s	5 分 36 秒	良好
快连（BBR v3 + 应用层 FEC）	8.1 MB/s	12.4 MB/s	1 分 39 秒	优秀

同样是 clone 同一个仓库，裸连需要 8 小时，快连 1 分 39 秒。250 倍的差距不是带宽换来的——是协议优化换来的。