Então; A implementação SSL do Java não é particularmente rápida na maioria das circunstâncias. Eu tenhovi blogsdemonstrando acelerações perceptíveis quando um aplicativo Java é movido para Solaris para aproveitar seu SSL baseado em kernel.
Tudo isso é muito bom no hardware Sun/Oracle (especialmente baseado em SPARC) que fornece aceleradores integrados, mas existe algum material sobre como um aplicativo Java funcionaria quando a instalação do Solaris está em uma caixa Intel comum (ou mesmo um VPS ) sem aceleração baseada em hardware?
ou seja, quanto o KSSL acelera um aplicativo Java habilitado para SSL em uma caixa Solaris x86?
Responder1
Observe que o x86 pode obter alguma aceleração para SSL da CPU. Você pode obter uma lista de aceleradores executando cryptoadm list -mv. Até o fornecedor de software kernel tem algumas otimizações. Esses provedores são os mesmos que executam o KSSL.
Para medir a diferença, execute o seguinte exemplo:
/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
O primeiro é software puro e o segundo é um provedor acelerado por kernel acessível como token PKCS11. Exatamente aqueles dois no meu antigo T1 Niagara estão fazendo 8,4 sinais/s contra 19.740,0 sinais/s. Essa é com certeza uma grande diferença. CPUs x86 modernas podem acelerar o AES, por exemplo, e até onde eu sei, ele é usado no provedor de kernel de software. Verifique você mesmo qual é a diferença. Mais importante é ter cifras assimétricas rápidas, porque elas são usadas durante o estabelecimento de uma conexão e consomem mais CPU... os aplicativos da Web fecham a conexão com frequência.
A propósito, KSSL está, na verdade, apenas no proxy de criptografia SSL do kernel ... um fato que acontece no kernel também contribui para a velocidade.
Só para comparar... em outra máquina, ~ mesma idade que T1 mencionado acima, mas x86 no VMware está fazendo para mim 42,1 sinais/s versus 98,6 sinais/s para rsa2048. Portanto, mais que dobrou a velocidade.
Responder2
O proxy SSL do kernel Solaris oferece melhorias de desempenho com base em: 1. união de dados para que sejam necessárias menos syscalls read() do aplicativo proxy 2. transferência de operações de criptografia para provedores de criptografia de hardware
A melhoria do primeiro ponto é provavelmente muito menor em comparação com o descarregamento da operação criptográfica. O segundo ponto depende do número de sessões SSL tratadas pelo KSSL, da quantidade de tráfego, do hardware subjacente e dos conjuntos de criptografia usados pelos clientes e suportados pelo KSSL.
No x86 no Solaris, o segundo ponto é atualmente visível apenas para conjuntos de criptografia SSL/TLS baseados em AES em máquinas que suportam o conjunto de instruções AES-NI Intel. Isto é basicamente Intel Westmere e posterior. Nenhuma outra cifra é atualmente acelerada em arquiteturas Intel/AMD, portanto isso é válido apenas para 2 conjuntos de cifras suportados por KSSL: rsa_aes_256_cbc_sha e rsa_aes_128_cbc_sha. Dado que se trata apenas de aceleração de cifra simétrica, compensa mais por transferências de dados em massa do que por conexões de curta duração com pequenas quantidades de dados.
Quanto à quantificação da melhoria de desempenho, testar isso com a velocidade do openssl(1) fornecerá algumas dicas, mas deve-se tomar cuidado, pois o mecanismo OpenSSL PKCS#11 precisa atravessar múltiplas camadas (mecanismo OpenSSL, metaslot PKCS#11, kernel PKCS#11/ dev/crypto API para o kernel) para que a sobrecarga das camadas possa distorcer bastante as medições, especialmente para tamanhos de dados pequenos. O KSSL possui apenas uma camada muito fina (API Kernel Crypto Framework) e não há sobrecarga de transição de syscall para o processamento real de registros SSL.