(57)【要約】【課題】暗号化して通信されたデータの平文でのキャッシュを可能とする。【解決手段】プロキシサーバ１０は、暗号化されたデータ取得要求と、データ２ａの平文の識別子とを含む、サーバ２宛ての第１リクエスト５を受信すると、識別子に対応するキャッシュデータが記憶部１１に格納されているか否かを判断する。プロキシサーバ１０は、キャッシュデータが格納されている場合、キャッシュデータを含む第１レスポンス５ａを第１リクエスト５の送信元に送信する。またプロキシサーバ１０は、キャッシュデータが格納されていない場合、データ２ａの取得を要求する第３リクエスト７をサーバ２に送信する。そしてプロキシサーバ１０は、第３リクエスト７に対する第３レスポンス７ａをサーバ２から受信すると、第３レスポンス７ａに含まれるデータ２ａを、識別子に対応付けてキャッシュデータとして記憶部１１に格納する。【選択図】図１
2020057259.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
サーバ内のデータの取得を要求する暗号化されたデータ取得要求と、前記データの平文の識別子とを含む、前記サーバ宛ての第１リクエストを受信すると、前記識別子に対応するキャッシュデータが記憶部に格納されているか否かを判断し、
前記キャッシュデータが前記記憶部に格納されている場合、前記キャッシュデータを含む第１レスポンスを前記第１リクエストの送信元に送信し、
前記キャッシュデータが前記記憶部に格納されていない場合、前記第１リクエストから前記識別子を削除した第２リクエストを前記サーバに送信するとともに、前記データの取得を要求する第３リクエストを前記サーバに送信し、
前記第２リクエストに対する第２レスポンスを前記サーバから受信すると、前記第２レスポンスを前記第１リクエストの送信元に転送し、
前記第３リクエストに対する第３レスポンスを前記サーバから受信すると、前記第３レスポンスに含まれる前記データを、前記識別子に対応付けて前記キャッシュデータとして前記記憶部に格納する、
処理をコンピュータに実行させるキャッシュ制御プログラム。
【請求項２】
前記第３リクエストの送信の際には、暗号化通信により前記第３リクエストを送信し、
前記第３レスポンスの受信の際には、暗号化通信により前記第３レスポンスを受信し、前記第３レスポンスに含まれる暗号化された前記データを復号し、復号後の前記データを前記識別子に対応付けて前記記憶部に格納する、
請求項１記載のキャッシュ制御プログラム。
【請求項３】
前記第１レスポンスの送信の際には、前記第１レスポンス内の前記キャッシュデータが平文であることを示す情報を前記第１レスポンスに含める、
請求項１または２記載のキャッシュ制御プログラム。
【請求項４】
コンピュータが、
サーバ内のデータの取得を要求する暗号化されたデータ取得要求と、前記データの平文の識別子とを含む、前記サーバ宛ての第１リクエストを受信すると、前記識別子に対応するキャッシュデータが記憶部に格納されているか否かを判断し、
前記キャッシュデータが前記記憶部に格納されている場合、前記キャッシュデータを含む第１レスポンスを前記第１リクエストの送信元に送信し、
前記キャッシュデータが前記記憶部に格納されていない場合、前記第１リクエストから前記識別子を削除した第２リクエストを前記サーバに送信するとともに、前記データの取得を要求する第３リクエストを前記サーバに送信し、
前記第２リクエストに対する第２レスポンスを前記サーバから受信すると、前記第２レスポンスを前記第１リクエストの送信元に転送し、
前記第３リクエストに対する第３レスポンスを前記サーバから受信すると、前記第３レスポンスに含まれる前記データを、前記識別子に対応付けて前記キャッシュデータとして前記記憶部に格納する、
キャッシュ制御方法。
【請求項５】
データの識別子に対応付けて前記データのキャッシュデータを記憶する記憶部と、
サーバ内の取得対象データの取得を要求する暗号化されたデータ取得要求と、前記取得対象データの平文の取得対象データ識別子とを含む、前記サーバ宛ての第１リクエストを受信すると、前記取得対象データ識別子に対応する対応キャッシュデータが前記記憶部に格納されているか否かを判断し、前記対応キャッシュデータが前記記憶部に格納されている場合、前記対応キャッシュデータを含む第１レスポンスを前記第１リクエストの送信元に送信し、前記対応キャッシュデータが前記記憶部に格納されていない場合、前記第１リクエストから前記取得対象データ識別子を削除した第２リクエストを前記サーバに送信するとともに、前記取得対象データの取得を要求する第３リクエストを前記サーバに送信し、前記第２リクエストに対する第２レスポンスを前記サーバから受信すると、前記第２レスポンスを前記第１リクエストの送信元に転送し、前記第３リクエストに対する第３レスポンスを前記サーバから受信すると、前記第３レスポンスに含まれる前記取得対象データを、前記取得対象データ識別子に対応付けて前記対応キャッシュデータとして前記記憶部に格納する処理部と、
を有するプロキシサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キャッシュ制御プログラム、キャッシュ制御方法、およびプロキシサーバに関する。
【背景技術】
【０００２】
イントラネット内の端末装置からインターネット上のサーバへのアクセスは、例えば、プロキシサーバを介して行われる。プロキシサーバは、イントラネットとインターネットとの間で通信されるパケットを中継する。
【０００３】
パケットを中継する際、プロキシサーバは、イントラネット内の端末装置がインターネット上のサーバから取得したデータをキャッシュすることができる。プロキシサーバがデータをキャッシュした後、同じデータの取得を要求するリクエストがイントラネット内の端末装置から出力される場合がある。この場合、プロキシサーバは、そのリクエストをインターネット上のサーバに送信するのに代えて、キャッシュしてあるデータ（キャッシュデータ）を端末装置に応答する。これにより、端末装置によるインターネット上のサーバで提供されるデータの取得処理を効率化できる。
【０００４】
例えば、イントラネット内の複数の端末装置それぞれがインターネット上のサーバで提供される同じデータを取得する場合がある。この場合、最初にサーバにアクセスした端末装置に転送したデータをプロキシサーバでキャッシュしておく。そしてプロキシサーバは、他の端末装置がサーバにアクセスした際には、キャッシュしたデータを該当端末装置に送信する。これにより、２台目以降の端末装置のサーバからのデータ取得処理が効率化される。
【０００５】
ネットワーク上の通信の効率化に関する技術としては、例えば、暗号化通信における通信データ量を削減するクライアント／サーバシステムが考えられている。また複数のサーバを対象として、各サーバと各クライアントとの間でデータを暗号化してやり取りする場合に、該暗号化されたデータを復号化したものを用いたデータ処理を行うことが可能なプロキシを有する情報提供システムも考えられている。さらに、ファイルタイプおよび応答タイプに応じて以降の要求がサフィックスプロキシによって取り扱われるようにＳａａＳ（Software as a Service）サーバ応答を処理するサフィックスプロキシも考えられている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−６３０３２号公報
【特許文献２】特開２００４−２０６５７３号公報
【特許文献３】特表２０１７−５０４０９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
端末装置とサーバとの通信は、例えばＨＴＴＰＳ（Hypertext Transfer Protocol Secure）などの技術を用いて暗号化して行われることがある。暗号化された通信データ（暗号データ）は、通信を行っている端末装置とサーバのみが復号可能であり、プロキシサーバは復号することができない。そのためプロキシサーバは、中継した暗号データを、平文でキャッシュすることができない。なお暗号データのままプロキシサーバでキャッシュしたとしても、その暗号データをサーバから暗号化通信で取得した端末装置以外の端末装置では、キャッシュした暗号データを復号することができず、処理の効率化に役立てることができない。
【０００８】
１つの側面では、暗号化して通信されたデータの平文でのキャッシュを可能とすることを目的とする。
【課題を解決するための手段】
【０００９】
１つの案では、コンピュータに以下の処理を実行させるキャッシュ制御プログラムが提供される。
コンピュータは、サーバ内のデータの取得を要求する暗号化されたデータ取得要求と、データの平文の識別子とを含む、サーバ宛ての第１リクエストを受信すると、識別子に対応するキャッシュデータが記憶部に格納されているか否かを判断する。次にコンピュータは、キャッシュデータが記憶部に格納されている場合、キャッシュデータを含む第１レスポンスを第１リクエストの送信元に送信する。さらにコンピュータは、キャッシュデータが記憶部に格納されていない場合、第１リクエストから識別子を削除した第２リクエストをサーバに送信するとともに、データの取得を要求する第３リクエストをサーバに送信する。コンピュータは、第２リクエストに対する第２レスポンスをサーバから受信すると、第２レスポンスを第１リクエストの送信元に転送する。またコンピュータは、第３リクエストに対する第３レスポンスをサーバから受信すると、第３レスポンスに含まれるデータを、識別子に対応付けてキャッシュデータとして記憶部に格納する。
【発明の効果】
【００１０】
１態様によれば、暗号化して通信されたデータの平文でのキャッシュが可能となる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態に係るキャッシュ制御方法の一例を示す図である。
【図２】第２の実施の形態のシステム構成の一例を示す図である。
【図３】プロキシサーバのハードウェアの一構成例を示す図である。
【図４】キャッシュを伴う暗号化通信を実現するための機能を示すブロック図である。
【図５】キャッシュデータ記憶部内のデータの一例を示す図である。
【図６】暗号化通信用のパケットフォーマットの一例を示す図である。
【図７】プロキシサーバによるデータキャッシュの概要を示す図である。
【図８】データキャッシュを含む通信処理手順の一例を示すシーケンス図である。
【図９】ブラウザによる暗号化通信処理の手順の一例を示すフローチャートである。
【図１０】ＧＥＴ要求のリクエストの一例を示す図である。
【図１１】ＰＯＳＴ要求のリクエストの一例を示す図である。
【図１２】ＵＲＬ情報を含むリクエストのパケットの一例を示す図である。
【図１３】ＴＬＳパケット処理部によるパケット中継処理の手順の一例を示すフローチャートである。
【図１４】キャッシュ用データ取得処理の手順の一例を示すフローチャートである。
【図１５】データの有効期限付きのレスポンスの一例を示す図である。
【図１６】キャッシュデータを応答するパケットの一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るキャッシュ制御方法の一例を示す図である。図１には、キャッシュ制御方法を、プロキシサーバ１０を用いて実施した場合の例を示している。プロキシサーバ１０は、例えばキャッシュ制御方法の処理手順が記述されたキャッシュ制御プログラムを実行することにより、キャッシュ制御方法を実施することができる。
【００１３】
プロキシサーバ１０は、キャッシュ制御方法を実施するために、記憶部１１と処理部１２とを有する。記憶部１１は、例えばプロキシサーバ１０が有するメモリ、またはストレージ装置である。処理部１２は、例えばプロキシサーバ１０が有するプロセッサ、または演算回路である。
【００１４】
記憶部１１は、プロキシサーバ１０が中継した複数のデータのそれぞれの識別子に対応付けて、そのデータのキャッシュデータを記憶する。また記憶部１１は、サーバ２との暗号化通信用の鍵（第２鍵４ａ）を記憶する。
【００１５】
処理部１２は、プロキシサーバ１０で中継するデータをキャッシュする。図１の例では、プロキシサーバ１０は、イントラネットにより端末装置１に接続されていると共に、インターネットによりサーバ２に接続されている。そしてプロキシサーバ１０は、端末装置１とサーバ２との間の通信を中継する。この際、端末装置１とサーバ２とは暗号化通信を行う場合がある。処理部１２は、中継したデータが暗号化されていても、そのデータをキャッシュすることができる。
【００１６】
端末装置１とサーバ２とは暗号化通信を行う場合、例えば端末装置１とサーバ２とが連係して、端末装置１とサーバ２それぞれが、暗号化と復号に使用する同じ内容の第１鍵３ａ，３ｂを生成する。そして端末装置１とサーバ２とは、第１鍵３ａ，３ｂで暗号化した情報を通信する。サーバ２が有するデータ２ａを、端末装置１が取得する場合、以下の手順でデータ２ａの取得処理、および処理部１２によるデータのキャッシュ処理が行われる。
【００１７】
まず端末装置１は、サーバ２内のデータ２ａの取得を要求するデータ取得要求を暗号化し、暗号化したデータ取得要求とデータ２ａ（取得対象データ）の平文の識別子（取得対象データ識別子）とを含む、サーバ２宛ての第１リクエスト５を送信する（ステップＳ１）。データの識別子は、例えばデータの平文のＵＲＬ（Uniform Resource Locator）である。第１リクエスト５は、プロキシサーバ１０で中継される。
【００１８】
プロキシサーバ１０の処理部１２は、第１リクエスト５を受信すると、データの識別子に対応するキャッシュデータ（対応キャッシュデータ）が記憶部１１に格納されているか否かを判断する（ステップＳ２）。処理部１２は、該当するキャッシュデータが記憶部１１に格納されている場合、キャッシュデータを含む第１レスポンス５ａを第１リクエスト５の送信元である端末装置１に送信する（ステップＳ３）。この場合、平文のキャッシュデータが、端末装置１に送信される。このとき処理部１２は、第１レスポンス５ａ内のキャッシュデータが平文であることを示す情報を第１レスポンス５ａに含めてもよい。これにより、第１レスポンス５ａを受信した端末装置１は、キャッシュデータが平文であることを認識して、適切にデータ２ａを処理できる。すなわち端末装置１は、暗号化通信により送信した第１リクエスト５に対して平文のデータが応答された場合、暗号化通信におけるデータの復号処理をスキップし、受信したデータを復号後のデータとして扱うことができる。
【００１９】
処理部１２は、該当するキャッシュデータが記憶部１１に格納されていない場合、第１リクエスト５からデータ２ａの識別子を削除した第２リクエスト６をサーバ２に送信する（ステップＳ４）。データ２ａの識別子を削除したため、プロキシサーバ１０とサーバ２との間の通信経路上での、アクセス対象のデータ２ａの識別子の漏洩が抑止される。なおデータ取得要求内にもデータ２ａの識別子が含まれるが、データ取得要求は暗号化されているため、サーバ２以外、データ取得要求からデータ２ａの識別子を抽出することはできない。
【００２０】
第２リクエスト６を受信したサーバ２は、データ２ａを応答する。例えばサーバ２は、データ２ａを第１鍵３ｂで暗号化し、暗号化したデータ２ａを含む第２レスポンス６ａをプロキシサーバ１０に送信する（ステップＳ５）。
【００２１】
プロキシサーバ１０の処理部１２は、第２リクエスト６に対する第２レスポンス６ａをサーバ２から受信すると、第２レスポンス６ａを第１リクエスト５の送信元である端末装置１に転送する（ステップＳ６）。第２レスポンス６ａを受信した端末装置１は、第１鍵３ａにより第２レスポンス６ａ内のデータ２ａを復号する（ステップＳ７）。
【００２２】
また処理部１２は、該当するキャッシュデータが記憶部１１に格納されていない場合、データ２ａの取得を要求する第３リクエスト７をサーバ２に送信する（ステップＳ８）。例えば処理部１２とサーバ２とが連係して、処理部１２とサーバ２それぞれが、暗号化と復号に使用する同じ内容の第２鍵４ａ，４ｂを生成する。処理部１２は、生成した第２鍵４ａを、例えば記憶部１１に格納する。そして処理部１２は、サーバ２内のデータ２ａの取得を要求するデータ取得要求を第２鍵４ａで暗号化し、暗号化したデータ取得要求を含む第３リクエスト７を、サーバ２に送信する。なお処理部１２は、第３リクエスト７の送信は、第２リクエスト６の送信とは別のスレッドで、任意のタイミングで実行することができる。例えば処理部１２は、第２リクエスト６と第３リクエスト７とを同時に行ってもよい。また処理部１２は、第２リクエスト６に対する第２レスポンス６ａを転送後に、第３リクエスト７を送信してもよい。
【００２３】
第３リクエスト７を受信したサーバ２は、データ２ａを応答する。例えばサーバ２は、データ２ａを第２鍵４ｂで暗号化し、暗号化したデータ２ａを含む第３レスポンス７ａをプロキシサーバ１０に送信する（ステップＳ９）。
【００２４】
プロキシサーバ１０の処理部１２は、第３リクエスト７に対する第３レスポンス７ａをサーバ２から受信すると、第３レスポンス７ａに含まれるデータ２ａを、データ２ａの識別子に対応付けて、キャッシュデータとして記憶部１１に格納する。例えば処理部１２は、暗号化通信により第３レスポンス７ａを受信した場合、第３レスポンス７ａに含まれる暗号化されたデータ２ａを、第２鍵４ａで復号し、復号後のデータ２ａを識別子に対応付けて記憶部１１に格納する（ステップＳ１０）。
【００２５】
このようにして、端末装置１が暗号化通信によりサーバ２から取得したデータ２ａを、プロキシサーバ１０において平文でキャッシュすることができる。その結果、サーバ２からの暗号化通信によるデータ取得の処理効率が向上する。
【００２６】
特に最近は、銀行のオンライン取引を行う場合のような極めて高い安全性が求められる通信に限らず、一般的な通信についても常時暗号化通信を行うことが増えている。常時暗号化通信を行うことで、例えば、ユーザの気づかないところで、重要なデータが重要性の低いデータ内に紛れ込んでいる場合であっても、重要なデータの漏洩を抑止できる。また、１つ１つの通信は重要ではないが、複数の通信を組み合わせて解析することで重要な情報を取り出せる場合がある。そのため、個々の通信が重要とは言えなくても、すべての通信を暗号化することで重要な情報の漏洩を抑止できる。このように常時暗号化通信を行う通信形態が多くなるほど、暗号化通信で取得されたデータをプロキシサーバ１０でキャッシュすることによる処理の効率化が重要となる。
【００２７】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。
図２は、第２の実施の形態のシステム構成の一例を示す図である。Ｗｅｂサーバ３１が接続されたインターネット３２と、端末装置２００，３００が接続されたイントラネット３３との間に、プロキシサーバ１００が配置されている。Ｗｅｂサーバ３１は、様々なデータを公開している。端末装置２００，３００は、Ｗｅｂサーバ３１にアクセスし、Ｗｅｂサーバ３１が公開しているデータを取得する。
【００２８】
プロキシサーバ１００は、端末装置２００，３００それぞれとＷｅｂサーバ３１との通信を中継する。またプロキシサーバ１００は、データのキャッシュ機能を備えている。例えばプロキシサーバ１００は、Ｗｅｂサーバ３１からいずれかの端末装置へ送信されたデータをキャッシュし、キャッシュデータを保持する。そしてプロキシサーバ１００は、端末装置２００，３００のいずれかからＷｅｂサーバ３１へ、キャッシュデータと同じデータの取得を要求するリクエストが出力されると、そのリクエストを送信した端末装置へキャッシュデータを送信する。なおプロキシサーバ１００は、端末装置２００，３００とＷｅｂサーバ３１との間で暗号化通信が行われた場合にも、通信された暗号データに対応する平文のデータをキャッシュすることができる。
【００２９】
図３は、プロキシサーバのハードウェアの一構成例を示す図である。プロキシサーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【００３０】
メモリ１０２は、プロキシサーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
【００３１】
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８ａ，１０８ｂがある。
【００３２】
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
【００３３】
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。
【００３４】
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００３５】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００３６】
機器接続インタフェース１０７は、プロキシサーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
【００３７】
ネットワークインタフェース１０８ａは、イントラネット３３に接続されている。ネットワークインタフェース１０８ａは、イントラネット３３を介して、端末装置２００，３００との間でデータの送受信を行う。
【００３８】
ネットワークインタフェース１０８ｂは、インターネット３２に接続されている。ネットワークインタフェース１０８ｂは、インターネット３２を介して、Ｗｅｂサーバ３１との間でデータの送受信を行う。
【００３９】
プロキシサーバ１００は、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。Ｗｅｂサーバ３１および端末装置２００，３００も、プロキシサーバ１００と同様のハードウェア構成により実現することができる。また、第１の実施の形態に示したプロキシサーバ１０、端末装置１、およびＷｅｂサーバ２も、図３に示したプロキシサーバ１００と同様のハードウェアにより実現することができる。
【００４０】
プロキシサーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。プロキシサーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、プロキシサーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またプロキシサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００４１】
以下、暗号データに対応する平文のデータをプロキシサーバ１００にキャッシュすることができる通信方式について、詳細に説明する。
図４は、キャッシュを伴う暗号化通信を実現するための機能を示すブロック図である。図４の例は、端末装置２００，３００内のブラウザ２１０，３１０がＷｅｂサーバ３１から暗号化通信によりデータを取得する場合を想定している。
【００４２】
端末装置２００，３００それぞれは、ブラウザ２１０，３１０を有している。ブラウザ２１０，３１０は、それぞれ暗号化通信部２１１，３１１を有している。各ブラウザ２１０，３１０は、自身の暗号化通信部２１１，３１１により、Ｗｅｂサーバ３１との間で、例えばＨＴＴＰＳにより暗号化通信を行うことができる。ＨＴＴＰＳでは、暗号化通信のプロトコルとしてＴＬＳ（Transport Layer Security）が用いられる。暗号化通信部２１１，３１１は、暗号化通信により、Ｗｅｂサーバ３１にデータの取得要求を送信する場合、送信パケットに取得するデータの平文の識別子（ＵＲＬ）を付与する。
【００４３】
プロキシサーバ１００は、キャッシュデータ記憶部１１０、ＴＬＳパケット処理部１２０、およびキャッシュ用データ取得部１３０を有する。
キャッシュデータ記憶部１１０は、平文のキャッシュデータを記憶する。例えばプロキシサーバ１００のメモリ１０２またはストレージ装置１０３の記憶領域の一部が、キャッシュデータ記憶部１１０として使用される。
【００４４】
ＴＬＳパケット処理部１２０は、ＴＬＳによって暗号化されたデータ通信用のパケットの中継処理を行う。例えばＴＬＳパケット処理部１２０は、データの取得要求を含むパケットを端末装置２００，３００のいずれかから受信すると、そのパケットから、取得するデータの位置を示す平文のＵＲＬを抽出する。そしてＴＬＳパケット処理部１２０は、抽出したＵＲＬに基づいて、取得するデータに対応するキャッシュデータの有無を判断する。ＴＬＳパケット処理部１２０は、取得するデータに対応するキャッシュデータがあれば、キャッシュデータ記憶部１１０から該当するキャッシュデータを読み出し、端末装置に送信する。またＴＬＳパケット処理部１２０は、取得するデータに対応するキャッシュデータがなければ、受信したパケットから取得するデータの平文のＵＲＬを削除し、ＵＲＬを削除したパケットをＷｅｂサーバ３１に送信する。取得するデータに対応するキャッシュデータがない場合、ＴＬＳパケット処理部１２０は、さらに、キャッシュ用データ取得部１３０に、該当するデータのキャッシュを指示するキャッシュ要求を送信する。
【００４５】
キャッシュ用データ取得部１３０は、キャッシュ要求に従って、Ｗｅｂサーバ３１からデータを取得する。そしてキャッシュ用データ取得部１３０は、取得したデータを、そのデータの取得元のＵＲＬと関連付けて、キャッシュデータとしてキャッシュデータ記憶部１１０に格納する。なおキャッシュ用データ取得部１３０は、ＴＬＳパケット処理部１２０とは別のスレッドで実行される。そしてキャッシュ用データ取得部１３０は、キャッシュ要求に応じたデータのキャッシュ処理を、任意のタイミングで実行する。
【００４６】
なお、図４に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
次に、キャッシュデータ記憶部１１０に格納されるキャッシュデータについて、詳細に説明する。
【００４７】
図５は、キャッシュデータ記憶部内のデータの一例を示す図である。キャッシュデータ記憶部１１０は、例えばキャッシュデータごとのレコードを登録するキャッシュデータ管理テーブル１１１を記憶している。キャッシュデータ管理テーブル１１１には、ＵＲＬ、ＨＴＴＰステータス、有効期限、およびデータの欄が設けられている。
【００４８】
ＵＲＬの欄には、キャッシュデータの取得元の位置とデータの名称を示すＵＲＬが設定される。
ＨＴＴＰステータスの欄には、ＵＲＬで示された位置を指定してデータの取得要求をＷｅｂサーバ３１に送信したときの、ＨＴＴＰによるレスポンスのステータスコードが設定される。例えばデータの取得を要求するリクエストに対して、要求されたデータを含むレスポンスのステータスコードは「２００」である。またデータの取得要求で要求したデータが、認証をしたユーザに対してのみ送信されるデータであり、認証せずにデータの取得要求が出された場合、レスポンスのステータスコードは「４０１」である。
【００４９】
有効期限の欄には、Ｗｅｂサーバ３１から取得したデータをキャッシュデータとして利用するための有効期限が設定される。有効期限は、指定したＵＲＬのデータが正しく取得できた場合に設定される。
【００５０】
データの欄には、データの取得要求に応じてＷｅｂサーバ３１から応答されたデータが設定される。例えばレスポンスのＨＴＴＰステータスが「２００」の場合、ＵＲＬで指定した位置のデータが、データの欄に設定される。またレスポンスのＨＴＴＰステータスが「４０１」の場合、例えばレスポンスに示されるエラーメッセージが、データの欄に設定される。
【００５１】
以上のような構成のシステムでは、端末装置２００，３００は、プロキシサーバ１００におけるデータのキャッシュを可能とするために、Ｗｅｂサーバ３１に送信するパケットに、Ｗｅｂサーバ３１に送るデータとは別に、取得するデータのＵＲＬを付与する。例えば端末装置２００，３００は、データのＵＲＬを含む平文のレコード（キャッシュ用レコード）を、ＴＬＳによる暗号化通信用のパケットに含めることができる。
【００５２】
図６は、暗号化通信用のパケットフォーマットの一例を示す図である。例えばＴＣＰ（Transmission Control Protocol）のパケット４０の場合、パケット４０内にフレームヘッダ４１、ＩＰ（Internet Protocol）ヘッダ４２、ＴＣＰヘッダ４３、およびＴＣＰデータ４４が含まれる。フレームヘッダ４１は、Ｅｔｈｅｒｎｅｔ（登録商標）などのデータリンク層のプロトコルで通信を行うための情報である。ＩＰヘッダ４２は、ＩＰで通信を行うための情報である。ＩＰヘッダ４２には、送信元ＩＰアドレスや宛先ＩＰアドレスが含まれる。ＴＣＰヘッダ４３は、ＴＣＰで通信を行うための情報である。ＴＣＰデータ４４は、パケットの送信先に渡すデータである。例えば端末装置２００，３００がＷｅｂサーバ３１からデータを取得する場合、ＴＣＰデータ４４内に取得するデータのＵＲＬが示される。またＷｅｂサーバ３１から端末装置２００，３００へデータを送信する際には、ＴＣＰデータ４４内に、要求されたデータが書き込まれる。
【００５３】
プロキシサーバ１００は、パケット４０のフレームヘッダ４１、ＩＰヘッダ４２、ＴＣＰヘッダ４３の情報を参照可能である。ここで、端末装置２００，３００とＷｅｂサーバ３１が暗号化通信を行わず、ＨＴＴＰで通信を行っていれば、プロキシサーバ１００はＴＣＰデータも参照可能である。そのためＨＴＴＰ通信の場合、プロキシサーバ１００は、端末装置２００，３００からＷｅｂサーバ３１へのリクエストのパケットから、データのＵＲＬを取得する。そしてプロキシサーバ１００は、取得したＵＲＬを指定したリクエストを送信することで、そのＵＲＬに対応するデータを取得できる。これにより、プロキシサーバ１００において、ＵＲＬとデータを対応付けてキャッシュすることが可能となる。
【００５４】
他方、端末装置２００，３００とＷｅｂサーバ３１との間でＨＴＴＰＳによって暗号化通信が行われた場合、ＴＣＰデータ４４が暗号化される。具体的には、ＨＴＴＰ通信のＴＣＰデータ４４には複数のＳＳＬレコード４４−１，４４−２，・・・が含まれており、一部のタイプのＳＳＬレコードが暗号化される。
【００５５】
ＳＳＬレコード４４−１，４４−２，・・・それぞれの先頭の５バイトには、タイプ（Ｔｙｐｅ）４４ａ、バージョン（Ｖｅｒｓｉｏｎ）４４ｂ、データ長（Ｌｅｎｇｔｈ）４４ｃが設定されている。タイプ４４ａの１バイトには、ＳＳＬレコードの種別が示されており、ＴＬＳでは以下の４つのタイプが定義されている。
２０，０ｘ１４：ｃｈａｎｇｅ＿ｃｉｐｈｅｒ＿ｓｐｅｃ
２１，０ｘ１５：ａｌｅｒｔ
２２，０ｘ１６：ｈａｎｄｓｈａｋｅ
２３，０ｘ１７：ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ
タイプを示す値の最初の数値は、タイプの１０進数での識別番号であり、次の値は、識別番号を１６進数で表したものである。暗号化されるのはタイプ「Ａｐｐｌｉｃａｔｉｏｎ  Ｄａｔａ」のＳＳＬレコードである。他のタイプのＳＳＬレコードは暗号化されない。プロキシサーバ１００は、暗号化されたＳＳＬレコードの内容を参照することができない。
【００５６】
端末装置２００，３００からＷｅｂサーバ３１へ送信するＴＬＳのパケットでは、Ｗｅｂサーバ３１へのデータの取得要求は、タイプ「Ａｐｐｌｉｃａｔｉｏｎ  Ｄａｔａ」のＳＳＬレコードに含められる。そのため、データの取得要求で示されるデータのＵＲＬは暗号化される。
【００５７】
なおプロキシサーバ１００は、暗号化されたＳＳＬレコードの内容を参照することはできないが、ＴＣＰデータ４４中のＳＳＬレコード構造は認識可能である。そこで端末装置２００，３００それぞれの暗号化通信部２１１，３１１は、Ｗｅｂサーバ３１へのＨＴＴＰＳのリクエストを送信する際、ＳＳＬレコードの後にプロキシサーバ１００に通知する情報を含むキャッシュ用レコードを追加する。暗号化通信部２１１，３１１は、キャッシュ用レコードは暗号化しない。また暗号化通信部２１１，３１１は、キャッシュ用レコードをＳＳＬレコードと区別するため、ＳＳＬレコードと同様のフォーマットにおけるタイプの値として、例えばキャッシュ用レコードを示す値［２４，０ｘ１８］（１０進数で「２４」、１６進数で「１８」）を設定する。なお、キャッシュ用レコードを示す値［２４，０ｘ１８］は一例であり、暗号化通信部２１１，３１１は、［２５，０ｘ１９］などのＳＳＬのプロトコルにおいて未定義の他の値を、キャッシュ用レコードを示す値とすることができる。
【００５８】
プロキシサーバ１００に通知する情報は、Ｗｅｂサーバ３１から取得するデータのＵＲＬである。なお通知する情報には、ＰＯＳＴデータやクッキーといった情報は含まれない。ＰＯＳＴデータやクッキーには認証情報や個人情報を含む可能性があるため、これらのデータをキャッシュ用レコードに含めないことで、認証情報や個人情報が暗号化せずに通信されることを抑止できる。
【００５９】
プロキシサーバ１００は、キャッシュ用レコードを参照して、リクエストで要求されたデータのＵＲＬを認識し、キャッシュデータ記憶部１１０に該当ＵＲＬに対応するキャッシュデータが格納されていれば、キャッシュデータを応答する。レスポンスのパケットのＴＣＰデータ４４には、タイプ［２４，０ｘ１８］としてキャッシュデータが含められる。
【００６０】
プロキシサーバ１００は、リクエストで要求されたデータのＵＲＬに対応するキャッシュデータがない場合、リクエストのパケットからキャッシュ用レコードを削除して、キャッシュ用レコード削除後のリクエストをＷｅｂサーバ３１に送信する。その後、プロキシサーバ１００は、別途Ｗｅｂサーバ３１に接続し、端末装置２００，３００からのＵＲＬに対応するデータをＷｅｂサーバ３１から取得し、キャッシュする。
【００６１】
図７は、プロキシサーバによるデータキャッシュの概要を示す図である。図７には、Ｗｅｂサーバ３１が有するデータ５１を、端末装置２００が取得した後に、別の端末装置３００が同じデータ５１のデータ取得のリクエストを送信した場合の例が示されている。なお端末装置２００，３００とＷｅｂサーバ３１とは、ＨＴＴＰＳによる暗号化通信を行うものとする。
【００６２】
まず端末装置２００では、暗号化通信部２１１がデータ５１取得のリクエストを作成する（ステップＳ１１）。この際、暗号化通信部２１１は、リクエスト内のＳＳＬレコードに続けて、プロキシサーバ１００に通知するＵＲＬを暗号化せずに追加する。例えばＳＳＬレコ−ドの後に、［０ｘ１８，０ｘ００００，０ｘ００１ｆ，ｈｔｔｐｓ：／／ｗｗｗ．ａｂｃ．ｃｏｍ／ｐｉｃｔｕｒｅ．ｐｎｇ］という情報が追加される。追加された情報内の「０ｘ００１ｆ」（１０進数で「３１」）は、それ以降のＵＲＬの記述”ｈｔｔｐｓ：／／・・・”の文字列の長さ（バイト数）である。そして暗号化通信部２１１は、Ｗｅｂサーバ３１宛てのリクエストをプロキシサーバ１００に送信する（ステップＳ１２）。
【００６３】
プロキシサーバ１００では、ＴＬＳパケット処理部１２０が、リクエストにおいてＳＳＬレコードの後に追加されたＵＲＬに対応するキャッシュデータが、キャッシュデータ記憶部１１０内にあるか否かを確認する（ステップＳ１３）。この時点では、キャッシュデータがないため、ＴＬＳパケット処理部１２０は、端末装置２００から受信したリクエストから、ＳＳＬレコードの後に追加されたＵＲＬを削除し、ＵＲＬ削除後のリクエストをＷｅｂサーバ３１に送信する（ステップＳ１４）。
【００６４】
Ｗｅｂサーバ３１は、リクエストに応じてデータ５１を含むレスポンスを、プロキシサーバ１００に送信する（ステップＳ１５）。プロキシサーバ１００のＴＬＳパケット処理部１２０は、Ｗｅｂサーバ３１からのレスポンスを端末装置２００に送信する（ステップＳ１６）。
【００６５】
キャッシュデータがないことを確認したＴＬＳパケット処理部１２０は、受信したリクエストに含まれるＵＲＬを指定して、キャッシュ用データ取得部１３０にデータ５１のキャッシュ要求を送信する。するとキャッシュ用データ取得部１３０は、ＨＴＴＰＳによる暗号化通信より、Ｗｅｂサーバ３１にデータ５１の取得を要求するリクエストを送信する（ステップＳ１７）。Ｗｅｂサーバ３１はリクエストを受信すると、暗号化したデータ５１を含むレスポンスをプロキシサーバ１００に送信する（ステップＳ１８）。
【００６６】
プロキシサーバ１００のキャッシュ用データ取得部１３０は、受信したレスポンスに含まれるデータ５１を復号し、そのデータをキャッシュする（ステップＳ１９）。これにより、キャッシュデータ記憶部１１０には、Ｗｅｂサーバ３１が有するデータ５１に対応するキャッシュデータ５２が格納される。
【００６７】
その後、端末装置３００の暗号化通信部３１１がデータ５１取得のリクエストを作成する（ステップＳ２１）。この際、暗号化通信部３１１も暗号化通信部２１１と同様に、リクエスト内のＳＳＬレコードに続けて、プロキシサーバ１００に通知するＵＲＬを暗号化せずに追加する。そして暗号化通信部３１１は、Ｗｅｂサーバ３１宛てのリクエストをプロキシサーバ１００に送信する（ステップＳ２２）。プロキシサーバ１００では、ＴＬＳパケット処理部１２０が、リクエストにおいてＳＳＬレコードの後に追加されたＵＲＬに対応するキャッシュデータ５２が、キャッシュデータ記憶部１１０内にあるか否かを確認する（ステップＳ２３）。この時点では、キャッシュデータ５２があるため、ＴＬＳパケット処理部１２０は、キャッシュデータ５２を含むレスポンスを作成する（ステップＳ２４）。そしてＴＬＳパケット処理部１２０は、レスポンスを端末装置３００に送信する（ステップＳ２５）。
【００６８】
このようにして端末装置２００がＷｅｂサーバ３１から取得したデータ５１をプロキシサーバ１００でキャッシュすることができる。その後、同じデータ５１へのリクエストが端末装置３００から出力された場合、プロキシサーバ１００は、キャッシュデータ５２を端末装置３００に送信することで、処理を効率化することができる。
【００６９】
なお端末装置２００とＷｅｂサーバ３１との間の通信は暗号化されており、ステップＳ１５におけるＷｅｂサーバ３１のレスポンスに含まれるデータ５１も暗号化されている。そのためプロキシサーバ１００ではステップＳ１５で送信されたレスポンスからデータ５１を取得することができない。そこでプロキシサーバ１００では、キャッシュ用データ取得部１３０がＷｅｂサーバ３１と暗号化通信を行い、Ｗｅｂサーバ３１からデータ５１を取得している。
【００７０】
以下、図８を参照して、プロキシサーバ１００によるデータキャッシュを含む通信の処理手順について説明する。
図８は、データキャッシュを含む通信処理手順の一例を示すシーケンス図である。端末装置２００の暗号化通信部２１１とＷｅｂサーバ３１とが連係して、暗号化通信用の鍵を生成する（ステップＳ３１，Ｓ３２）。例えば暗号化通信部２１１とＷｅｂサーバ３１とは、ＴＬＳの仕様に従って共有の鍵を生成する。端末装置２００は、ステップＳ３１で作成された鍵を用いてＳＳＬレコードの６バイト目以降を暗号化して、ＴＣＰデータを暗号化したリクエストを作成し、そのリクエストをプロキシサーバ１００に送信する（ステップＳ３３）。リクエストには、ＳＳＬレコードの後に、平文により、取得するデータのＵＲＬが設定されている。
【００７１】
プロキシサーバ１００では、ＴＬＳパケット処理部１２０が、リクエストに平文で示されているＵＲＬに対応するキャッシュデータがあるか否かを判断する（ステップＳ３４）。該当するキャッシュデータがあれば、ＴＬＳパケット処理部１２０は、そのキャッシュデータを含むレスポンスを端末装置２００に送信する（ステップＳ３５）。なおＴＬＳパケット処理部１２０は、キャッシュデータのレスポンスのパケットには、例えばデータのタイプとして、平文のデータであることを示す値［２４，０ｘ１８］を設定する。
【００７２】
キャッシュデータがない場合、ＴＬＳパケット処理部１２０は、端末装置２００から受信したリクエストから平文のＵＲＬを削除し、ＵＲＬ削除後のリクエストをＷｅｂサーバ３１に転送する（ステップＳ３６）。Ｗｅｂサーバ３１は、リクエストをステップＳ３２で生成した鍵を用いて復号する（ステップＳ３７）。Ｗｅｂサーバ３１は復号したリクエストに示されているＵＲＬに対応するデータを、ステップＳ３２で生成した鍵で暗号化し、暗号化したデータを含むレスポンスをプロキシサーバ１００に送信する（ステップＳ３８）。プロキシサーバ１００では、ＴＬＳパケット処理部１２０がレスポンスを受信し、受信したレスポンスを端末装置２００に送信する（ステップＳ３９）。
【００７３】
端末装置２００の暗号化通信部２１１は、プロキシサーバ１００からのレスポンスを解析する（ステップＳ４０）。例えば暗号化通信部２１１は、レスポンスのパケット内のＴＣＰデータに含まれるレコードのタイプを参照し、タイプが［２４，０ｘ１８］であれば、該当レコード内のデータが平文のキャッシュデータであると判断する。また暗号化通信部２１１は、例えばタイプが［２３，０ｘ１７］であれば、該当レコード内のデータが暗号化されたデータであると判断する。暗号化されたデータを受信した場合、暗号化通信部２１１は、ステップＳ３１で生成した鍵を用いてデータを復号する。
【００７４】
また  キャッシュデータがない場合、キャッシュ用データ取得部１３０とＷｅｂサーバ３１とが連係して、暗号化通信用の鍵を生成する（ステップＳ４１，４２）。例えばキャッシュ用データ取得部１３０とＷｅｂサーバ３１とは、ＴＬＳの仕様に従って共有の鍵を生成する。キャッシュ用データ取得部１３０は、ステップＳ４１で作成された鍵を用いて暗号化した、端末装置２００が送信したリクエストに平文で示されていたＵＲＬを含むリクエストを、Ｗｅｂサーバ３１に送信する（ステップＳ４３）。Ｗｅｂサーバ３１は、リクエストをステップＳ４２で生成した鍵を用いて復号する。そしてＷｅｂサーバ３１は、リクエストに示されているＵＲＬに対応するデータをステップＳ４２で生成した鍵で暗号化し、暗号化したデータを含むレスポンスをプロキシサーバ１００に送信する（ステップＳ４４）。プロキシサーバ１００は、レスポンスに含まれるデータを、ステップＳ４１で生成した鍵で復号し、キャッシュデータ記憶部１１０にキャッシュする（ステップＳ４５）。
【００７５】
次に、ブラウザ２１０、ＴＬＳパケット処理部１２０、およびキャッシュ用データ取得部１３０それぞれの実行する処理の手順について、詳細に説明する。
図９は、ブラウザによる暗号化通信処理の手順の一例を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
【００７６】
［ステップＳ１０１］ブラウザ２１０は、Ｗｅｂサーバ３１へのアクセス指示に応じてリクエストを生成する。例えばブラウザ２１０は、ユーザによる、ＵＲＬの入力、お気に入りの選択、画面表示されたＨＴＭＬデータの中のリンクの選択などの入力を、アクセス指示として取得する。またブラウザ２１０は、プログラムの実行過程で発生したＷｅｂサーバ３１へのアクセスのイベントを、アクセス指示として取得する。
【００７７】
ここで、ブラウザ２１０は、アクセス要求においてＨＴＴＰＳによるアクセスが指定された場合、暗号化通信部２１１を用いた暗号化通信を開始する。またブラウザ２１０は、アクセス要求に応じてＷｅｂサーバ３１にアクセスし、Ｗｅｂサーバ３１からＨＴＴＰＳによる再アクセスが求められた場合、暗号化通信部２１１を用いた暗号化通信を開始する。以下、暗号化通信を行う場合の処理を説明する。
【００７８】
［ステップＳ１０２］暗号化通信部２１１は、Ｗｅｂサーバ３１と連係して、暗号化と復号とに使用する鍵を生成する。
［ステップＳ１０３］暗号化通信部２１１は、生成した鍵でデータを暗号化したリクエストを生成する。例えば暗号化通信部２１１は、アクセス先のＵＲＬを含むＳＳＬレコードの６バイト目以降を暗号化する。
【００７９】
［ステップＳ１０４］暗号化通信部２１１は、リクエストの内容が、データ取得を示すＧＥＴ要求か否かを判断する。暗号化通信部２１１は、ＧＥＴ要求であれば、処理をステップＳ１０５に進める。また暗号化通信部２１１は、ＧＥＴ要求以外であれば、処理をステップＳ１０６に進める。ＧＥＴ以外のリクエストとしては、「ＰＯＳＴ／ＰＵＴ／ＤＥＬＥＴＥ」などがある。
【００８０】
［ステップＳ１０５］暗号化通信部２１１は、リクエストの末尾にアクセス先のＵＲＬを平文で含むキャッシュ用レコードを追加する。なお暗号化通信部２１１は、追加したＳＳＬレコードのタイプの値を［０ｘ１８］とする。なお追加するキャッシュ用レコードには、クッキーや認証情報は含まれない。
【００８１】
［ステップＳ１０６］暗号化通信部２１１は、Ｗｅｂサーバ３１へのリクエストをプロキシサーバ１００に送信する。その後、暗号化通信部２１１は、プロキシサーバ１００からのレスポンスを待つ。
【００８２】
［ステップＳ１０７］暗号化通信部２１１は、プロキシサーバ１００からレスポンスを受信する。
［ステップＳ１０８］暗号化通信部２１１は、レスポンス内のレコードに、タイプの値が［０ｘ１８］のレコードがあるか否かを判断する。暗号化通信部２１１は、該当レコードがある場合、処理をステップＳ１０９に進める。また暗号化通信部２１１は、該当レコードがない場合、処理をステップＳ１１０に進める。
【００８３】
［ステップＳ１０９］暗号化通信部２１１は、タイプが［０ｘ１８］のレコードに含まれるデータを、復号済みのデータとして取得する。暗号化通信部２１１は、その後、処理をステップＳ１１１に進める。
【００８４】
［ステップＳ１１０］暗号化通信部２１１は、レスポンス内のＳＳＬレコードの内容を復号し、平文のデータを取得する。
［ステップＳ１１１］暗号化通信部２１１は、取得したデータを出力する。暗号化通信部２１１が出力したデータは、例えばブラウザ２１０によって端末装置２００のモニタに表示される。
【００８５】
このようにして端末装置２００では、Ｗｅｂサーバ３１に対して暗号化通信で送信したリクエストへのレスポンスに平文のキャッシュデータが含まれていた場合でも、そのキャッシュデータをリクエストで要求したデータとして取得することができる。
【００８６】
なお図９のステップＳ１０４では、リクエストの種別を判別している。リクエストの種別は、リクエストの先頭の行を参照して判断することができる。
図１０は、ＧＥＴ要求のリクエストの一例を示す図である。図１０に示すリクエスト６１は、先頭の行に「ＧＥＴ  ｈｔｔｐｓ：／／ｗｗｗ．ｇ０１．ｆ−ｔｓｕ．ｌｏｃａｌ／ｈｅｌｌｏ．ａｓｐｘ  ＨＴＴＰ／１．１」と記載されていることから、ＧＥＴ要求であることが分かる。
【００８７】
図１１は、ＰＯＳＴ要求のリクエストの一例を示す図である。図１１に示すリクエスト６２は、先頭の行に「ＰＯＳＴ  ｈｔｔｐｓ：／／ｗｗｗ．ｇ０１．ｆ−ｔｓｕ．ｌｏｃａｌ／ｈｅｌｌｏ．ａｓｐｘ  ＨＴＴＰ／１．１」と記載されていることから、ＰＯＳＴ要求であることが分かる。
【００８８】
暗号化通信部２１１は、図１０に示したようにリクエスト６１がＧＥＴ要求の場合、そのリクエスト６１の末尾にＵＲＬ情報を示すキャッシュ用レコードを追加する。
図１２は、ＵＲＬ情報を含むリクエストのパケットの一例を示す図である。パケット７０には、フレームヘッダ７１、ＩＰヘッダ７２、ＴＣＰヘッダ７３、およびＴＣＰデータ７４が含まれている。ＴＣＰデータ７４には、ＳＳＬレコード７４ａの後にキャッシュ用レコード７４ｂが追加されている。
【００８９】
ＳＳＬレコード７４ａの先頭の５バイトは「１７  ０３  ０３  ００  ６４」である。１バイト目はタイプが［０ｘ１７］（ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ）であることを示している。２−３バイト目は、バージョンが「０３  ０３」であることを示している。４−５バイト目は、データ長が「００  ６４」（１０進数で１００バイト）であることを示している。６バイト目以降の「ｘｘｘｘ」は１００バイトの暗号データを表している。
【００９０】
キャッシュ用レコード７４ｂの先頭の５バイトは「１８  ０３  ０３  ００  ２６」である。１バイト目はタイプが［０ｘ１８］（ＵＲＬ情報）であることを示している。２−３バイト目は、バージョンが「０３  ０３」であることを示している。４−５バイト目は、データ長が「００  ２６」（１０進数で３８バイト）であることを示している。６バイト目以降の「ｈｔｔｐｓ：／／ｗｗｗ．ｇ０１．ｆ−ｔｓｕ．ｌｏｃａｌ／ｈｅｌｌｏ．ａｓｐｘ」がＵＲＬ情報である。
【００９１】
なお図１２では、ＵＲＬ情報を文字列で表しているが、実際には、パケット７０内には各文字に対応する文字コード「６８  ７４  ７４  ７０  ７３  ３ａ  ２ｆ  ２ｆ  ・・・」が設定される。
【００９２】
なおＷｅｂページの検索要求などにおいて、ＵＲＬの末尾に「？ｑｕｅｒｙ＝ＰＣサーバ」といった検索用のクエリが追記される場合がある。例えばリクエストの先頭の行に「ＧＥＴ  ｈｔｔｐｓ：／／ｗｗｗ．ｆ−ｔｓｕ．ｃｏｍ／ｊｐ／ｓｅａｒｃｈ／？ｑｕｅｒｙ＝ＰＣサーバ  ＨＴＴＰ／１．１」と記載される。この場合、暗号化通信部２１１は、クエリを含むＵＲＬ「ｈｔｔｐｓ：／／ｗｗｗ．ｆ−ｔｓｕ．ｃｏｍ／ｊｐ／ｓｅａｒｃｈ／？ｑｕｅｒｙ＝ＰＣサーバ」をキャッシュ用レコード内のデータとする。
【００９３】
次に、端末装置２００からのリクエストを受信したＴＬＳパケット処理部１２０が実行するパケット中継処理について詳細に説明する。
図１３は、ＴＬＳパケット処理部によるパケット中継処理の手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
【００９４】
［ステップＳ２０１］ＴＬＳパケット処理部１２０は、端末装置２００からのリクエストを受信する。
［ステップＳ２０２］ＴＬＳパケット処理部１２０は、受信したリクエストにタイプ［０ｘ１８］のキャッシュ用レコードがあるか否かを判断する。ＴＬＳパケット処理部１２０は、キャッシュ用レコードがある場合、処理をステップＳ２０３に進める。またＴＬＳパケット処理部１２０は、キャッシュ用レコードがなければ、処理をステップＳ２１１に進める。
【００９５】
［ステップＳ２０３］ＴＬＳパケット処理部１２０は、キャッシュ用レコードをメモリ１０２に格納後、受信したリクエストからキャッシュ用レコードを削除する。
［ステップＳ２０４］ＴＬＳパケット処理部１２０は、キャッシュ用レコードに示されるＵＲＬに合致するキャッシュデータの有無を確認する。例えばＴＬＳパケット処理部１２０は、キャッシュデータ記憶部１１０内のキャッシュデータ管理テーブル１１１のＵＲＬの欄から、キャッシュ用レコードに示されるＵＲＬを検索する。合致するＵＲＬが見つかった場合、ＴＬＳパケット処理部１２０は、該当するＵＲＬに対応するＨＴＴＰステータスを確認する。ＴＬＳパケット処理部１２０は、ＨＴＴＰステータスが「２００（ＯＫ）」であれば、キャッシュ用レコードに示されるＵＲＬに対応するキャッシュデータがあると判断する。
【００９６】
［ステップＳ２０５］ＴＬＳパケット処理部１２０は、キャッシュ用レコードに示されるＵＲＬに対応するキャッシュデータがある場合、処理をステップＳ２０６に進める。またＴＬＳパケット処理部１２０は、キャッシュ用レコードに示されるＵＲＬに対応するキャッシュデータがない場合、処理をステップＳ２０８に進める。
【００９７】
［ステップＳ２０６］ＴＬＳパケット処理部１２０は、現在の日時がキャッシュデータの有効期限内か否かを判断する。例えばＴＬＳパケット処理部１２０は、キャッシュデータ管理テーブル１１１から、キャッシュ用レコードに示されるＵＲＬに対応する有効期限を取得する。そしてＴＬＳパケット処理部１２０は、現在の日時が有効期限以前であれば、有効期限内であると判断する。ＴＬＳパケット処理部１２０は、有効期限内であれば、処理をステップＳ２０７に進める。またＴＬＳパケット処理部１２０は、有効期限を過ぎていれば、処理をステップＳ２０８に進める。
【００９８】
［ステップＳ２０７］ＴＬＳパケット処理部１２０は、キャッシュデータを、タイプ［０ｘ１８］のキャッシュ用レコードとして含むレスポンスを作成する。その後、ＴＬＳパケット処理部１２０は処理をステップＳ２１３に進める。
【００９９】
［ステップＳ２０８］ＴＬＳパケット処理部１２０は、端末装置２００から受信したリクエストをＷｅｂサーバ３１に転送する。
［ステップＳ２０９］ＴＬＳパケット処理部１２０は、キャッシュ用データ取得部１３０に、受信したリクエストに示されるＵＲＬに対応するデータのキャッシュを要求するジョブを投入する。
【０１００】
［ステップＳ２１０］ＴＬＳパケット処理部１２０は、Ｗｅｂサーバ３１からのレスポンスを受信する。その後、ＴＬＳパケット処理部１２０は、処理をステップＳ２１３に進める。
【０１０１】
［ステップＳ２１１］ＴＬＳパケット処理部１２０は、端末装置２００から受信したリクエストをＷｅｂサーバ３１に転送する。
［ステップＳ２１２］ＴＬＳパケット処理部１２０は、Ｗｅｂサーバ３１からのレスポンスを受信する。
【０１０２】
［ステップＳ２１３］ＴＬＳパケット処理部１２０は、レスポンスを端末装置２００に送信する。
このようにしてＴＬＳパケット処理部１２０は、キャッシュデータの有無を判断し、有効なキャッシュデータがある場合には、Ｗｅｂサーバ３１にリクエストを転送せずに、キャッシュデータを応答することができる。
【０１０３】
またＴＬＳパケット処理部１２０は、有効なキャッシュデータがない場合には、キャッシュ用データ取得部１３０にキャッシュ要求のジョブを投入することにより、データのキャッシュをキャッシュ用データ取得部１３０に依頼する。キャッシュ用データ取得部１３０は、投入されたジョブに応じて、キャッシュ用のデータを取得する。
【０１０４】
図１４は、キャッシュ用データ取得処理の手順の一例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ３０１］キャッシュ用データ取得部１３０は、ＴＬＳパケット処理部１２０からのジョブを受信する。キャッシュ用データ取得部１３０は、例えば受信したジョブをキューに格納する。
【０１０５】
［ステップＳ３０２］キャッシュ用データ取得部１３０は、受信したジョブに示されるＵＲＬに対応するキャッシュデータを、キャッシュデータ記憶部１１０から検索する。
なおキャッシュ用データ取得部１３０は、ステップＳ３０２以降の処理を、ジョブを受信した直後に実行してもよいし、所定のタイミングまで待ってから実行してもよい。例えばキャッシュ用データ取得部１３０は、プロキシサーバ１００の負荷が所定値以下になったときにステップＳ３０２以降の処理を実行してもよい。
【０１０６】
［ステップＳ３０３］キャッシュ用データ取得部１３０は、キャッシュデータが検出できたか否かを判断する。キャッシュ用データ取得部１３０は、キャッシュデータが検出できた場合、処理をステップＳ３０５に進める。またキャッシュ用データ取得部１３０は、キャッシュデータが検出できなかった場合、処理をステップＳ３０４に進める。
【０１０７】
［ステップＳ３０４］キャッシュ用データ取得部１３０は、受信したジョブに示されるＵＲＬからの過去のデータ取得においてエラーが発生しているか否かを判断する。例えばキャッシュ用データ取得部１３０は、キャッシュデータ管理テーブル１１１において、受信したジョブに示されるＵＲＬに対応するＨＴＴＰステータスの値がエラーを示す値（「２００」以外）の場合、エラーが発生していると判断する。キャッシュ用データ取得部１３０は、エラーが発生している場合、キャッシュ用データ取得処理を終了する。またキャッシュ用データ取得部１３０は、エラーが発生していなければ、処理をステップＳ３０６に進める。
【０１０８】
［ステップＳ３０５］キャッシュ用データ取得部１３０は、現在の日時がキャッシュデータの有効期限内か否かを判断する。例えばキャッシュ用データ取得部１３０は、キャッシュデータ管理テーブル１１１における、受信したジョブに示されるＵＲＬに対応する有効期限を取得する。そしてキャッシュ用データ取得部１３０は、現在の日時が有効期限以前であれば、有効期限内であると判断する。キャッシュ用データ取得部１３０は、有効期限内であれば、キャッシュ用データ取得処理を終了する。またキャッシュ用データ取得部１３０は、有効期限を過ぎていれば、処理をステップＳ３０６に進める。
【０１０９】
［ステップＳ３０６］キャッシュ用データ取得部１３０は、ジョブに示されているＵＲＬを指定したＧＥＴ要求のリクエストを生成する。
［ステップＳ３０７］キャッシュ用データ取得部１３０は、Ｗｅｂサーバ３１と連係して、暗号化通信用の鍵を生成する。
【０１１０】
［ステップＳ３０８］キャッシュ用データ取得部１３０は、暗号化通信によりリクエストをＷｅｂサーバ３１に送信する。
［ステップＳ３０９］キャッシュ用データ取得部１３０は、Ｗｅｂサーバ３１からレスポンスを受信する。
【０１１１】
［ステップＳ３１０］キャッシュ用データ取得部１３０は、受信したレスポンスに含まれるデータを復号する。
［ステップＳ３１１］キャッシュ用データ取得部１３０は、キャッシュデータ記憶部１１０に、復号したデータを格納する。なおリクエストに対して、Ｗｅｂサーバ３１からエラーのレスポンスが返される場合がある。例えば取得対象のデータがユーザ認証をしないと取得できないデータの場合、またはクッキーがないと取得できないデータの場合、エラーのレスポンスが返される。キャッシュ用データ取得部１３０は、レスポンスがエラーの場合も、エラー内容を示す情報を、キャッシュデータ記憶部１１０に格納する。
【０１１２】
キャッシュ用データ取得部１３０は、例えばキャッシュデータ記憶部１１０内のキャッシュデータ管理テーブル１１１に、取得したデータを含む新たなレコードを追加する。キャッシュ用データ取得部１３０は、追加したレコードのＵＲＬの欄には、取得したデータの取得元のＵＲＬを設定する。キャッシュ用データ取得部１３０は、追加したレコードのＨＴＴＰステータスの欄には、レスポンスのステータスを設定する。キャッシュ用データ取得部１３０は、追加したレコードの有効期限の欄には、Ｗｅｂサーバ３１からのレスポンス内に指定されている有効期限を設定する。またキャッシュ用データ取得部１３０は、レスポンスにおいて有効期限が指定されていない場合、例えば予め設定された有効期限のデフォルト値を、追加レコードの有効期限の欄に設定する。
【０１１３】
図１５は、データの有効期限付きのレスポンスの一例を示す図である。図１５の例では、リクエスト６３を暗号化してＷｅｂサーバ３１に送信したところ、Ｗｅｂサーバ３１からレスポンス６４が返されている。レスポンス６４には「Ｅｘｐｉｒｅｓ：  Ｔｕｅ，  ０２  Ｊｕｌ  ２０１９  １１：１４：０５  ＧＭＴ」との記載により、有効期限が指定されている。図１５の例では「Ｄａｔｅ」で示されている現在日時の１年後の日時が、有効期限として指定されている。キャッシュ用データ取得部１３０は、レスポンス６４の「Ｅｘｐｉｒｅｓ」で示された日時を、レスポンス６４に含まれるデータの有効期限としてキャッシュデータ管理テーブル１１１に設定する。
【０１１４】
なおレスポンス６４では、データの有効期間を指定することも可能である。例えばレスポンス６４の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」における「ｍａｘ−ａｇｅ」の値において、有効期間を秒単位で指定することができる。図１５の例では有効期間が３１５３６０００秒であり、これは３６５日に相当する期間である。
【０１１５】
またレスポンス６４では、プロキシサーバ１００でのキャッシュを許可するか否かを指定することが可能である。例えばレスポンス６４の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」で「ｐｕｂｌｉｃ」と指定された場合、プロキシサーバ１００は、レスポンス６４内のデータのキャッシュが可能である。他方、レスポンス６４の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」で「ｐｒｉｖａｔｅ」と指定された場合、レスポンス６４の内容がユーザ固有の情報であり、プロキシサーバ１００は、レスポンス６４内のデータをキャッシュすることができない。なお、レスポンス６４の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」で「ｐｒｉｖａｔｅ」と指定された場合、端末装置２００のブラウザ２１０がレスポンス６４内のデータをキャッシュすることは可能である。
【０１１６】
また、レスポンス６４が、どこかの装置でキャッシュされたデータである可能性もある。その場合、レスポンス６４の「Ａｇｅ」の値として、最初にキャッシュされてからの経過時間が秒単位で設定される。図１５の例では、すでに２３１５４１秒キャッシュされていることが示されている。
【０１１７】
プロキシサーバ１００が取得したデータは、有効期限内はキャッシュデータとして使用される。そしてイントラネット３３内の端末装置２００から、キャッシュデータに対応するＵＲＬを指定したＧＥＴ要求のリクエストが出力されると、プロキシサーバ１００のＴＬＳパケット処理部１２０が、平文のキャッシュデータを端末装置２００に送信する。
【０１１８】
図１６は、キャッシュデータを応答するパケットの一例を示す図である。図１６には、図１５に示したレスポンスによって取得したデータをキャッシュデータとして送信するためのパケット８０が示されている。パケット８０には、フレームヘッダ８１、ＩＰヘッダ８２、ＴＣＰヘッダ８３、およびＴＣＰデータ８４が含まれている。
【０１１９】
ＴＣＰデータ８４の先頭の５バイトは「１８  ０３  ０３  １ｄ  ｄ５」である。１バイト目はタイプが［０ｘ１８］（キャッシュ用レコード）であることを示している。２−３バイト目は、バージョンが「０３  ０３」であることを示している。４−５バイト目は、レスポンス内容のデータ長が「１ｄ  ｄ５」（１０進数で７６３７バイト）であることを示している。６バイト目以降にレスポンスの内容として、平文のキャッシュデータが記述されている。
【０１２０】
なお図１６では、レスポンスの内容を文字列で表しているが、実際には、パケット８０内には各文字に対応する文字コード「４８  ５４  ５４  ５０  ２ｆ  ３１  ２ｅ  ３１  ・・・」が設定される。またレスポンスの内容に示されている「￥ｒ￥ｎ」は改行を表す文字コードのエスケープシーケンスである。実際には、「￥ｒ」は１バイトで「０ｄ」であり、「￥ｎ」は１バイトで「０ａ」である。
【０１２１】
以上のようにして、第２の実施の形態では、イントラネット３３内の１つの端末装置が暗号化通信によりＷｅｂサーバ３１から取得したデータを、プロキシサーバ１００において平文でキャッシュすることができる。これにより、他の端末装置が同じデータの取得のリクエストを出力した場合、プロキシサーバ１００は、その端末装置に対してキャッシュデータを応答することができる。その結果、暗号化通信によるデータ取得の処理効率を向上させることができる。
【０１２２】
〔その他の実施の形態〕
第２の実施の形態では、ＴＬＳによる暗号化通信の例を示したが、他の暗号化通信であっても、第２の実施の形態と同様にプロキシサーバ１００でデータをキャッシュすることができる。
【０１２３】
また端末装置２００，３００ではブラウザ２１０，３１０が暗号化通信部２１１，３１１を有しているが、端末装置２００，３００においてＷｅｂサーバ３１と暗号化通信を行うのはブラウザ２１０，３１０には限定されない。ブラウザ２１０，３１０以外のソフトウェアであっても暗号化通信部２１１，３１１と同様の機能を用いて、図９と同様の暗号化通信処理を実行することができる。すなわちブラウザ２１０，３１０以外のソフトウェアも、プロキシサーバ１００に暗号化通信対象のデータをキャッシュさせたり、暗号化通信で通信されたデータのキャッシュデータをプロキシサーバ１００から取得したりすることができる。
【０１２４】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０１２５】
１  端末装置
２  サーバ
２ａ  データ
３ａ，３ｂ  第１鍵
４ａ，４ｂ  第２鍵
５  第１リクエスト
５ａ  第１レスポンス
６  第２リクエスト
６ａ  第２レスポンス
７  第３リクエスト
７ａ  第３レスポンス
１０  プロキシサーバ
１１  記憶部
１２  処理部
【図１】
2020057259.tif 000003
【図２】
2020057259.tif 000004
【図３】
2020057259.tif 000005
【図４】
2020057259.tif 000006
【図５】
2020057259.tif 000007
【図６】
2020057259.tif 000008
【図７】
2020057259.tif 000009
【図８】
2020057259.tif 000010
【図９】
2020057259.tif 000011
【図１０】
2020057259.tif 000012
【図１１】
2020057259.tif 000013
【図１２】
2020057259.tif 000014
【図１３】
2020057259.tif 000015
【図１４】
2020057259.tif 000016
【図１５】
2020057259.tif 000017
【図１６】
2020057259.tif 000018