Webの表示速度を遅くする「SSLハンドシェイク」とは:現場にキく、Webシステムの問題解決ノウハウ(3)
本連載は、日立製作所が提供するアプリケーションサーバ「Cosminexus」の開発担当者へのインタビューを通じて、Webシステムにおける、さまざまな問題/トラブルの解決に効くノウハウや注意点を紹介していく。現在起きている問題の解決や、今後の開発のご参考に(編集部)
知っていますか? SSLハンドシェイク
Webアプリケーションで提供するWebページにSSLを適用した場合、SSLでは通信相手の認証/通信内容の暗号化などの負荷の高い処理が実行されるため、WebページのWebブラウザに表示される速度が遅くなることがある。この現象は、SSLセッションを再利用して、「SSLハンドシェイク」(上記の認証/暗号化を含んだ一連の処理)を簡略化することで、解決できる場合がある。
今回は、それらの問題を解決してWebブラウザの表示速度を向上させる方法について話をうかがったので、その内容を紹介する。
現象の見え方
今回は、以下の問題についての話だ。
Webアプリケーションで提供するWebページにSSLを適用した場合、Webブラウザ上への表示速度が遅い。
SSLを理解するのが、問題解決への最短距離
こういった現象は、読者も日常的に見ていることだろう。その原因を考えるうえで、とても基本的なことから確認してみたい。
SSLとは
SSLとは、インターネット/イントラネットで発生し得る「盗聴」「改ざん」「なりすまし」といったトラブルを防止するための技術だ。SSLでは、これらのトラブルを防止するために、アプリケーションデータを送受信する前に、SSLハンドシェイクと呼ばれる通信処理をWebブラウザ(クライアント)/Webサーバ間で実行する。SSLハンドシェイクでは主に、以下に示す処理を実行する。
SSLハンドシェイクでの問題点
SSLハンドシェイクの処理イメージを次の図に示そう。
- アプリケーションデータの暗号化に利用するアルゴリズムをクライアント/サーバ間で決定。
- CAから発行された証明書を利用して、クライアント/サーバの認証を行う証明書を利用して、クライアント/サーバの認証を行う
- 1.のアルゴリズムに基付き、暗号鍵を生成暗号鍵を生成
図1の赤い矢印の個所が上記のリスト1、2の処理に該当する。ここでは、アプリケーションデータの暗号化アルゴリズムを決定するための処理、および、証明書の送受信/証明書の検証によるクライアント/サーバ間の認証を実行するため、CPU処理時間と通信量を多く要するコストの高い処理になっており、SSLでの通信性能に最も影響する。
そのため、Webアプリケーションで提供するWebページにSSLを適用した場合、Webページのブラウザに表示される速度が遅くなることがあるという。
SSLセッション/アクセラレータを利用しよう
この問題の解決方法として、2つ考えられる。1つはSSLセッションを再利用する方法だ。
SSLセッションは、一度SSLハンドシェイクが完了した状態を意味し、一意の識別子(セッションID)で特定可能な情報だ。SSLセッションを再利用して、2回目以降のSSLハンドシェイクを簡略化することにより、アプリケーションデータの暗号化アルゴリズムを決定するための処理、および、証明書の送受信/証明書の検証によるクライアント/サーバ間の認証を省略できる。その結果、Webアプリケーションで提供するWebページにSSLを適用した場合のWebブラウザ上への表示速度を向上できる。
また、SSLアクセラレータを利用することにより、Webサーバに掛かっているSSL関連処理の負荷を軽減できる。
【1】SSLセッションを再利用する場合
現在多くのWebブラウザ、および、WebサーバではSSLセッションを再利用することにより、2回目以降のSSLハンドシェイクを簡略化し、SSLによる通信性能の向上を図ることが可能になっている。
例えばアプリケーションサーバとしてCosminexusを使っている場合、SSLセッションを再利用することにより、SSLハンドシェイクの中の以下の処理をスキップできるという。
- アプリケーションデータの暗号化に利用するアルゴリズムをクライアント/サーバ間で決定
- CAから発行された証明書を利用して、クライアント/サーバの認証を行う
SSLセッションを再利用する場合のSSLハンドシェイクの処理のイメージを次の図に示そう。
SSLセッションを再利用するためには、Hitachi Web Serverのコンフィグファイル(httpsd.conf)に以下に示す設定を行う必要があるという。なお、Windows版とUNIX版では、Hitachi Web Serverのプロセス構造が異なるため、設定方法が一部異なるそうだ。
- Windows版の場合
- SSLSessionCacheSize SSLセッションを管理するキャッシュのサイズ(単位:バイト)
- SSLSessionCacheTimeout SSLセッションの有効期間(単位:秒)
- UNIX版の場合
SSLセッションを管理するためのサーバ(gcacheサーバ)を利用して、SSLセッションを管理するため、Windows版と同様の設定に加えて、(gcacheサーバ)の設定を行う- SSLCacheServerPath gcacheサーバヘのパス名
- SSLCacheServerPort gcacheサーバのポート番号
【2】SSLアクセラレータを利用する場合
SSLアクセラレータとは、SSL関連の処理(SSLハンドシェイク、および、アプリケーションデータの暗号/復号)を高速化するための専用ハードウェアだ。SSLアクセラレータを利用することにより、Webサーバに掛かっているSSL関連処理の負荷を軽減できる。
SSLアクセラレータを利用した場合のシステム構成を次の図に示そう。
SSLを適用する場合、速度とのトレードオフを考慮
今回は、SSLセッションを再利用する/SSLアクセラレータを利用することで、SSLによる通信性能を向上させる手順について説明した。
Webアプリケーションで提供するWebページにSSLを適用する場合には、今回の説明内容を参考にして、SSLによる通信性能の向上を図るのは、いかがだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ApacheのSSL対応化と環境設定
- SSLによる安全なWebサイト作り
- 第1回 Webアプリの問題点を「見える化」する7つ道具
- 第2回 “Stop the World”を防ぐコンカレントGCとは?
- 第3回 【実録ドキュメント】そのログ本当に必要ですか?
- 第4回 DBアクセスのトラブルは終盤で発覚しがち……
- 第5回 OutOfMemoryエラー発生!? GCがあるのに、なぜ?
- 第6回 【真夏の夜のミステリー】Tomcatを殺したのは誰だ?
- 第7回 【トラブル大捜査線】失われたコネクションを追え!
- 第8回 肥え続けるTomcatと胃を痛めるトラブルハッカー
- 第9回 JavaのGC頻度に惑わされた年末年始の苦いメモリ
- 第10回 ThreadとHashMapに潜む無限回廊は実に面白い?
- 第11回 スレッドダンプの森で覚えた死のロックへの違和感
- 第12回 アプリ開発でも、よ?く考えよう。キャッシュは大事だよ
- 第13回 DB操作の“壁”を壊すJPAが起こした「赤壁の戦い」
- 第1回 クラスタ化すると遅くなる?
- 第2回 キャッシュが性能劣化をもたらす謎を解く
- 第3回 クラスタは何台までOK?
- 第4回 マルチスレッドのいたずらに注意
- 第5回 クラスタによるアプリケーションの動的アップデート
- 第6回 APサーバからの応答がなくなった、なぜ?
- 第7回 低負荷なのにCPU使用率が100%?
- 第8回 文字化け“???”の法則とその防止策
- 第9回 メモリは足りているのに“OutOfMemory”のなぞ
- 第10回 レスポンスキャッシュでパフォーマンス向上
- 第11回 JDBC接続を高速化?PreparedCacheの活用
- 第12回 ブラウザキャッシュでパフォーマンス向上
- 第13回 ファイルアップロード/ダウンロードに潜むわな
- Eclipse上でプロファイリングを実現する
- JMeterによるWebサーバ性能評価の勘所