k2cc 自适应速率控制

k2cc 是开途（Kaitu）自主研发的拥塞控制算法，其设计理念、技术架构和实现均为开途原创知识产权。

k2cc（Adaptive Rate Control）专为高审查、高丢包网络环境设计，能自动探测最优发送速率——无需用户手动配置带宽参数。k2cc 是一个独立的拥塞控制算法，当前被 k2v5（客户端-服务端架构）使用，未来也将作为 k2v6（P2P 架构）的拥塞控制层。

如果您只需要快速使用 k2，请参阅 1 分钟快速开始。

为什么需要 k2cc

在 GFW 等高审查网络环境中，传统拥塞控制算法面临根本性挑战：

算法	丢包响应	在审查网络中的表现
Cubic/Reno	大幅降速（乘法减少）	将审查丢包误判为拥塞，5% 丢包率下吞吐量下降 75%+
BBR	基于带宽估计	持续丢包干扰带宽探测模型，严重低估可用带宽
Brutal	完全忽略	不区分丢包类型，固定速率发送，高丢包下触发重传风暴
k2cc	自适应区分	自动识别非拥塞性丢包，维持接近链路容量的有效吞吐

GFW 对被检测到的代理连接实施约 26% 的概率性丢包（USENIX Security 2023 实测数据）。这个丢包率对传统算法是致命的——Cubic 在此条件下吞吐量不足理论值的 10%。k2cc 能在 26% 甚至 50% 丢包率下维持有效传输。

核心能力

审查感知丢包处理

k2cc 能区分网络拥塞导致的丢包和审查基础设施主动丢弃的数据包。在高审查网络中，防火墙主动丢弃数据包并非真正的网络拥塞——降速不会减少丢包率，只会降低有效吞吐量。k2cc 识别这一特征，在审查丢包环境中维持接近链路容量的发送速率。

自动速率探测

无需用户配置带宽参数。k2cc 持续探测最优发送速率，实时跟踪网络条件变化。在移动网络或晚高峰等带宽频繁波动的场景下，k2cc 自动适应实际可用带宽。

延迟敏感控制

k2cc 实时监测 RTT（往返延迟），当路由器缓冲区开始积压（bufferbloat）时主动调整发送速率，抑制延迟恶化。同时通过发包节奏控制（pacing）均匀分布数据包，避免突发流量造成队列堆积。

速率恢复机制

在因网络波动降速后，k2cc 会周期性主动探测更高速率。一旦网络条件改善（如审查放松、晚高峰结束），算法能快速恢复到全速，而非锁定在之前的降速水平。

流量共存公平性

k2cc 自适应调整发送速率，与其他 TCP/QUIC 流量和平共存。多个 k2 连接在同一链路上时能相对均衡地分配带宽，不会挤占其他应用的网络资源。

---

性能验证

k2 内置 14 种网络场景基准测试套件（详见 k2 vs Hysteria2），涵盖从理想网络到 GFW 极端审查（50% 丢包率）的完整频谱。测试场景基于学术研究设计，参考 RFC 8867、QUICbench (IMC 2022)、USENIX Security 2023/2025 的方法论。

在 T7 场景（26% 概率性丢包，USENIX Security 2023 实测值）下，传统算法 Cubic 吞吐量不足理论值 10%，BBR 严重低估可用带宽，而 k2cc 仍能维持有效传输。

详细的量化基准测试报告正在准备中，将在后续版本中公开发布。

---

常见问题

k2cc 需要手动配置吗？

不需要。k2cc 完全自动运行，无需指定带宽参数。安装后开箱即用。

k2cc 如何与 QUIC 配合？

k2cc 直接控制 QUIC 的发送速率，替代了 QUIC 默认的拥塞控制算法。

k2cc 的性能如何验证？

k2 项目内置了 14 种网络场景的基准测试套件，涵盖从理想网络到极端审查的完整频谱。详细的测评框架见 k2 vs Hysteria2 拥塞控制对比。

k2cc 是开源的吗？

k2cc 的设计理念和能力描述已在本文档中公开。算法实现属于开途（Kaitu）的核心知识产权，目前不开源。k2 项目的测评框架（14 种网络场景）已开源，任何人都可以用相同的测试条件验证不同算法的实际表现。

---

接下来阅读：k2v5 协议架构 了解 k2v5 的客户端-服务端协议设计，隐身伪装技术 了解流量隐身机制，k2 vs Hysteria2 查看 k2cc 与 Brutal/BBR 的性能对比。