ShadowsocksR 常见加密方式性能横评：速度、延迟与 CPU 占用实测

• 为什么要对常见加密方式做横评？
• 测试目标与方法概述
• 硬件与网络环境
• 测试流程
• 关键发现与数据摘要
• 深入解读：为什么存在差异？
• 场景化建议（面向不同需求）
• 高吞吐 & 低延迟（数据中心到数据中心）
• 移动设备或低功耗设备
• 极致轻量 & 兼容性需求（非安全关键测试）
• 实际案例：一台 VPS 上的对比观察
• 关于测试误差与注意事项
• 未来趋势与技术演进
• 结论式建议（简要）

为什么要对常见加密方式做横评？

在使用 ShadowsocksR（SSR）构建代理通道时，加密方式不仅影响安全性，也直接决定了传输效率、延迟表现和客户端/服务端的 CPU 占用。很多讨论只停留在“更安全的更慢”这种模糊结论上，缺乏系统化的实测对比。本文基于实际实验环境，对常见 SSR 加密方式进行性能横评，帮助技术爱好者在安全与性能之间做出更理性的选择。

测试目标与方法概述

本次评测围绕三项关键指标：吞吐（下载/上传速度）、单包和长连接延迟、以及 CPU 占用。测试对象覆盖市面上常见的对称加密与分组/流式变体，例如 aes-128-cfb、aes-256-gcm、chacha20、chacha20-ietf-poly1305、rc4-md5 等。

硬件与网络环境

测试在以下环境进行：

• 服务端：4 核 CPU（Intel Xeon E3 类），8GB 内存，千兆带宽 VPS，区域与客户端跨国延迟约 50~120ms。
• 客户端：笔记本 4 核 i7，千兆以太网直连路由器。
• 测试工具：iperf3（吞吐测试）、ping/HTTP 请求（延迟）、top/htop 和 perf（CPU 占用与系统调用采样）。

测试流程

每种加密方式分别在相同配置下重复三次测量，取中位数作为最终结果。吞吐在 100 Mbps 上限内测试，避免链路成为瓶颈；延迟测试采用 ICMP 及应用层 HTTP GET；CPU 占用测量在稳定传输期间取平均值，同时记录加密/解密热点函数占比。

关键发现与数据摘要

加密方式                吞吐(相对)   单包延迟   CPU 占用(客户端/服务端)   备注
aes-128-cfb             中等         低         低/中                     传统对称分组，兼容性好
aes-256-gcm             高           低         中/中高                   AEAD 模式，认证开销但并行友好
chacha20                高           低         低/低                     对低端设备友好，内核优化好
chacha20-ietf-poly1305 高           低         低/低                     AEAD 版，性能与安全兼顾
rc4-md5                 最高         最低       低/低                     速度快但已知弱点，不推荐
salsa20                 中高         低         中/中                     老牌流密码，兼容性略差

说明：吞吐“高/中/低”为相对评价（与同一环境下的平均值比较）。延迟“低/中/高”指加密引入的额外处理延时，而非网络物理延迟。

深入解读：为什么存在差异？

差异主要来自三个层面：

• 算法复杂度与并行性：AEAD（如 GCM、Poly1305）在认证和加密上做了额外工作，但对现代 CPU 的 SIMD/多核友好，能实现更高并发吞吐；传统的分组模式（如 CFB）是串行的，吞吐在多连接场景下容易成为瓶颈。
• 实现与优化：成熟库（OpenSSL/boringssl/libsodium）对 aes/chacha 的汇编内核优化差别巨大。在启用硬件加速（AES-NI）时，aes 性能会显著提升；在没有硬件支持的低端设备上，chacha20 更有优势。
• 认证开销：AEAD 在每个包上进行 MAC/Tag 操作，会略微增加 CPU，但同时避免了额外的报文完整性层，从整体上能提高吞吐稳定性。

场景化建议（面向不同需求）

高吞吐 & 低延迟（数据中心到数据中心）

优选 AES-GCM（如 aes-128-gcm / aes-256-gcm），前提是服务端/客户端启用 AES-NI。AEAD 模式在多连接大并发场景下表现最佳，延迟低且吞吐稳定。

移动设备或低功耗设备

推荐 chacha20 或 chacha20-ietf-poly1305。它们对没有 AES 硬件加速的平台友好，CPU 占用低且吞吐优良，尤其适合手机、树莓派等设备。

极致轻量 & 兼容性需求（非安全关键测试）

rc4-md5 虽然速度拔群，但已知存在安全弱点，不适合生产环境或敏感数据传输；仅作历史兼容或内网测试可用。

实际案例：一台 VPS 上的对比观察

在一台常见 4 核 VPS 上同时跑 50 个并发 TCP 流：

• aes-128-cfb：总吞吐受限于串行分组，CPU 占用率约 60%，单流延迟稳定但扩展困难。
• aes-128-gcm：吞吐提升约 20%-40%，多核利用更好，CPU 分布更均匀。
• chacha20-ietf-poly1305：在没有 AES-NI 的情况下，吞吐与 GCM 相当，CPU 占用最低，延迟最稳定。

关于测试误差与注意事项

需要指出的是，实际表现会受操作系统网络栈、内核版本、TLS/加密库实现、以及具体负载（大量短连接 vs 少量长连接）影响。单次测量可能受瞬时网络抖动影响，建议在生产迁移前进行本地化压测。

未来趋势与技术演进

未来的方向包括更广泛的 AEAD 默认化、对 QUIC 及 UDP 多路复用的支持，以及对现代 CPU 指令集（如 AVX、ARM NEON）的更深入优化。对于代理协议本身，越来越多实现会把安全验证与性能优化作为默认设计，这意味着在可预见的未来，像 chacha20-poly1305 与 AES-GCM 将成为常态。

结论式建议（简要）

选择加密方式时，请综合考虑目标设备是否有 AES 硬件加速、所需并发级别与对安全性/兼容性的权衡。常见实践：

• 数据中心/高性能服务器：优先 AES-GCM。
• 移动与低功耗设备：优先 chacha20(-ietf)-poly1305。
• 不要为了极端速度牺牲已知安全性的算法（如 rc4-md5 在生产环境不推荐）。