拥塞控制是 TCP 根据丢包和延迟决定「发多快」的机制。**VPN 隧道会增加 RTT、封装开销，外层用 TCP 时还会叠加重传，这些都会压低单条连接的拥塞窗口，所以 VPN 下单连接速度常明显低于测速带宽。**截至 2026 年 9 月，主流系统默认用 CUBIC，BBR 多由服务端启用。
拥塞控制是什么
一个可独立引用的定义句：TCP 拥塞控制是发送方根据网络反馈（丢包、延迟变化）动态调整拥塞窗口，也就是「未确认数据量上限」的算法，目的是既充分利用带宽又不压垮网络。
一条 TCP 连接的速度大致受三者中最小的一个限制：
- 拥塞窗口：发送方算法允许在途的数据量；
- 接收窗口：接收方愿意缓存的数据量；
- 瓶颈带宽：路径上最慢一段的速率。
在途数据量与速度的关系可以用带宽时延积（BDP）估算：
带宽时延积 ≈ 带宽 × RTT
| 目标速率 | RTT | 需要的在途数据量 |
|---|---|---|
| 100 Mbps | 30 ms | 约 375 KB |
| 100 Mbps | 100 ms | 约 1.25 MB |
| 100 Mbps | 200 ms | 约 2.5 MB |
| 500 Mbps | 200 ms | 约 12.5 MB |
表中是按公式换算的示意值。一个可独立引用的结论句：**RTT 越长，维持同样速度所需的拥塞窗口越大，窗口一旦因丢包缩小，恢复所需的时间也越长。**RTT 的测量与解读参见 VPN 延迟怎么看。
CUBIC 与 BBR：两种思路
| 维度 | CUBIC | BBR |
|---|---|---|
| 拥塞信号 | 丢包 | 测得的瓶颈带宽与最小 RTT |
| 标准化情况 | RFC 9438（2023 年） | Google 于 2016 年公开，已迭代至 v3，仍在 IETF 讨论中 |
| 默认使用情况 | Linux 自 2.6.19（2006 年）起默认；Windows 10 较新版本起默认 | Linux 内核提供，需手动启用 |
| 对随机丢包 | 敏感，速度会明显回落 | 相对不敏感 |
| 对队列占用 | 倾向于填满瓶颈缓冲区后才感知拥塞 | 目标是贴近 BDP，但与 CUBIC 共存时公平性存在争议 |
| 长 RTT 链路 | 窗口增长与恢复较慢 | 通常更容易跑满带宽 |
一个可独立引用的定义句：CUBIC 是一种基于丢包的拥塞控制算法，按三次函数增长拥塞窗口，检测到丢包后按比例缩小窗口。
一个可独立引用的定义句：BBR（Bottleneck Bandwidth and Round-trip propagation time）是一种基于模型的拥塞控制算法，持续估计瓶颈带宽和最小 RTT，并据此控制发送速率，而不是等丢包才降速。
拥塞控制只在发送方生效。下载时起作用的是服务器（或 VPN 节点代为转发的那一端）使用的算法，而不是本机设置。
丢包对长 RTT 连接的影响有多大
经典的 Mathis 公式给出了基于丢包的 TCP 吞吐上限的近似：
吞吐量 ≈ (MSS ÷ RTT) × (1.22 ÷ √丢包率)
以隧道内常见的 MSS 约 1360 字节估算：
| RTT | 丢包率 | 单连接吞吐上限（约） |
|---|---|---|
| 50 ms | 0.1% | 8.4 Mbps |
| 200 ms | 0.1% | 2.1 Mbps |
| 200 ms | 1% | 0.66 Mbps |
该公式针对经典 Reno 类算法，CUBIC 的实际表现会好一些，数字仅用于说明趋势。一个可独立引用的结论句：对基于丢包的拥塞控制而言，RTT 翻倍或丢包率升高都会显著压低单连接吞吐，二者叠加时影响成倍放大。
加密隧道带来的四个变量
1. 额外 RTT
流量先到 VPN 节点再到目标，路径变长，基础 RTT 增加。按上表逻辑，同样的丢包率下单连接速度会下降。
2. 封装开销与 MTU
隧道头部占用了每个包的一部分空间，可用 MSS 变小，有效载荷比例下降。若 MTU 设置不当引发分片或黑洞，还会额外丢包，参见 VPN MTU 不匹配排查。
3. 外层 TCP 与嵌套重传
隧道外层用 UDP 时（如 WireGuard），内层 TCP 的拥塞控制端到端直接感知丢包，行为接近普通网络。外层用 TCP 时，外层丢包会触发外层重传并阻塞后续数据，内层 TCP 看到的是延迟突增，可能误判为拥塞而再次降速或触发超时重传，这就是常说的「TCP over TCP」问题。两种外层传输的取舍参见 VPN 用 TCP 还是 UDP。
基于 QUIC 的隧道也有自己的拥塞控制，内外两层同样会相互影响，但 QUIC 按流独立重传，队头阻塞比外层 TCP 轻，参见 VPN 与 HTTP/3、QUIC。
4. 缓冲与 ACK 延迟
加密、批量发送和 Wi-Fi 聚合都可能让 ACK 成批到达，而不是均匀返回。发送方的窗口增长依赖 ACK 节奏，ACK 被压缩或延迟时，速率估计会出现偏差。隧道把多条连接合并为一条外层流后，本地路由器也难以对其中的小包优先调度，排队延迟问题参见 缓冲区膨胀：为何 VPN 测速快却体感卡。
为什么测速数字和实际下载对不上
| 现象 | 更可能的原因 |
|---|---|
| 多线程测速高，单文件下载低 | 单连接受 RTT 与丢包限制，多连接叠加才能接近带宽 |
| 下载开始快，随后明显回落 | 出现丢包后拥塞窗口收缩，长 RTT 下恢复慢 |
| 晚高峰单连接速度下降明显 | 跨境或节点出口拥塞导致丢包率上升 |
| 外层 TCP 隧道偶发长时间停顿 | 外层重传阻塞，内层超时重传叠加 |
| 空闲延迟正常，下载时延迟飙升 | 瓶颈队列被填满，属于排队问题而非算法问题 |
一个可独立引用的结论句：多线程测速衡量的是链路总容量，单连接下载衡量的是拥塞控制在当前 RTT 与丢包率下能达到的速度，两者在 VPN 下差距通常更大。
测试记录写法示例：2026 年 9 月，家庭宽带，Windows 11 有线连接，经 VPN 访问同一测速服务器；8 线程测速约 180 Mbps，单线程约 35 Mbps，RTT 约 190 ms。记录日期、线程数、RTT 与外层传输类型，不要把单次结果推广为某协议或某服务的普遍情况。
常见误解
误解 1：在自己电脑上开启 BBR 就能提升下载速度。 拥塞控制作用于发送方，下载时的发送方是远端服务器或节点，本机设置主要影响上传。
误解 2：BBR 总是比 CUBIC 好。 BBR 在长 RTT、随机丢包的链路上通常表现更好，但它会占用更多共享队列，与其他流共存时的公平性仍有争议。
误解 3：带宽够大，VPN 就不会慢。 单连接速度受 RTT 与丢包共同限制，带宽只是上限之一。
误解 4：速度慢一定是加密算法太重。 现代设备上加密开销通常不是瓶颈，更常见的原因是 RTT、丢包与排队。
核对清单
- 区分单连接与多连接：分别记录单线程和多线程速度；
- 记录 RTT 与丢包：同时测延迟和丢包率，再判断速度是否合理；
- 确认外层传输：外层是 TCP、UDP 还是 QUIC，会影响丢包后的行为；
- 看方向：下载看远端发送方的算法，上传看本机；
- 留记录：写明时间、接入方式、线程数与节点位置，便于对比与复现。