k2 vs Hysteria2：拥塞控制深度对比与测评

k2cc 自适应速率控制 vs Hysteria2 Brutal 固定速率 vs BBR：14 种网络场景测评框架，审查网络中的真实表现对比。

k2 vs Hysteria2：拥塞控制深度对比与测评

拥塞控制算法是隧道协议性能的核心决定因素。在高丢包率、高延迟的跨境网络中，不同的拥塞控制策略会带来截然不同的用户体验。本文对比 k2 的 k2cc 与 Hysteria2 的 Brutal/BBR 在各类网络场景下的实际表现。

三种拥塞控制策略

k2cc — 自适应速率控制

k2cc（Adaptive Rate Control）是 k2 自研的拥塞控制算法，自动探测最优发送速率。核心特性：

零配置：无需指定带宽参数，自动探测
审查感知：区分拥塞丢包与审查丢包
RTT 敏感：实时监测延迟，主动抑制 bufferbloat
持续探测：周期性主动探测更高速率

Hysteria2 Brutal — 固定速率

Brutal 由用户手动声明最大带宽（up_mbps/down_mbps），协议以该速率持续发送，不响应拥塞信号。

需手动配置：必须指定带宽上限
忽略丢包：不区分任何丢包类型，以固定速率强行发送
无延迟感知：对 RTT 变化不敏感
丢包补偿：通过提高发送速率来补偿丢包，可能加剧拥塞

Hysteria2 BBR — Google BBR

当 Hysteria2 客户端不声明带宽时，自动使用 Google BBR 算法。BBR 基于带宽估计和 RTT 探测工作，但并非为审查网络设计。

维度一：丢包恢复

k2cc

k2cc 的审查感知机制能区分拥塞导致的丢包和审查基础设施主动丢弃的数据包，在审查性丢包环境中几乎不降速。

降速后周期性主动探测更高速率，快速恢复可用带宽。

Brutal

完全忽略丢包信号，以固定速率持续发送。表面上"不受丢包影响"，但在高丢包下会触发大量 QUIC 层重传，有效吞吐量实际下降。且无法区分拥塞性丢包——当网络真正拥塞时，Brutal 的固定速率发送会加剧拥塞。

BBR

BBR 通过带宽探测估计可用带宽，但持续的审查性丢包会干扰带宽估计模型，导致低估可用带宽。在 26% 丢包率（GFW 典型值）下，BBR 的带宽估计可能严重偏低。

维度二：延迟稳定性

k2cc

k2cc 实时监测 RTT，对延迟变化敏感。当路由器缓冲区开始积压（bufferbloat），RTT 上升触发速率下调，主动抑制延迟恶化。发包节奏控制（pacing）均匀分布数据包发送时间，避免突发。

Brutal

以恒定速率填充链路，对 RTT 完全不敏感。在共享链路上容易造成路由器缓冲区堆积，导致同一链路上所有连接（包括网页浏览、视频通话）延迟暴增。

BBR

BBR 有 RTT 探测机制，延迟控制能力优于 Brutal 但弱于 k2cc。BBR 的 ProbeRTT 阶段会周期性大幅降速以测量最小 RTT，在审查环境中这个探测窗口可能导致短暂的吞吐量下降。

维度三：带宽利用率

k2cc

持续探测最优发送速率，无需用户配置，能快速逼近可用带宽上限。在移动网络或晚高峰等带宽频繁波动的场景下，k2cc 的实时跟踪能力确保始终贴近实际可用带宽。

Brutal

带宽利用率完全取决于用户设定值的准确性：

用户设定 vs 实际带宽	结果
设定值 < 实际带宽	链路利用率不足，浪费可用带宽
设定值 ≈ 实际带宽	理想状态（但很难持续准确）
设定值 > 实际带宽	持续拥塞，重传增加，延迟上升

晚高峰时带宽从 100 Mbps 降至 30 Mbps，Brutal 仍以 100 Mbps 发送，导致 70% 的数据包需要重传。

BBR

BBR 有自动带宽探测能力，但探测周期较长（约 10 秒一个 ProbeRTT 周期），对快速变化的网络环境响应较慢。

维度四：共存公平性

k2cc

速率自适应调整，与其他 TCP/QUIC 流量和平共存。多个 k2 连接在同一链路上时能相对均衡地分配带宽。

Brutal

