¿Hay alguna manera de dividir el proceso de cifrado/descifrado en varios núcleos con SFTP?

¿Hay alguna manera de dividir el proceso de cifrado/descifrado en varios núcleos con SFTP?

Estoy en un caso en el que el proceso de cifrado en una transferencia SFTP maximiza un núcleo de CPU. Sin embargo, mi ancho de banda IO (discos, buses y red) está lejos de estar al máximo.

Dicho esto, el sistema en cuestión tiene múltiples núcleos: me gustaría aprovecharlos en el proceso de cifrado/descifrado.

¿Es eso posible? ¿Si es así, cómo?

NB: si es posible, me gustaría evitar conjuntos de parches con modificaciones que no se consideren lo suficientemente buenas como para incluirlas en upstream OpenSSH.

Respuesta1

No. El protocolo SFTP no deja muchas oportunidades de paralelización. Elprotocolo originalrequiere algoritmos de cifrado y MAC que no se pueden paralelizar dentro de un paquete. Soportes OpenSSHGCM, que se puede paralelizar, pero OpenSSH no intenta paralelizar dentro de un paquete. Aunque el protocolo permite paralelizar el procesamiento de paquetes sucesivos, OpenSSH no lo hace.

¿Por qué OpenSSH no se paraleliza? Porque la paralelización es complicada de realizar correctamente y solo es beneficiosa para el rendimiento en escenarios específicos:

  • En la mayoría de los escenarios, la red es el cuello de botella, por lo que optimizar el tiempo de CPU no tiene sentido.
  • Si el sistema está haciendo otras cosas (incluido servir múltiples conexiones SSH en paralelo), paralelizar el procesamiento SSH es perjudicial para el rendimiento de otros procesos.
  • Paralelizar tiene un coste: la carga de trabajo debe transmitirse a los procesadores participantes y los datos deben ensamblarse cuando todos los procesadores hayan terminado. La sincronización tiene un costo bastante alto, por lo que la paralelización solo es beneficiosa si cada elemento de trabajo es lo suficientemente grande. Para SSH, es poco probable que la paralelización dentro de un paquete sea beneficiosa.
  • Sería posible paralelizar el procesamiento de múltiples paquetes, pero tendría un enorme impacto en el diseño del software: tendría que haber una interfaz compleja entre la capa de datos y la capa de criptografía, en lugar de una simple transmisión de datos.

OpenSSH está diseñado teniendo en cuenta la seguridad, y la complejidad es enemiga de la seguridad, por lo que estaría muy fuera de lugar siquiera considerar la paralelización. Pero alguien más lo hizo:HPN-SSHes un conjunto de parches para OpenSSH que permiten el procesamiento paralelo. Todavía se mantiene a día de hoy.

ARMv8 introduce aceleración de hardware para AES, SHA-1 y SHA-256. Si tiene una placa ARMv8 (ya sea que esté ejecutando un sistema de 32 o 64 bits), asegúrese de que su biblioteca criptográfica (OpenSSL para OpenSSH) esté compilada con aceleración ARMv8. Algunas versiones anteriores a ARMv8 tienen aceleración criptográfica patentada que puede serexpuesto por el kernel de Linux, pero OpenSSL no admite esto de fábrica (ha habido parches para el kernel y OpenSSL, pero tienen un historial de falta de mantenimiento).

Si no desea utilizar los parches HPN, puede realizar la paralelización por encima de la capa SSH. Si tiene muchos archivos pequeños para transferir, cópielos en lotes y paralelice los lotes. Si tiene que transferir un archivo grande, cópielo en fragmentos y paralelice los fragmentos.

información relacionada