我遇到的情况是，SFTP 传输中的加密过程会占用一个 CPU 核心。然而，我的 IO 带宽（磁盘、总线和网络）还远未达到最大。
话虽这么说，所讨论的系统有多个核心：我想在加密/解密过程中利用它们。
那可能吗？如果是这样，怎么办？
注意：如果可能的话，我想避免修改后的补丁集不足以包含在上游中OpenSSH。
答案1
不会。SFTP 协议没有为并行化留下很多机会。这原始协议需要无法在数据包内并行化的密码和 MAC 算法。 OpenSSH 支持气相色谱法，可以并行化，但 OpenSSH 不会尝试在数据包内并行化。尽管该协议允许并行处理连续的数据包，但 OpenSSH 并没有这样做。
为什么 OpenSSH 不并行化？因为并行化正确执行起来很复杂，并且只在特定场景下对性能有益：
- 在大多数情况下，网络是瓶颈，因此优化 CPU 时间是没有意义的。
- 如果系统正在执行其他操作（包括并行服务多个 SSH 连接），则并行 SSH 处理会损害其他进程的性能。
- 并行化是有代价的：工作负载必须传输到参与的处理器，并且必须在所有处理器完成后组装数据。同步的成本相当高，因此只有每个工作项足够大时并行化才有用。对于 SSH，数据包内的并行化不太可能有好处。
- 并行处理多个数据包是可能的，但这会对软件的设计产生巨大影响：数据层和加密层之间必须有一个复杂的接口，而不是简单的数据流。
OpenSSH 在设计时就考虑到了安全性，而复杂性是安全性的敌人，因此即使考虑并行化也是非常不符合其特性的。不过，也有人这么做了：HPN-SSH是一组允许并行处理的 OpenSSH 补丁。直到今天它仍然被维护着。
ARMv8 引入了 AES、SHA-1 和 SHA-256 的硬件加速。如果您有 ARMv8 板（无论您运行的是 32 位还是 64 位系统），请确保您的加密库（OpenSSL for OpenSSH）是使用 ARMv8 加速进行编译的。一些 ARMv8 之前的版本具有专有的加密加速，这可能是由Linux内核暴露，但 OpenSSL 不支持开箱即用（已经有内核和 OpenSSL 补丁，但它们有停止维护的历史）。
如果您不想使用 HPN 补丁，那么您可以在 SSH 层之上进行并行化。如果您有许多小文件要传输，请分批复制它们并并行化批次。如果您有一个大文件要传输，请将其分块复制并并行化这些块。