以固定速率持续发送，不为其他流量让路。在家庭网络中，一个 Brutal 连接可能导致同一网络下的其他设备（视频通话、网页浏览）几乎无法正常使用。多个 Brutal 连接共存时可能引发拥塞崩溃（congestion collapse）。

BBR

BBR 的公平性介于 k2cc 和 Brutal 之间。BBR 已知在与 Cubic 流量共存时可能过度抢占带宽。

测评框架：14 种网络场景

k2 内置了完整的拥塞控制基准测试套件，基于学术研究设计了 14 种网络场景，涵盖从理想环境到极端审查的完整频谱。

测试方法

通过 Docker Compose 构建隔离测试环境
使用 Linux tc/netem 精确模拟网络条件（RTT、丢包率、带宽上限）
三种拥塞控制策略并行测试：k2cc、Hysteria2 Brutal（1 Gbps 声明带宽）、Hysteria2 BBR
每场景 3 轮，下载 2 GB 文件，逐秒记录吞吐量
参考文献：RFC 8867、QUICbench (IMC 2022)、USENIX Security 2023/2025

标准网络场景（T0-T5）

场景	RTT	丢包率	带宽上限	典型环境
T0 Ideal	< 1ms	0%	无限制	Docker 基准线
T1 Good	50ms	0.1%	无限制	同洲优质 ISP
T2 Fair	100ms	1%	无限制	跨洲稳定线路
T3 Poor	150ms	2%	50 Mbps	普通 ISP
T4 Bad	200ms	5%	20 Mbps	拥堵长途链路
T5 Hostile	250ms	10%	10 Mbps	严重劣化环境

GFW 审查场景（T6-T8）

场景	RTT	丢包率	带宽上限	典型环境
T6 GFW Normal	80ms	2%	50 Mbps	中国跨境基准
T7 GFW Detected	100ms	26%	无限制	GFW 概率性封锁（USENIX'23 测量值）
T8 GFW Extreme	200ms	50%	10 Mbps	敏感时期 / 定向封锁

T7 场景中的 26% 丢包率来自 USENIX Security 2023 对 GFW 概率性丢包行为的实际测量。这是传统拥塞控制算法的"死亡区间"——Cubic 在此丢包率下吞吐量不足理论值的 10%。

中国运营商场景（C1-C5）

基于 APNIC 2020 研究数据和社区实测，模拟三大运营商到海外（日本）的真实条件：

场景	运营商	RTT	丢包率	带宽上限	时段
C1 CMCC South	中国移动	120ms	5%	30 Mbps	非高峰
C2 CMCC Peak	中国移动	200ms	15%	8 Mbps	晚高峰 8-11PM
C3 CT CN2	电信 CN2 GIA	50ms	0.5%	200 Mbps	全时段
C4 CT 163 Peak	电信 163 骨干	100ms	8%	30 Mbps	晚高峰
C5 CU Peak	中国联通	120ms	6%	20 Mbps	拥堵时段

各场景下的算法预期表现

基于 k2cc 的设计特性，各类场景下的预期表现：

场景类型	k2cc 优势	Brutal 弱点	BBR 弱点
T0-T1（理想/良好）	自动饱和带宽	依赖手动设定	正常工作
T2-T3（中等）	自适应探测	可能过度发送	响应偏慢
T4-T5（恶劣）	审查感知，维持有效吞吐	重传风暴	低估带宽
T6（GFW 基准）	GFW 模式容忍审查丢包	固定速率勉强可用	带宽估计受干扰
T7（GFW 概率封锁）	审查感知维持高速	重传风暴严重	严重低估
T8（极端审查）	仍有有效吞吐	拥塞崩溃风险	几乎不可用
C1-C5（运营商）	实时跟踪晚高峰波动	固定设定无法适应	ProbeRTT 降速

运行测评

测评套件开源在 k2 代码仓库中，可通过以下命令运行：

cd k2/docker/bench

# 运行全部 14 个场景
./run.sh

# 运行指定场景
./run.sh T7_gfw_detected C2_cmcc_peak

# 自定义参数
ROUNDS=5 SIZE=100MB BRUTAL_MBPS=500 ./run.sh T0_ideal

输出包括：

逐秒吞吐量日志：精确的速率变化曲线
场景对比报告：三种算法的平均吞吐、延迟变异系数、超时率
CSV 数据导出：可用于自定义可视化

对比总结

