つまり、JavaのSSL実装は、ほとんどの状況では特に高速ではありません。見たブログJava アプリケーションを Solaris に移行してカーネルベースの SSL を活用すると、顕著な速度向上が見られることが実証されています。
オンボード アクセラレータを備えた Sun/Oracle (特に SPARC ベース) ハードウェアでは、これはすべて問題ありませんが、ハードウェア ベースのアクセラレーションのない一般的な Intel ボックス (または VPS) に Solaris がインストールされている場合、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
1 つ目は純粋なソフトウェアで、2 つ目は PKCS11 トークンとしてアクセス可能なカーネル アクセラレーション プロバイダーです。私の古い T1 Niagara では、これら 2 つは 8.4 署名/秒と 19740.0 署名/秒です。これは確かに大きな違いです。たとえば、最新の x86 CPU は AES を高速化でき、私の知る限り、ソフトウェア カーネル プロバイダーで使用されています。違いは自分で確認してください。より重要なのは、非対称暗号が高速であることです。これは、接続を確立するときに使用され、CPU を多く消費するためです。Web アプリケーションは頻繁に接続を閉じます。
ちなみに、KSSL は実際にはカーネル内の SSL 暗号化プロキシです。カーネル内で実行されるため、速度にも貢献します。
比較のため...別のマシンでは、上記の T1 とほぼ同じ年齢ですが、VMware の x86 では 42.1 サイン/秒であるのに対し、rsa2048 では 98.6 サイン/秒です。つまり、速度は 2 倍以上です。
答え2
Solaris カーネル SSL プロキシは、次の方法でパフォーマンスを向上させます。1. データを結合してプロキシ アプリケーションの read() システムコールの数を減らす 2. 暗号化操作をハードウェア暗号化プロバイダにオフロードする
最初のポイントの改善は、暗号化操作のオフロードと比較すると、おそらくはるかに小さいでしょう。2 番目のポイントは、KSSL によって処理される SSL セッションの数、トラフィックの量、基盤となるハードウェア、およびクライアントによって使用され KSSL によってサポートされている暗号スイートによって異なります。
Solaris 上の x86 では、2 番目のポイントは現在、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) が 1 つだけあり、SSL レコードの実際の処理にはシステム コール遷移のオーバーヘッドはありません。