[AIX Solaris HP-UX Linux Windows][IBM i]

Secure Sockets Layer のパフォーマンス・ヒント

このページを使用して、Secure Sockets Layer (SSL) のパフォーマンスに関するヒントを学習します。 パフォーマンスにおいては、一般に、機能とスピードが相反する関係にあることを考慮する必要があります。 通常、機能が多く、それに含まれる処理が多いほど、パフォーマンスは遅くなります。

SSL (Secure Sockets Layer) のパフォーマンスには、次の 2 つのタイプがあります。
  • ハンドシェーク
  • バルク暗号化/暗号化解除

SSL 接続の確立時には、SSL ハンドシェークが発生します。接続が確立されると、SSL は読み取り/書き込みごとにバルク暗号化および暗号化解除を実行します。 SSL ハンドシェークのパフォーマンス・コストは、バルク暗号化および暗号化解除よりもはるかに大きくなります。

SSL のパフォーマンスを向上させるには、個々の SSL 接続数およびハンドシェーク数を減らします。

接続数を減らすと、単純な Transmission Control Protocol/Internet Protocol (TCP/IP) 接続を通じた非セキュアな通信ばかりでなく、SSL 接続を通じたセキュアな通信についてもパフォーマンスが向上します。 個々の SSL 接続を減らす方法の 1 つに、 HTTP 1.1 をサポートするブラウザーを使用する方法があります。HTTP 1.1 にアップグレードできない場合は、個々の SSL 接続を減らすことができない可能性があります。

別の一般的なアプローチとして、2 つの WebSphere® Application Server コンポーネント間の接続数 (TCP/IP と SSL の両方) を減らす方法があります。アプリケーション・サーバーの HTTP トランスポートの構成が、Web サーバーのプラグインがアプリケーション・サーバーに対して新規接続を繰り返し再オープンしないようになっていることを確認するには、以下のガイドラインが役立ちます。
  • キープアライブの最大数が、最低でも Web サーバーのスレッドごとの要求の最大数 (または UNIX での IBM® HTTP Server の処理の最大数) と同じ大きさになっていることを確認してください。Web サーバーのプラグインが、アプリケーション・サーバーへの可能な限りすべての同時接続についてキープアライブ接続を取得できることを確認します。取得できないと、アプリケーション・サーバーは、単一の要求を処理するときに接続をクローズしてしまいます。 また、キープアライブ接続が Web コンテナーのスレッドを消費するのを防ぐために、 Web コンテナーのスレッド・プール内のスレッドの最大数を、キープアライブの最大数より大きくする必要があります。
    注: HTTP トランスポートは推奨されていません。 チャネル・ベースの構成についてキープアライブの最大値を設定する方法の説明については、HTTP トランスポート・チャネルの設定を参照してください。
  • キープアライブ接続ごとの要求の最大数を増やします。デフォルト値は 100 で、100 個の要求の後に、アプリケーション・サーバーがプラグインからの接続をクローズすることになります。その後に、プラグインは新しい接続を開く必要があります。 このパラメーターの目的は、アプリケーション・サーバーへの接続時や、 アプリケーション・サーバー内にスレッドをとどめておくために継続的な送信要求を阻止する際に、サービス妨害攻撃を防ぐことです。
  • システムが SSL ハンドシェークをいくつも実行する場合は、 ハードウェア・アクセラレーターを使用してください。

    WebSphere Application Server で現在サポートされているハードウェア・アクセラレーターを使用すると、SSL ハンドシェークのパフォーマンスは向上しますが、バルク暗号化と暗号化解除のパフォーマンスは向上しません。 Web サーバーの接続は短期間であるため、通常、アクセラレーターの使用は Web サーバーにとってメリットがあります。WebSphere Application Server における他の SSL 接続は、すべて長期間存続します。

    [IBM i]IBM Cryptographic Coprocessor の WebSphere Application Server での使用はサポートされていません。ただし、Apache で稼働する IBM HTTP Server for iSeries などの他の製品では、IBM Cryptographic Coprocessor を使用して SSL のパフォーマンスを向上させることができます。

  • より良いパフォーマンスを持つ代替の暗号スイートを使用してください。

    暗号スイートのパフォーマンスは、ソフトウェアとハードウェアでは異なります。暗号スイートのパフォーマンスがソフトウェアで良好であっても、ハードウェアでも良好とは限りません。アルゴリズムには、一般にハードウェアで非効率な ものもありますが (Data Encryption Standard (DES) や Triple-Strength DES (3DES) など)、特殊なハードウェアを使用すると、同じアルゴリズムでも効率良く実装できます。

    バルク暗号化/暗号化解除のパフォーマンスは、個々の SSL 接続に使用する暗号スイートの影響を受けます。以下のグラフは、それぞれの暗号スイートのパフォーマンスを示しています。 データを計算するテスト用ソフトウェアは、クライアント・ソフトウェアとサーバー・ソフトウェアの両方に対応している Java™ Secure Socket Extension (JSSE) で、暗号ハードウェアはサポートされていません。 テストには、接続を確立する時間を含 めずに、確立された接続を通じてデータを送信する時間だけを含めています。したがって、このデータから、長期間実行される 接続について、さまざまな暗号スイートの相対的な SSL パフォーマンスが明らかになります。

    接続を確立する前に、クライアントでは各テスト・ケースごとに暗号スイートを 1 つずつ使用可能にします。 接続が確立されると、クライアントは、クライアントがサーバーに 1 つの整数を書き込むのにかかる時間、およびサーバーがクライアントに指定のバイト数を書き戻す時間を計測します。データ量の違いが暗号スイートの相対的パフォーマンスに与える影響は、無視できる程度のものです。

    接続が確立されると、クライアントは、クライアントがサーバーに 1 つの整数を書き込むのにかかる時間、およびサーバーがクライアントに指定のバイト数を書き戻す時間を計測します。データ量が変動しても、暗号スイートの相対的なパフォーマンスへの影響は無視できます。

前記のデータを分析すると、以下のことが明らかになります。
  • バルク暗号化のパフォーマンスは、暗号スイート名の中の WITH より後ろの部分のみから影響を受ける。これは、WITH より前の部分は、SSL ハンドシェーク中にのみ使用されるアルゴリズムを表すためです。
  • MD5 および Secure Hash Algorithm SHA は、データ保全性を提供するために使用する 2 つのハッシュ・アルゴリズムである。通常、MD5SHA よりも高速ですが、SHA のほうが MD5 よりもセキュアです。
  • DES および RC2RC4 よりも低速です。 Triple DES が最もセキュアですが、ソフトウェアのみの使用ではパフォーマンス・コストは高くなります。
  • プライバシー保護を保ちつつ最高のパフォーマンスを提供する暗号スイートは、SSL_RSA_WITH_RC4_128_MD5 である。SSL_RSA_EXPORT_WITH_RC4_40_MD5 の暗号機能は RSA_WITH_RC4_128_MD5 より劣るものの、バルク暗号化におけるパフォーマンスは同じです。このため、SSL 接続が長期間実行される接続であれば、セキュリティー・レベルが高の場合と中の場合のパフォーマンスの違いは無視できます。WebSphere Application Server 製品間だけで通信を行うすべてのコンポーネントについては、中レベルではなく、高レベルのセキュリティーを使用することをお勧めします。その接続が、長期的に実行される接続であることを確認してください。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_ssl
ファイル名:rprf_ssl.html