对比维度	k2cc（自适应速率控制）	Hysteria2 Brutal（固定速率）	Hysteria2 BBR
配置门槛	零配置	需手动指定带宽	零配置
丢包恢复	审查感知自适应	忽略丢包，重传补偿	带宽估计受干扰
延迟稳定性	RTT 感知 + pacing	无延迟控制	有 ProbeRTT
带宽利用率	自动探测，实时跟踪	取决于手动设定准确性	探测周期较长
共存公平性	自适应共存	挤占其他流量	部分抢占
审查网络	专门优化	固定速率不适应	非设计目标
弱网适应性	多策略弱网适应	无适应	有限适应

常见问题

Brutal 声明 1Gbps 带宽不是更快吗？

在理想网络（T0）中，Brutal 声明高带宽确实能快速饱和链路。但在真实跨境网络中，Brutal 的固定速率无法区分链路容量和声明值之间的差距——超出链路容量的部分全部变成丢包和重传，有效吞吐量反而下降。k2cc 通过自动探测始终贴近实际可用带宽。

BBR 也是自适应算法，和 k2cc 有什么区别？

BBR 是为通用互联网设计的优秀算法，但没有审查感知能力。在 GFW 概率性丢包环境中，BBR 的带宽估计会被持续丢包干扰而严重低估。k2cc 的审查感知机制能识别非拥塞性丢包，在相同网络条件下维持远高于 BBR 的吞吐量。

k2cc 算法的技术细节在哪里？

详细说明请参阅 k2cc 自适应速率控制。

k2 vs Hysteria2：拥塞控制深度对比与测评

k2cc 自适应速率控制 vs Hysteria2 Brutal 固定速率 vs BBR：14 种网络场景测评框架，审查网络中的真实表现对比。

k2 vs Hysteria2：拥塞控制深度对比与测评

三种拥塞控制策略

k2cc — 自适应速率控制

k2cc（Adaptive Rate Control）是 k2 自研的拥塞控制算法，自动探测最优发送速率。核心特性：

零配置：无需指定带宽参数，自动探测
审查感知：区分拥塞丢包与审查丢包
RTT 敏感：实时监测延迟，主动抑制 bufferbloat
持续探测：周期性主动探测更高速率

Hysteria2 Brutal — 固定速率

Brutal 由用户手动声明最大带宽（up_mbps/down_mbps），协议以该速率持续发送，不响应拥塞信号。

需手动配置：必须指定带宽上限
忽略丢包：不区分任何丢包类型，以固定速率强行发送
无延迟感知：对 RTT 变化不敏感
丢包补偿：通过提高发送速率来补偿丢包，可能加剧拥塞

Hysteria2 BBR — Google BBR

当 Hysteria2 客户端不声明带宽时，自动使用 Google BBR 算法。BBR 基于带宽估计和 RTT 探测工作，但并非为审查网络设计。

维度一：丢包恢复

k2cc

k2cc 的审查感知机制能区分拥塞导致的丢包和审查基础设施主动丢弃的数据包，在审查性丢包环境中几乎不降速。

降速后周期性主动探测更高速率，快速恢复可用带宽。

Brutal

BBR

维度二：延迟稳定性

k2cc

Brutal

以恒定速率填充链路，对 RTT 完全不敏感。在共享链路上容易造成路由器缓冲区堆积，导致同一链路上所有连接（包括网页浏览、视频通话）延迟暴增。

BBR

维度三：带宽利用率

k2cc

Brutal

带宽利用率完全取决于用户设定值的准确性：

用户设定 vs 实际带宽	结果
设定值 < 实际带宽	链路利用率不足，浪费可用带宽
设定值 ≈ 实际带宽	理想状态（但很难持续准确）
设定值 > 实际带宽	持续拥塞，重传增加，延迟上升

晚高峰时带宽从 100 Mbps 降至 30 Mbps，Brutal 仍以 100 Mbps 发送，导致 70% 的数据包需要重传。

BBR

BBR 有自动带宽探测能力，但探测周期较长（约 10 秒一个 ProbeRTT 周期），对快速变化的网络环境响应较慢。

维度四：共存公平性

k2cc

速率自适应调整，与其他 TCP/QUIC 流量和平共存。多个 k2 连接在同一链路上时能相对均衡地分配带宽。

Brutal

BBR

BBR 的公平性介于 k2cc 和 Brutal 之间。BBR 已知在与 Cubic 流量共存时可能过度抢占带宽。

测评框架：14 种网络场景

k2 内置了完整的拥塞控制基准测试套件，基于学术研究设计了 14 种网络场景，涵盖从理想环境到极端审查的完整频谱。

