加密吞吐受什么限制
IPsec 的加解密是实打实的计算：每个报文都要做加密与完整性校验。软件转发的设备上这部分工作落在 CPU 上，吞吐量直接受单核性能与核数影响，常见表现是大流量时某个核跑满而其他核空闲。带硬件加密引擎的平台会把这项工作卸载到专用芯片，CPU 占用相对平稳，但引擎本身也有吞吐上限，超过后仍会成为瓶颈。因此观察性能时分两步：先确认是软件还是硬件承载，再看具体瓶颈在哪里——是加解密、是转发路径，还是排队与调度。
基本信息
| 软件转发 | 加解密占用 CPU，吞吐受限明显 |
|---|---|
| 硬件加速 | 专用加密引擎处理，CPU 占用较低 |
| 观察指标 | 分核利用率、加密相关进程占用 |
| 算法影响 | 较新算法通常有更好的实现效率，但不绝对 |
| 密钥长度 | 越长计算量越大，需在安全与性能间平衡 |
| 测试方式 | 用打流工具实测而非理论估算 |
典型使用场景
- 大带宽隧道上线前评估设备能力是否足够
- 业务高峰出现丢包与卡顿：确认是否加解密成为瓶颈
- 算法选型：比较不同算法组合对吞吐的实际影响
- 容量规划：根据实测结果决定是否需要升级硬件
- 排障：区分是加密瓶颈还是链路或队列瓶颈
观察点
观察点
# Cisco：查看进程占用与平台吞吐等级
show processes cpu sorted | include Crypto|IPsec
show platform hardware throughput level
# Linux strongSwan：看 charon 线程占用
top -H -p $(pidof charon)
# 结合接口计数判断是否丢包
show interfaces GigabitEthernet0/0 | include rate|drop
# 打流验证真实吞吐
iperf3 -c 10.2.2.10 -t 60瓶颈定位对照
| 现象 | 倾向瓶颈 | 验证方式 |
|---|---|---|
| 单核跑满其他核空闲 | 软件加解密未并行 | 观察分核利用率 |
| 加解密进程占用高 | 算法或负载过重 | 更换算法组合再测 |
| CPU 不高但丢包 | 队列或链路带宽瓶颈 | 看接口与队列计数 |
| 隧道内带宽低于链路 | 加解密或封装开销 | 对比隧道内外打流结果 |
高吞吐场景建议直接实测：同样的算法在软件与硬件平台上差距可能很大，理论估算容易偏乐观。
隧道封装本身也有开销：MTU 减小使相同带宽下报文数增多，间接提高了加解密负担，容量评估时应一并计入。