k2cc 自适应速率控制
k2cc 是 k2 自研的拥塞控制算法，专为高审查、高丢包网络设计。自动探测最优发送速率，区分审查丢包与拥塞丢包，无需手动配置带宽参数。
k2cc 自适应速率控制
k2cc（Adaptive Rate Control）是 k2 自研的拥塞控制算法，专为高审查、高丢包网络环境设计。它能自动探测最优发送速率——无需用户手动配置带宽参数。
如果您只需要快速使用 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 自动适应实际可用带宽。
延迟敏感控制
k2cc 实时监测 RTT（往返延迟），当路由器缓冲区开始积压（bufferbloat）时主动调整发送速率，抑制延迟恶化。同时通过发包节奏控制（pacing）均匀分布数据包，避免突发流量造成队列堆积。
速率恢复机制
在因网络波动降速后，k2cc 会周期性主动探测更高速率。一旦网络条件改善（如审查放松、晚高峰结束），算法能快速恢复到全速，而非锁定在之前的降速水平。
流量共存公平性
k2cc 自适应调整发送速率，与其他 TCP/QUIC 流量和平共存。多个 k2 连接在同一链路上时能相对均衡地分配带宽，不会挤占其他应用的网络资源。
协议技术要素
以下是 k2v5 协议的其他技术要素。关于隐身伪装机制的详细分析，请参阅 隐身伪装技术。
k2v5 URL 格式
k2v5 将所有连接参数编码到单个 URL 中：
k2v5://USERNAME:PASSWORD@HOST:PORT?ech=ECH_CONFIG&pin=sha256:CERT_HASH&fp=FINGERPRINT&hop=PORT_RANGE
| 参数 | 说明 | 示例 |
|---|---|---|
USERNAME | 用户名 | abc123 |
PASSWORD | 认证密码 | tok456 |
HOST | 服务端 IP 或域名 | 203.0.113.5 |
PORT | 服务端端口（通常 443） | 443 |
ech | Base64 编码的 ECH 配置 | AEX0... |
pin | 服务端证书的 SHA-256 哈希 | sha256:abc... |
fp | TLS 指纹类型（chrome/firefox/safari/random） | chrome |
hop | UDP 端口跳跃范围（可选） | 10000-20000 |
三层身份体系
k2v5 连接过程中存在三层可观测的身份信息：
层级 明文可见 内容
─────────────────────────────────────────────────────────
1. TCP 目标 是 服务端真实 IP 地址
2. 外层 SNI 是 某主流 CDN 公共域名（ECH public_name）
3. 内层 SNI 否 k2 服务端域名（被 ECH 加密）
网络旁观者（ISP、GFW）只能看到第 1 层和第 2 层。第 3 层被 ECH 完整加密，无法在不持有 ECH 私钥的情况下解密。
ECH 配置派生
k2s 生成的 ECH 配置从某主流 CDN 的真实 ECH 配置派生：
- 查询该 CDN 公共域名的 DNS HTTPS 记录，获取 ECH 配置模板
- 复制
cipher_suites、kem_id、public_name等字段 - 递增
config_id（避免与真实配置冲突） - 替换 HPKE 公钥为 k2s 自己的公钥
结果：k2 流量的 ECH 配置与该 CDN 的真实流量在结构上无法区分。
证书与固定
k2s 使用自签名证书，不依赖任何 CA。
- 双证书设计：EC 证书 + RSA 证书，与真实 CDN 的证书多样性匹配
- 证书固定：URL 中的
pin=sha256:HASH是证书公钥的 SHA-256 哈希，客户端直接比对 - 自签名证书不出现在 Certificate Transparency（CT）日志中，避免被 CT 扫描检测
TLS 记录填充
k2s 定期（每 24 小时）从 ECH 伪装目标域名下载真实证书链，测量其 TLS Record 大小分布，并用相同的填充长度发送 TLS 握手记录。k2 握手的流量特征（数据包大小分布）与真实 CDN 的 HTTPS 流量匹配。
传输层
QUIC/H3（主传输）：基于 QUIC 的 HTTP/3 传输，原生多路复用、无队头阻塞。k2cc 算法直接控制 QUIC 的发送速率。
TCP-WebSocket（回退传输）：当 QUIC 被 UDP 封锁时自动切换。使用 smux 在单个 WebSocket 连接上实现多路复用。切换过程对应用层透明。
TransportManager 封装统一的 Dialer 接口：优先 QUIC → QUIC 失败回退 TCP-WS → 连接状态监控与自动重连。
UDP 端口跳跃
当 URL 包含 hop=START-END 参数时，k2 客户端在 QUIC 传输中随机选择端口范围内的 UDP 端口，定期更换，对抗基于固定端口的 UDP QoS 限速。
服务端 ECH 路由
k2s 在接收 TLS 连接时检查 ClientHello：
- 有 ECH 扩展：解密 ECH，验证身份，进入 k2v5 隧道处理
- 无 ECH 扩展：将原始 TCP 连接透明转发到
public_name对应的真实 CDN 服务器
非 ECH 连接收到的是真实 CDN 响应，探测脚本无法区分 k2s 与真实 CDN 服务器。
常见问题
k2cc 需要手动配置吗？
不需要。k2cc 完全自动运行，无需指定带宽参数。安装后开箱即用。
k2cc 如何与 QUIC 配合？
k2cc 直接控制 QUIC 的发送速率，替代了 QUIC 默认的拥塞控制算法。
k2cc 的性能如何验证？
k2 项目内置了 14 种网络场景的基准测试套件，涵盖从理想网络到极端审查的完整频谱。详细的测评框架见 k2 vs Hysteria2 拥塞控制对比。
接下来阅读：隐身伪装技术 从威胁模型角度分析 k2 的对抗能力，k2 vs Hysteria2 查看 k2cc 与 Brutal/BBR 的性能对比，或 k2 vs VLESS+Reality 了解 k2 与 Reality 的隐身路线对比。