测试方法

通过 Docker Compose 构建隔离测试环境
使用 Linux tc/netem 精确模拟网络条件（RTT、丢包率、带宽上限）
三种拥塞控制策略并行测试：k2cc、Hysteria2 Brutal（1 Gbps 声明带宽）、Hysteria2 BBR
每场景 3 轮，下载 2 GB 文件，逐秒记录吞吐量
参考文献：RFC 8867、QUICbench (IMC 2022)、USENIX Security 2023/2025

标准网络场景（T0-T5）

场景	RTT	丢包率	带宽上限	典型环境
T0 Ideal	< 1ms	0%	无限制	Docker 基准线
T1 Good	50ms	0.1%	无限制	同洲优质 ISP
T2 Fair	100ms	1%	无限制	跨洲稳定线路
T3 Poor	150ms	2%	50 Mbps	普通 ISP
T4 Bad	200ms	5%	20 Mbps	拥堵长途链路
T5 Hostile	250ms	10%	10 Mbps	严重劣化环境

GFW 审查场景（T6-T8）

场景	RTT	丢包率	带宽上限	典型环境
T6 GFW Normal	80ms	2%	50 Mbps	中国跨境基准
T7 GFW Detected	100ms	26%	无限制	GFW 概率性封锁（USENIX'23 测量值）
T8 GFW Extreme	200ms	50%	10 Mbps	敏感时期 / 定向封锁

中国运营商场景（C1-C5）

基于 APNIC 2020 研究数据和社区实测，模拟三大运营商到海外（日本）的真实条件：

场景	运营商	RTT	丢包率	带宽上限	时段
C1 CMCC South	中国移动	120ms	5%	30 Mbps	非高峰
C2 CMCC Peak	中国移动	200ms	15%	8 Mbps	晚高峰 8-11PM
C3 CT CN2	电信 CN2 GIA	50ms	0.5%	200 Mbps	全时段
C4 CT 163 Peak	电信 163 骨干	100ms	8%	30 Mbps	晚高峰
C5 CU Peak	中国联通	120ms	6%	20 Mbps	拥堵时段

各场景下的算法预期表现

基于 k2cc 的设计特性，各类场景下的预期表现：

场景类型	k2cc 优势	Brutal 弱点	BBR 弱点
T0-T1（理想/良好）	自动饱和带宽	依赖手动设定	正常工作
T2-T3（中等）	自适应探测	可能过度发送	响应偏慢
T4-T5（恶劣）	审查感知，维持有效吞吐	重传风暴	低估带宽
T6（GFW 基准）	GFW 模式容忍审查丢包	固定速率勉强可用	带宽估计受干扰
T7（GFW 概率封锁）	审查感知维持高速	重传风暴严重	严重低估
T8（极端审查）	仍有有效吞吐	拥塞崩溃风险	几乎不可用
C1-C5（运营商）	实时跟踪晚高峰波动	固定设定无法适应	ProbeRTT 降速

运行测评

测评套件开源在 k2 代码仓库中，可通过以下命令运行：

cd k2/docker/bench

# 运行全部 14 个场景
./run.sh

# 运行指定场景
./run.sh T7_gfw_detected C2_cmcc_peak

# 自定义参数
ROUNDS=5 SIZE=100MB BRUTAL_MBPS=500 ./run.sh T0_ideal

输出包括：

逐秒吞吐量日志：精确的速率变化曲线
场景对比报告：三种算法的平均吞吐、延迟变异系数、超时率
CSV 数据导出：可用于自定义可视化

对比总结

对比维度	k2cc（自适应速率控制）	Hysteria2 Brutal（固定速率）	Hysteria2 BBR
配置门槛	零配置	需手动指定带宽	零配置
丢包恢复	审查感知自适应	忽略丢包，重传补偿	带宽估计受干扰
延迟稳定性	RTT 感知 + pacing	无延迟控制	有 ProbeRTT
带宽利用率	自动探测，实时跟踪	取决于手动设定准确性	探测周期较长
共存公平性	自适应共存	挤占其他流量	部分抢占
审查网络	专门优化	固定速率不适应	非设计目标
弱网适应性	多策略弱网适应	无适应	有限适应

常见问题

Brutal 声明 1Gbps 带宽不是更快吗？

BBR 也是自适应算法，和 k2cc 有什么区别？

k2cc 算法的技术细节在哪里？

详细说明请参阅 k2cc 自适应速率控制。