- 为什么要对加密方式做性能实测
- 测试环境与方法概述
- 被测加密方案
- 关键指标与典型结果（中位数）
- 从数据看性能瓶颈
- 为何 CFB 表现最差
- 实践中的体验差异
- 选择建议（面向技术爱好者）
- 注意事项与误区
- 未来趋势简评
为什么要对加密方式做性能实测
在选择 Shadowsocks 服务端与客户端的加密方式时，很多人关注的是安全性，但在真实使用场景下，速度、延迟与资源占用往往对体验影响更大。不同加密算法在 CPU 指令集、实现优化和包处理方式上差异显著，本次实测旨在把常用加密方案在相同网络与硬件条件下的表现量化，帮助技术爱好者进行权衡。
测试环境与方法概述
测试在一台云服务器（4 vCPU，8 GB 内存，Linux）与本地测试机（相同 CPU 家族）之间进行。链路为千兆以太网，裸链路带宽可达 900 Mbps。测试工具包括网络吞吐基准（类似 iperf）、HTTP 下载/上传、以及 ICMP/TCP 延迟测试。为了减少误差，所有测试在空闲时段重复 5 次取中位数。
被测加密方案
本次对比包含常见且广泛使用的四种方案：aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305与aes-128-cfb（作为兼容性参考）。这些算法代表了基于 AEAD、流/块的主流实现。
关键指标与典型结果（中位数）
算法 吞吐（Mbps） 平均 RTT（ms） CPU（客户端） 内存占用（MB） aes-128-gcm 620 18 12% 32 aes-256-gcm 540 20 18% 34 chacha20-ietf-poly1305 680 17 10% 30 aes-128-cfb 400 25 22% 28
从数据看性能瓶颈
可以看到，chacha20-ietf-poly1305在大多数测试中表现最好，吞吐高且延迟低，且 CPU 占用最低。这与其在通用 CPU 上的高效实现和较少的内存访问有关。AEAD 的 aes-128-gcm 次之，兼顾速度与安全；而 aes-256-gcm 在启用更长密钥与更多轮运算时，CPU 负担显著上升，从而带来吞吐下降和延迟增加。
为何 CFB 表现最差
aes-128-cfb 属于较老的分组链模式，缺乏现代 AEAD 的内联认证，且常见实现缺少针对现代 CPU 的加速微优化，导致吞吐与延迟均不占优。除非有兼容性限制或极端场景需求，否则不建议优先选择。
实践中的体验差异
在网页浏览与在线视频场景下，延迟对交互感受影响最大：chacha20 与 aes-128-gcm 的较低 RTT 明显让页面响应更快；而在大文件传输或备份场景，吞吐率决定完成时间，此时 chacha20 也能节省约 10%-20% 的传输时间。CPU 占用方面，在低端路由器或单板机（如 ARM 平台）上，chacha20 优势会更加明显。
选择建议（面向技术爱好者）
根据不同需求可作如下倾向性选择：
– 追求最佳综合性能：优先考虑 chacha20-ietf-poly1305（尤其是在没有 AES 硬件加速的设备上）。
– 需要广泛兼容且希望使用硬件加速：aes-128-gcm 是稳妥选择。
– 高安全需求同时有硬件支持：可考虑 aes-256-gcm，但需接受更高的资源消耗。
– 兼容老设备或特殊实现时才使用 aes-128-cfb。
注意事项与误区
不要仅凭单次吞吐测试决定加密策略。现实网络波动、MTU、UDP vs TCP 报文特性、以及实现的库（比如 OpenSSL、BoringSSL、libsodium）会显著影响最终表现。此外，开启多路复用、压缩或额外的包处理逻辑也会改变 CPU 与延迟表现。
未来趋势简评
随着通用 CPU 的向量化指令集（如 AES-NI、ARMv8 的 Crypto 扩展）普遍化，AES 系列在支持硬件加速的平台上会持续缩小与 ChaCha20 的差距。另一方面，轻量级 AEAD 与更高效的实现继续推动移动与边缘设备上的加密性能提升，用户在选择时应结合实际部署平台与性能剖面。
本文基于可复现的基准思路与多次测量得出结论，旨在为关注 Shadowsocks 性能的技术爱好者提供参考。
暂无评论内容