Hysteria 2 Brutal 拥塞控制与 UDP 恶劣丢包穿透工程拆解（2026 深度实测版）

一、引言：通信物理现实与核心工程痛点

跨洋链路的性能天花板由二氧化硅的介电常数决定，而非由任何协议栈的优化技巧决定。单模光纤纤芯折射率 $n \approx 1.468$，真空中光速 $c = 300,000\text{ km/s}$，纤芯内群速度 $v = c/n \approx 204,360\text{ km/s}$，对应单向传播时延约 $4.89\ \mu\text{s/km}$。上海至洛杉矶海缆路径典型长度 11,00013,000 km（含登陆段与陆地回传），单向光传播时延即达 5464 ms，双向 RTT 物理下界 108128 ms；叠加海缆再生中继、OTN 交叉、PE 路由器排队与跨境交换点调度，生产环境 RTT 普遍落在 150220 ms 区间。这个数字是任何拥塞控制算法都无法压缩的刚性成本。

真正的工程痛点出现在丢包维度。跨境骨干在晚高峰（19:00~23:30 CST）普遍执行 QoS 整形与 UDP 限速策略：国际出口方向对非白名单 UDP 流做 policer 限速、对突发流量做 token bucket 整形，部分路径对 QUIC/UDP 443 做特征识别后降优先级。上海电信 AS4134 普通国际出口在晚高峰的随机丢包可达 8%~25%，CN2 GIA（AS4809 承载、AS4134 宣告）路径可压到 1%~3%；北京联通 AS9929 相对平稳（3%~8%），AS4837 普通出口在高峰段抖动明显；广州移动 AS58453 因 CMIN2 与普通出口差异，丢包分布呈明显的双峰特征。对基于 ACK 时钟的 CUBIC/BBR 而言，随机丢包被误判为拥塞信号，cwnd 反复回退，吞吐塌陷至链路容量的 15%~30%。

Hysteria 2 的 Brutal 算法正是针对这一场景设计的：放弃"探测可用带宽"的范式，改为"声明带宽 + 强制 pacing"，把丢包从拥塞信号中解耦。本文以三网分布式探针的实测数据为基准，拆解 Brutal 的机制边界、报文行为与部署陷阱。评测口径与质检标准参见 评测方法论与质检标准，实验室背景见 关于 AirportMatrix 评测实验室。

二、底层物理拓扑与传输介质机理解剖

2.1 端到端路径的物理分层

[Client 上海]                                          [Server 洛杉矶]
  |  10GE 接入                                            |  10GE 接入
  v                                                       v
[OLT/BRAS] --(城域 OTN)--> [AS4134 PE] --(国际出口)--> [跨境 IXP] --(海缆)--> [AS15169/AS13335 上游]
                                |                          |
                           QoS policer               海缆再生中继
                           UDP 限速策略               OTN 交叉 (每 80~120km)
                                |                          |
                           token bucket              排队时延 5~40ms

关键物理量：海缆段每 80120 km 设再生中继，中继引入的附加时延约 0.020.05 ms/段；跨境 IXP（如 Equinix LA、HKIX）的交换矩阵排队在拥塞时段可贡献 10~40 ms 的额外 RTT。这些排队时延是 Brutal 需要"用带宽声明去覆盖"的部分——它无法消除排队，只能通过 pacing 降低自身注入突发的概率。

2.2 QUIC 报文与 UDP 封装时序

Hysteria 2 基于 QUIC（RFC 9000）承载，应用层为自定义的 Hysteria 协议帧。一个典型数据包的封装链路：

[App Payload ≤ 1200B]
   └─ Hysteria Frame Header (2~4B)
      └─ QUIC STREAM Frame (type 0x08~0x0f, offset+len+data)
         └─ QUIC Short Header (1B flags + 连接ID + PN)
            └─ UDP Header (8B, src/dst port)
               └─ IP Header (20B IPv4 / 40B IPv6)
                  └─ Ethernet Frame (14B) + FCS(4B)

MTU 1500 时，IPv4 + UDP + QUIC 头部开销约 20+8+1+8(连接ID)+2(PN) ≈ 3948 B，Hysteria 帧头 24 B，实际应用载荷上限约 14001440 B。工程上必须把 QUIC 的 max_udp_payload_size 与路径 MTU 对齐：跨境路径常见 PMTUD 黑洞（ICMP 被过滤），若不显式设置 MTU 14001420，会出现大包被静默丢弃、表现为"小包通、大包卡"的典型故障。MSS 1460 是 TCP 侧概念，QUIC 侧对应的是 max_udp_payload_size，两者不可混用。

2.3 Brutal 的 pacing 时序模型

Brutal 的核心状态机极简：发送端维护一个固定的目标速率 $R_{target}$（由配置的 up/down 带宽换算），每个发送周期按 $R_{target} \cdot \Delta t$ 字节注入，不随 ACK 到达动态调整 cwnd。其伪代码语义：

