IPsec 吞吐量低于预期？先检查活动 SA
一长串转换算法并不等于正在保护你传输的那个会话。在归咎于加密之前，先记录协商出的 SA、载荷大小和实际交付速率。
配置里列出了八种转换算法，有人读到最强的那一个，就把吞吐量数字归到它头上。隧道很可能并没有选那个转换算法，也没有跑任何人想象中的那种负载。真正协商出来的是那份列表里的一条，带着一个包大小、一个方向、一个构建版本。测一测它，关于算法的争论通常还没开始就结束了。
症状：数字低于配置所承诺的水平
一长串转换算法描述的是可能性，而每种可能性都在纸面上评分，不是在这台硬件上。协商结果是一个双方都接受的唯一组合，它可能是任何一方为了兼容性仍然允许的最弱组合。这个组合能达到什么，取决于卸载状态、包大小和队列行为，所以两台策略文件完全相同的设备可能相差很远。列表是菜单；关联才是真正回来的那张订单。
读列表只能告诉你可能选了什么。读关联才能告诉你到底是什么在承载传输，而吞吐量数字描述的只是它。任何从列表出发的调优步骤，都是附带额外文书工作的猜测。
记录承载这次传输的关联
在 ASA 上 show crypto ipsec sa 会列出活动关联及其转换算法和每个方向的计数器，而 命令参考 记录了该输出。选定真正重要的对端和方向，并注意重新协商密钥会替换关联并重置计数器，这会悄悄作废你仍然信赖的基线。把输出和测试笔记存在一起，下一次运行才有可比对的东西。关联标识符如果在多次运行之间漂移，之后的所有比较都会失去意义。
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
五行就足以让一次测量可复现，而每一行在缺失时都排除一种具体解释。它们都不是提案列表里的一项，因为列表说不出此刻是什么在保护你的字节。把表填一次，下一次事故就会从数据开始，而不是从新的算法争论开始。
接入链路那一行是人们最常忽略的，而它恰恰最常解释看起来像加密问题的差距。饱和的底层网络或路径上的限速器，会制造出和慢速引擎一样形状的症状。
用受控负载测量单个方向
从代表应用的局域网端点发起测试，而不是从网关本身发起，因为网关生成的探测可能遵循不同的本地策略。在加入第二条流之前先测一个方向，并记录提供的速率与接收方实际收到的量。限速 UDP 运行能把提供的负载与 TCP 的拥塞响应分开，而不限速的 UDP 发送端并不是中立的诊断。还要记录载荷长度，因为更大的数据报会同时改变包速率和封装开销。
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30用相同的载荷长度和时长把同一个测试跑两遍，因为单次运行无法把上限和糟糕的一分钟区分开。如果接收方报告的包数少于发送方发出的包数，丢包就是你的发现，而加密引擎只是几个候选之一。
在调任何东西之前先解释差距
把转发策略、队列丢弃、接口错误和资源限制与加密路径一起检查，因为单靠速率缺口永远无法定位 CPU。账目层次也要写清楚：外层隧道字节包含封装，重传会改变内层与外层计数的关系。把不相干的计数器逐字节对比，只会造出从未存在过的差异。
包大小值得单独做一次受控对比，而不是从旧例子里抄一个数字。TCP MSS 调整的是 TCP，对任意 UDP 数据报毫无影响，所以从旧文档里搬来的固定 1350 什么都测不出来。有意改变载荷长度，观察接收方报告什么。
只改一个变量并保持工作负载
当基线在窄带内重复之后，改一个受支持的变量，并重跑原来的应用任务。正是这一步把数字变成原因，也只有它才值得去动配置。重复同样的负载，而不是更友好的那种。
不要为了把合成数字做大而撤掉提案、削弱认证或关闭保护。那些动作改变的是安全姿态，随后测到的是这次改变的结果，而不是隧道的能力。