所以; 在大多数情况下，Java的SSL实现并不是特别快捷。 当Java应用程序迁移到Solaris以利用其基于内核的SSL时，我已经看到博客展示了明显的加速。
对于提供板载加速器的Sun / Oracle（特别是基于SPARC的）硬件，这一切都很好，但是在Solaris安装在商品Intel盒上（或者甚至是VPS ）没有基于硬件的加速？
即KSSL在x86 Solaris机器上加速启用SSL的Java应用程序有多less？
请注意，x86可以从CPU获得一些SSL加速。 您可以通过运行cryptoadm list -mv来获取加速器cryptoadm list -mv 。 即使内核软件提供商也有一些优化。 这些提供者是运行KSSL的那些提供者。
要衡量差异运行以下例如：
/usr/sfw/bin/openssl speed rsa2048 /usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
第一个是纯软件，第二个是内核加速提供商可以作为PKCS11令牌访问。 在我的旧T1尼亚加拉，这两个人正在做8.4标志/秒，而19740.0标志/秒。 这肯定是巨大的差异。 现代x86 CPU可以加速AES，据我所知，它被用于软件内核提供商。 检查自己有什么区别。 更重要的是要有快速的不对称密码，因为它们在build立连接时使用，而且更多的CPU需要… Web应用程序经常closures连接。
顺便说一句KSSL其实只是在内核SSLencryption代理…它发生在内核的一个事实也有助于速度。
只是为了比较…在另一台机器上，〜与上面提到的T1年龄相同，但VMware中的x86对我来说是42.1 sign / s，对于rsa2048是98.6 sign / s。 速度超过一倍。
Solaris内核SSL代理提供了基于以下方面的性能改进：1.合并数据，以减less代理应用程序的read（）系统调用次数2.将encryption操作卸载到硬件encryption提供程序
与encryption操作卸载相比，第一点的改进可能要小得多。 第二点取决于KSSL处理的SSL会话的数量，stream量，客户端使用的底层硬件和密码套件，以及KSSL支持的密码套件。
在Solaris上的x86上，第二点当前仅对于支持AES-NI Intel指令集的计算机上基于AES的SSL / TLS密码套件可见。 这基本上是英特尔Westmere和以后。 Intel / AMD体系结构目前没有其他密码加速，因此仅适用于KSSL支持的两个密码套件：rsa_aes_256_cbc_sha和rsa_aes_128_cbc_sha。 鉴于这只是对称密码加速，它支付大量数据传输，而不是与less量数据的短期连接。
至于性能改进的量化，用openssl（1）速度testing将会提供一些提示，但是由于OpenSSL PKCS＃11引擎必须经过多层（OpenSSL引擎，PKCS＃11 metaslot，PKCS＃11内核/ dev / crypto API添加到内核），所以图层的开销可能会使测量偏差很大，特别是对于小数据大小。 KSSL只有一个非常薄的层（内核encryption框架API）可以通过，而且对于SSLlogging的实际处理没有系统调用的转换开销。