Hysteria 加密算法实测：AES-GCM vs ChaCha20-Poly1305，性能谁更胜一筹？

• 在实际网络环境下挖掘加密算法的性能差异
• 从原理上看性能差异
• 核心差异汇总
• 实测方法与环境说明
• 典型场景与选择建议
• 高性能服务器节点（数据中心级别）
• 移动设备或边缘节点
• 混合或不可控客户端生态
• 实现与部署时需要注意的细节
• 未来趋势与发展方向
• 对技术爱好者的实用建议

在实际网络环境下挖掘加密算法的性能差异

Hysteria 作为近年来在翻墙与低延迟代理圈内受关注的传输层协议，允许在 UDP 基础上使用不同的 AEAD（Authenticated Encryption with Associated Data）算法来保护数据完整性与机密性。社区中常见的选择是 AES-GCM 与 ChaCha20-Poly1305。理论上两者都提供相似的安全属性，但在真实世界的延迟、吞吐和 CPU 占用上表现并不完全相同。本文基于原理解析、实测数据与典型场景，帮助你在 fq.dog 的技术读物体系下理解何时该选哪种算法。

从原理上看性能差异

AES-GCM 依赖于 AES 块加密与 Galois 域的多项式运算，其性能在有硬件加速（如 Intel 的 AES-NI 或 ARM 的 AES 指令集）的平台上非常出色。硬件加速能极大降低每字节的 CPU 周期，从而在高吞吐场景下实现低延迟与高带宽。

ChaCha20-Poly1305 则是纯软件实现的流加密 + MAC 组合，设计目标之一就是在没有硬件 AES 支持的设备上仍能保持高性能。移动设备、低功耗 CPU（如老旧 x86、部分 ARM 核心）上，ChaCha20 往往比 AES-GCM 更省 CPU，且对数据长短分布更友好。

核心差异汇总

简要对比两种算法的关键点：

• 硬件依赖性：AES-GCM 在有 AES-NI/AES 指令时优势明显；ChaCha20-Poly1305 则几乎不依赖硬件。
• 短报文性能：ChaCha20 在短数据包（VoIP、小包代理）上延迟优于未加速的 AES-GCM。
• 长传输吞吐：在启用 AES-NI 的服务器上，AES-GCM 的吞吐可以领先或持平。
• 实现复杂度：AES-GCM 的安全实现需关注侧信道与常数时间操作；ChaCha20 的实现相对简单且安全边界清晰。

实测方法与环境说明

为保证对比的可信度，采用以下条件进行对比测试：

• 测试软件：Hysteria 服务端与客户端最新版。
• 服务器硬件：x86_64 双核云主机，支持 AES-NI（可切换关闭以模拟无加速环境）。
• 客户端设备：一台带 AES 指令集的笔记本与一台旧款 ARM 手机（无 AES 硬件加速）。
• 网络环境：公网往返延迟约 40ms，带宽上限 200 Mbps，测试场景包括 TCP/UDP 混合实时与大文件传输。
• 测量指标：单连接吞吐、CPU 占用、首包延迟与短包 RTT。

测试结果（摘要）：
1) 服务器启用 AES-NI：
   - 大文件吞吐：AES-GCM 与 ChaCha20 相近，AES-GCM 稍优约 5-10%。
   - CPU 占用：AES-GCM 更低（尤其在多并发下）。
   - 短包延迟：差异微小，均能满足实时应用。

2) 服务器关闭 AES-NI 或客户端为无 AES 设备：
   - 大文件吞吐：ChaCha20 明显更好（提升约 20-40%）。
   - 短包延迟：ChaCha20 优势更明显，首包 RTT 更低。
   - CPU 占用：ChaCha20 更节能。

典型场景与选择建议

根据不同使用场景，选择不同 AEAD 可以更好地平衡性能与资源：

高性能服务器节点（数据中心级别）

这些节点通常启用了 AES-NI 并且承担大量并发。优先选择 AES-GCM：能在多核环境下以更低的 CPU 消耗换取较高吞吐，适合搭建出口节点或承载大规模并发转发。

移动设备或边缘节点

对于手机、树莓派或旧款云主机，建议使用 ChaCha20-Poly1305。在这些设备上，ChaCha20 的软件性能与能耗表现更好，短包场景（即时通讯、游戏、低延迟代理）下体验更佳。

混合或不可控客户端生态

如果你的用户群体包含未知硬件（既有支持 AES-NI 的桌面，也有老旧手机），可以考虑在服务端开启两种算法的支持，让客户端根据本地能力协商使用。Hysteria 的配置通常允许灵活选项，以便兼顾兼容性与性能。

实现与部署时需要注意的细节

在真实部署时，单纯选择算法并不能保证最优体验，还需关注以下因素：

• 密钥与随机数管理：无论算法，密钥轮换、随机数质量与 nonce 处理都是安全的关键。
• 测量与监控：监控 CPU、延迟与丢包率，识别是否因加密开销导致性能瓶颈。
• 编译与库版本：使用系统提供的加密库（如 OpenSSL）时，确认其是否已启用硬件加速与最新补丁。
• 并发模型：在高并发场景，线程/协程调度和 I/O 模型对延迟的影响往往超过加密本身。

未来趋势与发展方向

加密算法在性能与安全之间不断权衡。未来的趋势包括：

• 更广泛的硬件加速支持，尤其是在 ARM 平台（手机/边缘设备）普及 AES 指令后，AES-GCM 的优势将进一步扩大。
• 算法层面的优化，例如更高效的 AEAD 设计或更低延迟的认证机制，尤其针对短报文场景。
• 协议级优化，例如多路复用、拥塞控制与包检重发策略与加密协同工作，减少加密与网络层之间的性能损耗。

对技术爱好者的实用建议

在搭建或优化 Hysteria 节点时，先做小规模测试再全面切换。针对你的主要用户群（数据中心用户 vs 移动用户）选择默认算法，并在服务端保留备选项以便兼容。监控数据应该是决策的最终依据，而不是单纯的理论结论。

通过对原理与实测数据的结合，可以看出：没有绝对的“全能”答案。理解你的硬件环境和用户需求，才能在 AES-GCM 与 ChaCha20-Poly1305 之间做出最合适的选择。