Hysteria项目中UDP转发流量处理DOQ协议的问题分析

问题背景

在Hysteria项目中，用户报告了一个关于UDP转发流量处理DOQ(DNS over QUIC)协议时出现的异常问题。当通过Hysteria服务端和UDP转发工具(gost/socat)组合使用时，DOQ协议的DNS查询会出现随机失败的情况，而普通的UDP DNS查询则能正常工作。

问题现象

用户搭建了如下测试环境：

• 服务器T运行Hysteria服务端(BBR加速)
• 服务器R运行UDP转发工具(gost/socat)将流量转发到T
• 客户端C运行Hysteria客户端和网络增强模式

当使用q工具进行DOQ查询时(q @quic://dns.nextdns.io A google.com)，大多数情况下会失败，报错信息为"timeout: no recent network activity"或"handshake did not complete in time"。只有极少数情况下能成功完成查询。

技术分析

通过深入分析Hysteria项目的源代码和抓包数据，发现问题出在UDP数据包重组逻辑上。Hysteria在处理分片UDP数据包时，使用了一个全局的Defragger结构体，该结构体只能保存一个PacketID的分片信息。

当多个DOQ查询并发进行时，不同PacketID的分片数据包会互相干扰。例如：

1. PacketID 48970的分片1到达
2. 接着PacketID 8662的分片1到达
3. 然后PacketID 48970的分片0到达

由于Defragger只能保存一个PacketID的状态，导致先到达的分片1信息被后续的其他PacketID分片覆盖，无法正确重组完整的数据包。

解决方案

针对这个问题，合理的修复方案是将Defragger改为基于PacketID的map结构，为每个PacketID维护独立的分片状态。这样不同查询的分片数据就不会互相干扰。

修改后的逻辑工作流程如下：

1. 收到分片数据包时，根据PacketID查找或创建对应的Defragger
2. 在该PacketID的Defragger中记录分片信息
3. 当该PacketID的所有分片都到达时，进行数据重组
4. 重组完成后，从map中移除该PacketID的Defragger

技术细节

在QUIC协议中，每个数据包都有唯一的PacketID。DOQ作为基于QUIC的DNS协议，同样继承了这一特性。Hysteria的UDP转发功能需要正确处理这些分片数据包，特别是在高并发场景下。

原始实现的问题在于：

• 单Defragger设计无法处理并发QUIC连接
• 分片到达顺序不可控时会导致数据丢失
• 没有超时清理机制可能导致内存泄漏

改进后的实现应该：

• 使用并发安全的map结构存储Defragger
• 为每个PacketID维护独立状态
• 添加超时清理机制
• 优化内存使用效率

总结

这个问题展示了在实现网络协议栈时需要考虑的并发处理能力。特别是在UDP协议中，数据包的到达顺序和并发处理是需要特别关注的重点。Hysteria作为高性能网络工具，正确处理各种协议的分片和重组是保证稳定性的关键。

对于开发者来说，这个案例也提醒我们在设计协议处理逻辑时，要充分考虑实际网络环境中的各种边界条件，包括但不限于：数据包乱序、分片丢失、高并发场景等。只有全面考虑这些因素，才能开发出稳定可靠的网络应用。