Entonces; La implementación de SSL de Java no es particularmente rápida en la mayoría de las circunstancias. Heblogs vistoslo que demuestra notables aceleraciones cuando una aplicación Java se traslada a Solaris para aprovechar su SSL basado en Kernel.
Eso está muy bien en el hardware Sun/Oracle (especialmente basado en SPARC) que proporciona aceleradores integrados, pero ¿hay algún material sobre cómo funcionaría una aplicación Java cuando la instalación de Solaris se realiza en una caja Intel básica (o incluso en un VPS)? ) sin aceleración basada en hardware?
es decir, ¿cuánto acelera KSSL una aplicación Java habilitada para SSL en una caja Solaris x86?
Respuesta1
Tenga en cuenta que x86 puede obtener cierta aceleración para SSL desde la CPU. Puede obtener una lista de aceleradores ejecutando cryptoadm list -mv. Incluso el proveedor de software del kernel tiene algunas optimizaciones. Esos proveedores son los mismos que ejecutan KSSL.
Para medir la diferencia ejecute lo siguiente, por ejemplo:
/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
El primero es software puro y el segundo es un proveedor acelerado por kernel accesible como token PKCS11. Exactamente esos dos en mi antiguo T1 Niagara están haciendo 8,4 signos/s frente a 19740,0 signos/s. Sin duda, esa es una gran diferencia. Las CPU x86 modernas pueden acelerar AES, por ejemplo, y hasta donde yo sé, se utiliza en el proveedor del kernel de software. Comprueba tú mismo cuál es la diferencia. Más importante es tener cifrados asimétricos rápidos, porque se utilizan durante el establecimiento de una conexión y consumen más CPU... las aplicaciones web cierran la conexión con frecuencia.
Por cierto, KSSL está, de hecho, solo en el proxy de cifrado SSL del kernel... un hecho que sucede en el kernel también contribuye a la velocidad.
Solo para comparar... en otra máquina, ~ la misma edad que T1 mencionada anteriormente, pero x86 en VMware me está dando 42,1 signos/s frente a 98,6 signos/s para rsa2048. Así que se duplicó la velocidad.
Respuesta2
El proxy SSL del kernel de Solaris ofrece mejoras de rendimiento basadas en: 1. fusionar datos para que se requieran menos llamadas al sistema read() de la aplicación proxy 2. descargar operaciones criptográficas a proveedores de cifrado de hardware
La mejora del primer punto es probablemente mucho menor en comparación con la descarga de operaciones criptográficas. El segundo punto depende de la cantidad de sesiones SSL manejadas por KSSL, la cantidad de tráfico, el hardware subyacente y los conjuntos de cifrado utilizados por los clientes y respaldados por KSSL.
En x86 en Solaris, el segundo punto actualmente es visible solo para conjuntos de cifrado SSL/TLS basados en AES en máquinas que admiten el conjunto de instrucciones Intel AES-NI. Esto es básicamente Intel Westmere y posteriores. Actualmente, ningún otro cifrado está acelerado en las arquitecturas Intel/AMD, por lo que esto solo es válido para 2 conjuntos de cifrado compatibles con KSSL: rsa_aes_256_cbc_sha y rsa_aes_128_cbc_sha. Dado que se trata únicamente de aceleración de cifrado simétrico, se paga más por transferencias de datos masivas que por conexiones de corta duración con pequeñas cantidades de datos.
En cuanto a la cuantificación de la mejora del rendimiento, probar esto con la velocidad de openssl(1) proporcionará algunas pistas, pero se debe tener cuidado ya que el motor OpenSSL PKCS#11 tiene que atravesar múltiples capas (motor OpenSSL, metaranura PKCS#11, kernel PKCS#11/ dev/crypto API al kernel) por lo que la sobrecarga de las capas puede sesgar bastante las mediciones, especialmente para tamaños de datos pequeños. KSSL solo tiene una capa muy delgada (Kernel Crypto Framework API) por la que pasar y no hay sobrecarga de transición de llamada al sistema para el procesamiento real de registros SSL.