所以;在大多數情況下，Java 的 SSL 實作並不是特別快。我有看過的博客當 Java 應用程式遷移到 Solaris 以利用其基於核心的 SSL 時，展示了顯著的加速。
這對於提供板載加速器的Sun/Oracle（尤其是基於SPARC 的）硬體來說一切都很好，但是是否有任何資料說明當Solaris 安裝在商用Intel 機器（甚至是VPS）上時Java 應用程式將如何執行）沒有基於硬體的加速？
即，KSSL 可以在 x86 Solaris 機器上使啟用 SSL 的 Java 應用程式加速多少？
答案1
請注意，x86 可以從 CPU 獲得一些 SSL 加速。您可以透過運行來獲取加速器列表cryptoadm list -mv。甚至內核軟體供應商也有一些優化。這些提供者與執行 KSSL 的提供者相同。
若要測量差異，請執行以下範例：
/usr/sfw/bin/openssl speed rsa2048
/usr/sfw/bin/openssl speed rsa2048 -engine pkcs11
第一個是純軟體，第二個是可作為 PKCS11 令牌存取的核心加速提供者。正是我的舊 T1 Niagara 上的那兩個執行 8.4 符號/秒與 19740.0 符號/秒。這肯定是巨大的差異。例如，現代 x86 CPU 可以加速 AES，據我所知，它在軟體核心提供者中使用。你自己檢查一下有什麼區別。更重要的是擁有快速的非對稱密碼，因為它們在建立連接期間使用並且更需要 CPU...Web 應用程式經常關閉連接。
順便說一句，KSSL 實際上只是在核心 SSL 加密代理中...事實上它發生在內核中也有助於速度。
只是為了比較......在另一台機器上，~與上面提到的 T1 相同，但 VMware 中的 x86 為我提供了 42.1 個符號/秒，而 rsa2048 為 98.6 個符號/秒。所以速度提高了一倍以上。
答案2
Solaris 核心 SSL 代理基於以下方面提供效能改進： 1. 合併數據，以便需要更少的代理應用程式的 read() 系統呼叫 2. 將加密操作卸載到硬體加密提供程序
與加密操作卸載相比，第一點的改進可能要小得多。第二點取決於 KSSL 處理的 SSL 會話數量、流量、用戶端使用並由 KSSL 支援的底層硬體和密碼套件。
在 Solaris 上的 x86 上，第二點目前僅對於支援 AES-NI Intel 指令集的電腦上基於 AES 的 SSL/TLS 密碼套件可見。這基本上是 Intel Westmere 及更高版本。目前沒有其他密碼在 Intel/AMD 架構上加速，因此這僅對 KSSL 支援的 2 個密碼套件有效：rsa_aes_256_cbc_sha 和 rsa_aes_128_cbc_sha。鑑於這只是對稱密碼加速，它為大量資料傳輸支付更多費用，而不是為少量資料的短暫連線支付更多費用。
至於效能改進的量化，使用 openssl(1) 速度進行測試將提供一些提示，但應小心，因為 OpenSSL PKCS#11 引擎必須遍歷多個層（OpenSSL 引擎、PKCS#11 元插槽、PKCS#11 核心/ dev/crypto API 到核心），因此層的開銷可能會嚴重影響測量結果，特別是對於小資料量。 KSSL 只需要經過一層非常薄的層（核心加密框架 API），並且實際處理 SSL 記錄時沒有系統呼叫轉換開銷。