on_tick(dt):
    budget += R_target * dt
    while budget >= next_packet_size and inflight < max_inflight:
        send(next_packet)
        budget -= next_packet_size
        inflight += next_packet_size

on_ack(pkt):
    inflight -= pkt.size
    // 不调整 R_target，不触发 AIMD
    // 仅用于丢包检测与重传调度

这与 BBR 的"探测-建模"路径形成根本对立：BBR 需要至少一个 RTT 的带宽样本才能收敛，Brutal 在首个 RTT 即按声明速率注入。代价是声明值超过真实可用带宽时，多余流量在瓶颈队列堆积，触发 policer 丢包，形成"声明越大、丢包越多、重传越多"的正反馈。

三、核心指标量化测试方法论与三网骨干实测大表

3.1 测试基线

探针部署：上海电信 AS4134（普通出口 + CN2 双路径）、北京联通 AS9929 与 AS4837 双栈、广州移动 AS58453；服务端位于洛杉矶（上游 AS15169 与 AS13335 各一组）。测量工具：MTR 双向 200 包采样、iperf3 UDP 模式 60s 压测、自研 QUIC 吞吐探针（记录 pacing 速率、inflight、重传率、RTT 分位）。测试时段覆盖工作日 14:00（平峰）与 21:00~22:30（晚高峰）。所有测试重复 5 次取中位数，剔除首 3s 慢启动段。

3.2 表一：三网路径物理与丢包基线（晚高峰 21:00~22:30）

3.3 表二：Brutal vs BBR vs CUBIC 吞吐对比（60s UDP 压测，单流）

晚高峰 AS4134 普通出口场景下，Brutal 吞吐为 BBRv3 的 2.52 倍、CUBIC 的 3.63 倍；代价是重传放大比升至 1.18~1.42，即实际注入链路的字节数比有效载荷高 18%~42%。

3.4 表三：MTU 与 UDP 缓冲配置对 Brutal 稳定性的影响（上海 AS4134 晚高峰）

结论：跨境路径应将 MTU 压至 1400~1420，配合 net.core.rmem_max/wmem_max 提升至 4MB 以上，否则 Brutal 的高注入速率会在 socket 缓冲处形成丢包，表现为"算法没丢、内核丢了"的伪故障。

四、协议报文拆解与拥塞控制/加解密机制演进

4.1 QUIC 帧与 Hysteria 帧的嵌套

Hysteria 2 在 QUIC 之上定义了自己的帧类型：ClientHello（认证与带宽协商）、ServerHello（确认与参数下发）、UDPPacket（数据承载）、UDPError、UDPClose。带宽协商在握手阶段完成：客户端上报 up/down，服务端可做上限裁剪。这一设计把"带宽声明"变成协议级契约，而非运行时启发式。

QUIC 层的关键帧：STREAM（0x080x0f）承载数据，ACK（0x020x03）携带 ACK Range，PING（0x01）用于保活与 RTT 采样，CONNECTION_CLOSE（0x1c~0x1d）终止。Brutal 对 ACK 的使用仅限于丢包检测与 RTT 估计，不用于 cwnd 调整——这是它与所有 ACK 时钟算法的分水岭。

4.2 加解密机制

Hysteria 2 默认使用 QUIC 的 TLS 1.3 握手，应用层数据由 QUIC 的 AEAD（AES-128-GCM 或 ChaCha20-Poly1305）保护。握手阶段的带宽协商参数在 TLS 记录层内传输，具备前向保密性。认证采用预共享密码（password）派生的凭证，配合可选的 obfs（Salamander 混淆）对抗 DPI 特征识别。Salamander 对 UDP 载荷做固定密钥的 XOR + 随机填充，改变包长分布，降低被 QoS 分类器命中的概率。协议细节可参考 Hysteria 2 协议性能解析 与 VLESS 协议深度指南 的对比章节。

4.3 拥塞控制的演进脉络

从 Reno 的 AIMD，到 CUBIC 的三次函数窗口增长，到 BBR 的带宽-时延积建模，再到 Brutal 的"声明即契约"，本质是在"丢包是否等于拥塞"这一假设上做取舍。跨境链路的丢包大量来自 policer 与随机早丢（RED/WRED），与拥塞无因果关系。Brutal 的工程价值在于承认这一现实，把控制权交给运维者的带宽声明；其工程风险也在于此——声明值必须基于真实链路容量，而非"我希望它有多快"。

五、实战部署：生产级客户端/网关精细化分流配置

5.1 带宽声明的工程取值

声明值应取"路径真实可用带宽的 70%85%"，而非签约带宽。上海 AS4134 普通出口晚高峰实测可用 6090 Mbps 时，声明 100 Mbps 会导致重传放大比升至 1.4 以上；声明 70 Mbps 时重传比降至 1.15，有效吞吐反而更高。CN2 路径可声明至实测值的 90%。上行方向同理，且上行 policer 通常更严格。

