Existe uma maneira de dividir o processo de criptografia/descriptografia em vários núcleos com SFTP?

Existe uma maneira de dividir o processo de criptografia/descriptografia em vários núcleos com SFTP?

Estou em um caso em que o processo de criptografia em uma transferência SFTP maximiza um núcleo da CPU. No entanto, minha largura de banda de E/S (discos, barramentos e rede) está longe de atingir o limite máximo.

Dito isto, o sistema em questão tem múltiplos núcleos: gostaria de aproveitá-los no processo de criptografia/descriptografia.

Isso é possível? Se sim, como?

NB: se possível, eu gostaria de evitar conjuntos de patches com modificações não consideradas boas o suficiente para serem incluídas no upstream OpenSSH.

Responder1

Não. O protocolo SFTP não deixa muitas oportunidades de paralelização. Oprotocolo originalrequer algoritmos de cifra e MAC que não podem ser paralelizados dentro de um pacote. Suporte OpenSSHMCG, que pode ser paralelizado, mas o OpenSSH não tenta paralelizar dentro de um pacote. Embora o protocolo permita paralelizar o processamento de pacotes sucessivos, o OpenSSH não faz isso.

Por que o OpenSSH não paraleliza? Porque a paralelização é complicada de ser feita corretamente e só é benéfica para o desempenho em cenários específicos:

  • Na maioria dos cenários, a rede é o gargalo, portanto, a otimização do tempo de CPU é inútil.
  • Se o sistema estiver fazendo outras coisas (incluindo servir múltiplas conexões SSH em paralelo), a paralelização do processamento SSH será prejudicial ao desempenho de outros processos.
  • A paralelização tem um custo: a carga de trabalho deve ser transmitida aos processadores participantes e os dados devem ser montados quando todos os processadores terminarem. A sincronização tem um custo bastante elevado, portanto a paralelização só é benéfica se cada item de trabalho for suficientemente grande. Para SSH, é improvável que a paralelização dentro de um pacote seja benéfica.
  • Seria possível paralelizar o processamento de múltiplos pacotes, mas teria um enorme impacto no design do software: teria que haver uma interface complexa entre a camada de dados e a camada de criptografia, em vez de um simples streaming de dados.

O OpenSSH foi projetado com a segurança em mente, e a complexidade é inimiga da segurança, portanto, seria muito estranho considerar a paralelização. Outra pessoa fez isso:HPN-SSHé um conjunto de patches para OpenSSH que permite processamento paralelo. Ainda é mantido até hoje.

ARMv8 introduz aceleração de hardware para AES, SHA-1 e SHA-256. Se você tiver uma placa ARMv8 (esteja você executando um sistema de 32 ou 64 bits), certifique-se de que sua biblioteca de criptografia (OpenSSL para OpenSSH) seja compilada com aceleração ARMv8. Alguns pré-ARMv8 possuem aceleração de criptografia proprietária que pode serexposto pelo kernel Linux, mas o OpenSSL não suporta isso imediatamente (existem patches de kernel e OpenSSL, mas eles têm um histórico de falta de manutenção).

Se não quiser usar os patches HPN, você pode paralelizar acima da camada SSH. Se você tiver muitos arquivos pequenos para transferir, copie-os em lotes e paralelize-os. Se você tiver um arquivo grande para transferir, copie-o em partes e paralelize-as.

informação relacionada