5.2 sing-box 配置要点

{
  "type": "hysteria2",
  "server": "example.com",
  "server_port": 443,
  "up_mbps": 70,
  "down_mbps": 300,
  "obfs": { "type": "salamander", "password": "***" },
  "tls": { "enabled": true, "server_name": "example.com" }
}

配合 "mtu": 1400 与系统级 UDP 缓冲调优。分流规则建议按域名后缀 + GeoIP 双维度，避免全量代理导致 Brutal 的 pacing 被本地应用突发打乱。完整配置实践参见 sing-box 极客配置实践 与 Clash Verge Rev 保姆级配置教程。

5.3 网关侧的关键内核参数

net.core.rmem_max = 4194304
net.core.wmem_max = 4194304
net.ipv4.udp_mem = 65536 131072 262144
net.core.netdev_max_backlog = 5000

UDP 无连接特性意味着内核不会为每个流维护独立缓冲，高并发下 rmem_max 不足会直接表现为应用层丢包。这一点在 Brutal 高注入速率下被放大。

六、常见工程误区与链路故障深度排查决策树

6.1 误区清单

• 误区一：声明带宽越高越好。 声明超过 policer 阈值会触发持续丢包，重传放大比飙升，有效吞吐反降。
• 误区二：Brutal 能对抗所有丢包。 它对随机丢包鲁棒，对突发性全丢包（如链路闪断、路由抖动）无能为力，此时应依赖 QUIC 的连接迁移与重连。
• 误区三：MTU 1500 是默认安全值。 跨境路径 PMTUD 黑洞普遍，必须显式降 MTU。
• 误区四：混淆（obfs）能绕过所有 QoS。 Salamander 改变包长分布，但无法对抗基于流统计特征的分类器。

6.2 故障排查决策树

吞吐低于预期?
├─ 检查 MTU 是否 1400~1420 → 否 → 调整并复测
├─ 检查 UDP 缓冲是否 ≥4MB → 否 → 调优
├─ 检查声明带宽 vs 实测可用 → 声明过高 → 下调至 70%~85%
├─ MTR 双向丢包分布
│  ├─ 单跳集中丢包 → 该跳 policer/拥塞 → 换路径或降速
│  ├─ 全程均匀丢包 → 随机丢包 → Brutal 应已覆盖，检查重传率
│  └─ 末端集中丢包 → 服务端接入瓶颈 → 检查服务端网卡与队列
└─ 检查是否被 QoS 识别 → 启用 obfs 或换端口

七、长效选型决策与企业/个人场景避坑准则

企业场景：跨境办公与科研数据回传对稳定性要求高于峰值吞吐，建议声明值保守（实测 70%），并配置多路径冗余（CN2 + 9929 双线）。个人场景：晚高峰娱乐流量对突发敏感，可适当提高声明值但需监控重传率，超过 1.5 即回调。选型时可参考 精选 IEPL 专线机场排行榜 与 30秒智能代理选型向导，但须以自身路径实测为准，任何榜单都不能替代 MTR 与压测。

长效决策的三个硬指标：晚高峰重传放大比 ≤1.3、P95 抖动 ≤30 ms、连接中断 ≤1 次/小时。任一指标越界，优先回调带宽声明而非更换协议。

八、常见高频技术疑问解答 (FAQ)

Q1：Brutal 在 30% 以上丢包时还能维持吞吐吗？ A：不能线性维持。实测 30% 随机丢包下，Brutal 有效吞吐降至声明值的 45%60%，重传放大比升至 1.82.2，链路实际承载字节数远超有效载荷。此场景应降速并考虑多路径聚合，而非继续提高声明值。

Q2：Brutal 与 BBR 能否共存或切换？ A：Hysteria 2 的 Brutal 是协议内置算法，不与 QUIC 的 BBR 共存于同一连接。可在客户端按路径质量做策略切换：低丢包路径用 BBR 类算法节省重传，高丢包路径用 Brutal 保吞吐。

Q3：为什么 MTU 1400 比 1500 吞吐更高？ A：跨境路径 PMTUD 黑洞导致 1500 字节包被静默丢弃，表现为大包重传、小包正常。降至 1400 规避分片与黑洞，虽头部开销增加约 7%，但消除了伪丢包，净吞吐提升。

Q4：Salamander 混淆对 QoS 规避有效吗？ A：对基于包长分布与固定特征的简单分类器有效，对基于流统计（包速率、字节速率、熵）的分类器效果有限。晚高峰 UDP 限速若基于五元组+速率，混淆无法规避，需换端口或换路径。

Q5：声明带宽应如何随时间段调整？ A：建议按平峰/晚高峰双档配置，晚高峰声明值下调 15%~25%。自动化方案可基于 MTR 丢包率与重传比做反馈回调，但需设置滞回区间避免震荡。