JP6943790B2

JP6943790B2 - セッション情報セットをキャッシュするサーバ、及び、セッション情報セットのキャッシュ制御方法

Info

Publication number: JP6943790B2
Application number: JP2018039131A
Authority: JP
Inventors: 恒太井手口; 伸義森田; 昂太関
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2018-03-05
Filing date: 2018-03-05
Publication date: 2021-10-06
Anticipated expiration: 2038-03-05
Also published as: US10841394B2; US20190273803A1; JP2019153189A

Description

本発明は、概して、セッション情報セットのキャッシュ制御に関する。

セッションＩＤが関連付けられた接続要求に応答して接続が行われる（データの送受信が可能な状態が確立される）技術の一例として、ＴＬＳ（Transport Layer Security）が知られている（ＴＬＳの一種（例えば拡張）として、ＤＴＬＳ（Datagram Transport Layer Security）という技術も知られている）。ＴＬＳでは、初回のセッションでは、フルのハンドシェークがクライアントとサーバ間で行われることで、セッションが確立する。

また、ＴＬＳでは、セッション再開がサポートされている。セッション再開が行われれば、フルのハンドシェークに比べて、リソース量（セッション確立のために必要とされる計算リソース量（例えば、ＣＰＵ使用率のような演算量）、及び、通信量（セッション確立のためにクライアントとサーバ間で送受信されるデータの総量）を削減することができる。

セッション再開のためには、セッションに必要なセッション情報セットがサーバにキャッシュされている必要がある。言い換えれば、サーバでのセッション情報セットのキャッシュヒット率が高ければ、セッション再開の確率が高い。

一般に、セッション情報セットのキャッシュ方式としては、ＦＩＦＯ（First-In First-Out）方式が採用される。

また、サーバでのキャッシュヒット率の向上を狙った技術として、非特許文献１に開示の技術が知られている。非特許文献１によれば、クライアントが、サーバに、当該クライアントが次に接続する予想時刻である次回接続予想時刻を知らせ、サーバは、当該クライアントから知らされた次回接続予想時刻を基に、当該クライアントのセッション情報セットをキャッシュするか否かを決定する。

Ryan Stevens and Hao Chen, "Predictive Eviction: A Novel Policy forOptimizing TLS Session Cache Performance", GLOBECOM 2015.（http://web.cs.ucdavis.edu/~hchen/paper/globecom2015.pdf）

一般に、クライアントに比べて、サーバの方が、通信する相手が多く、故に、キャッシュするセッション情報セットの数も多い。特に、ＩｏＴ（Internet of things）では、センサー機器等の多くのＩｏＴ機器がクライアントとなるため、この傾向は大きい。

サーバにおいて、セッション情報セットのキャッシュ領域の容量よりもセッション情報セットの総量が多い場合、溢れたセッション情報セットはキャッシュ領域から削除されることになる。サーバは、削除されたセッション情報セット中のセッションＩＤをクライアントから受けても、キャッシュミスヒットが生じて、セッション再開は不可能であり、リソース量及び通信量の大きいフルのハンドシェークが必要になる。通信効率の向上のためには、セッション情報セットのキャッシュヒット率の向上が重要と考えられる。

しかし、非特許文献１の技術では、各クライアントが次の接続予想時刻をサーバに知らせる必要があるため、クライアントとサーバ間の通信量が増えてしまう。また、非特許文献１の技術では、各クライアントに、次の接続時刻を予想する機能と当該予想時刻を知らせる機能を追加しなければならず、サーバに比べて多く存在するクライアントの各々にそのような機能を追加することは、負担である。このような課題は、クライアントの数が膨大となる傾向にあるＩｏＴでは特に大きい。

一方、一般に採用されているＦＩＦＯ方式では、非特許文献１の技術のような課題はないが、キャッシュヒット率の向上は期待できない。例えば、同じ間隔で接続要求をそれぞれ送信するようになっている複数のクライアントに対して、キャッシュ領域に格納可能なセッション情報セットの数が、クライアントの数よりも少ない場合、キャッシュヒット率がゼロになってしまう。

上記のような課題は、ＴＬＳ（又はＤＴＬＳ）に限らず、セッションＩＤが関連付けられた接続要求に応答して接続が行われる他の技術に関してもあり得る。

サーバは、クライアントからの接続要求に関してキャッシュミスヒットがある場合（クライアントから受信された接続要求に関連付けられているセッションＩＤに一致するセッションＩＤを含んだセッション情報セットがキャッシュ領域にキャッシュされていない場合）、当該クライアントからの最新の接続要求の受信に関わる時刻と当該クライアントの接続要求周期との合計である次回接続予想時刻を算出する。そして、サーバは、少なくともキャッシュ領域が満杯の場合に、当該クライアントについて算出された次回接続予想時刻に基づいて、上記最新の接続要求に関連付けられているセッションＩＤを含んだセッション情報セットをキャッシュ領域にキャッシュするか否かを決定する。

各クライアントから次回接続予想時刻をサーバに知らせること無しに、クライアントの次回接続予想時刻に基づくキャッシュ制御ができる。そして、各クライアントについて、次回接続予想時刻は、当該クライアントとの接続の実績としての接続要求周期に基づいており、そのような予想時刻を基にキャッシュ制御が行われるので、キャッシュヒット率の向上が期待できる。つまり、各クライアントから次回接続予想時刻をサーバに知らせること無しに、キャッシュヒット率の向上が期待できる。

本発明の一実施形態に係るクライアントサーバシステムの構成を示す。ＩｏＴサーバの構成を示す。セッションキャッシュＤＢの構成を示す。接続要求周期ＤＢの構成を示す。本発明の一実施形態で行われるキャッシュ制御の概要を示す。ＩｏＴ機器とＩｏＴサーバ間の処理の流れを示す。接続要求を受信したＩｏＴサーバにより行われる一連の処理の流れを示す。接続要求を受信したＩｏＴサーバにより行われる一連の処理の変形例に係る部分を示す。

以下の説明では、「インターフェース部」は、１以上のインターフェースでよい。当該１以上のインターフェースは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。

また、以下の説明では、「ＰＤＥＶ部」は、１以上のＰＤＥＶであり、典型的には補助記憶デバイスでよい。「ＰＤＥＶ」は、物理的な記憶デバイス（Physical storage DEVice）を意味し、典型的には、不揮発性の記憶デバイス、例えばＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。

また、以下の説明では、「記憶部」は、メモリ部とＰＤＥＶ部の少なくとも一部とのうちの少なくとも１つ（典型的には少なくともメモリ部）である。

また、以下の説明では、「演算部」は、１以上の演算モジュールである。少なくとも１つの演算モジュールは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種の演算モジュールでもよい。少なくとも１つの演算モジュールとしてのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも１つの演算モジュールは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義の演算モジュールでもよい。

また、以下の説明では、「ｘｘｘテーブル」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

また、以下の説明では、「ｋｋｋ部」（インターフェース部、記憶部及び演算部を除く）の表現にて機能を説明することがあるが、機能は、１以上のコンピュータプログラムが演算部によって実行されることで実現されてもよいし、１以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよい。プログラムが演算部によって実行されることで機能が実現される場合、定められた処理が、適宜に記憶部及び／又はインターフェース部等を用いながら行われるため、機能は演算部の少なくとも一部とされてもよい。機能を主語として説明された処理は、演算部あるいはその演算部を有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が１つの機能にまとめられたり、１つの機能が複数の機能に分割されたりしてもよい。

また、以下の説明では、「情報セット」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペア及びタプルのうちのいずれでもよい。

また、以下の説明では、「時刻」の単位は、年月日時分秒でもよいし、それよりも粗くても細かくてもよいし、それらとは異なる単位でもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号を使用することがある。例えば、ＩｏＴ機器を区別しない場合には、「ＩｏＴ機器１０１」と言い、ＩｏＴ機器を区別する場合には、「ＩｏＴ機器１０１Ａ」、「ＩｏＴ機器１０１Ｂ」のように言う。

以下、図面を参照して、本発明の一実施形態を説明する。なお、本実施形態では、セッションＩＤが関連付けられた接続要求に応答して接続が行われる技術の一例として、ＴＬＳが採用されているが、本発明は、セッションＩＤが関連付けられた接続要求に応答して接続が行われる他の技術にも適用可能である。また、本実施形態では、ＩｏＴでのクライアントサーバ間の通信が例として採用されているが、本発明は、他のクライアントサーバ間通信にも適用可能である。

図１は、本発明の一実施形態に係るクライアントサーバシステムの構成を示す。

複数のＩｏＴ機器１０１（例えばＩｏＴ機器１０１Ａ〜１０１Ｃ）の各々がクライアントの一例として存在し、ＩｏＴサーバ１０３が、サーバの一例として存在する。複数のＩｏＴ機器１０１の各々とＩｏＴサーバ１０３との間で、無線通信ネットワークのような通信ネットワーク１０２を介して、通信が行われる。

ＩｏＴ機器１０１として、種々の機器を採用し得る。例えば、各ＩｏＴ機器１０１は、工場に設置されているセンサー機器（及び他種の機器）でよく、ＩｏＴサーバ１０３は、当該工場内の各ＩｏＴ機器１０１からデータを収集するサーバでよい。

なお、図１において、“ノードＡ”、“ノードＢ”といった表記は、ＩｏＴ機器１０１に割り振られているノードＩＤ（クライアントＩＤの一例）である。

図２は、ＩｏＴサーバ１０３の構成を示す。

ＩｏＴサーバ１０３は、典型的には計算機システム（１以上の計算機）であり、インターフェース部２０１、記憶部２０２及びそれらに接続された演算部２０３を有する。

インターフェース部２０１経由で、各ＩｏＴ機器１０１と通信が行われる。

記憶部２０２は、演算部２０３により実行される１以上のコンピュータプログラムや演算部２０３により参照又は更新される情報を格納する。そのような情報の一例として、セッションキャッシュＤＢ（データベース）２１１、及び、接続要求周期ＤＢ２１２がある。セッションキャッシュＤＢ２１１を格納した記憶領域の全部又は一部が、キャッシュ領域の一例である。

演算部２０３が１以上のコンピュータプログラムを実行することにより、接続制御部２２１及びキャッシュ制御部２２２といった機能が実現される。

接続制御部２２１は、Ｉｏｔ機器１０１との接続を制御する。接続制御部２２１は、次回接続予想時刻及び接続オーバー時刻を算出する時刻算出部２３１と、接続要求周期を算出（更新）する周期算出部２３２とを有する。「次回接続予想時刻」、「接続オーバー時刻」及び「接続要求周期」については、後述する。

キャッシュ制御部２２２は、セッション情報セットのキャッシュを制御する。キャッシュ制御部２２２は、セッション情報セットのキャッシュ優先度を算出（決定）する優先度算出部２４１を有する。「セッション情報セット」及び「キャッシュ優先度」については、後述する。

本実施形態では、ＩｏＴ機器１０１のＩｏＴサーバ１０３への接続は、ＴＬＳに従う。また、本実施形態では、説明を簡単にするために、１つのＩｏＴ機器１０１とＩｏＴサーバ１０３との間では１つのセッションが行われるものとする。

ＴＬＳによれば、初回のセッションでは、フルのハンドシェークが行われる。フルのハンドシェークの概要は、例えば、下記（Ｆ１）〜（Ｆ４）である。
（Ｆ１）ＩｏＴ機器１０１が、任意のセッションＩＤ（ダミーのセッションＩＤ）を関連付けた接続要求（ClientHello）をＩｏＴサーバ１０３に送信する。「セッションＩＤを関連付けた接続要求を送信する」とは、セッションＩＤを含んだ接続要求を送信することでもよいし、接続要求の送信後にセッションＩＤを送信することであってもよい。
（Ｆ２）ＩｏＴサーバ１０３（接続制御部２２１）が、正式なセッションＩＤを関連付けた応答（ServerHello）をＩｏＴ機器１０１に返す。これにより、ＩｏＴサーバ１０３とＩｏＴ機器１０１との間でセッションＩＤが共有される。
（Ｆ３）ＩｏＴサーバ１０３（接続制御部２２１）とＩｏＴ機器１０１との間で、相互認証処理が行われる。
（Ｆ４）ＩｏＴサーバ１０３（接続制御部２２１）とＩｏＴ機器１０１との間で、暗号化通信のための共通鍵の共有のためのやり取りが行われる。

一方、ＴＳＬによれば、ＩｏＴ機器１０１が、正式なセッションＩＤを関連付けた接続要求をＩｏＴサーバ１０３に送信し、ＩｏＴサーバ１０３において、当該セッションＩＤと一致するセッションＩＤを含んだセッション情報セットがキャッシュされているキャッシュヒットがあれば、セッション再開が行われる。セッション再開では、フルのハンドシェークにおいて行われる相互認証処理と共通鍵共有のやり取りの一部が省略される。つまり、セッション確立に必要なハンドシェークが簡略化される。

本実施形態では、ＩｏＴ機器１０１からの接続要求に関してキャッシュミスヒットが生じた場合、接続制御部２２１が、ＩｏＴ機器１０１からの最新の接続要求の受信に関わる時刻と当該ＩｏＴ機器１０１の接続要求周期との合計である次回接続予想時刻を算出する。そして、キャッシュ制御部２２２が、少なくともキャッシュ領域が満杯の場合に、当該ＩｏＴ機器１０１について算出された次回接続予想時刻に基づいて、当該ＩｏＴ機器１０１の最新の接続要求に関連付けられているセッションＩＤを含んだセッション情報セットをキャッシュ領域にキャッシュするか否かを決定する。これにより、各ＩｏＴ機器１０１から次回接続予想時刻をＩｏＴサーバ１０３に知らせること無しに、キャッシュヒット率の向上が期待できる。

なお、「接続要求の受信に関わる時刻」は、当該接続要求を受信した時の現在時刻でもよいし、キャッシュヒット有無の判定のためにキャッシュ領域にアクセスしたときの時刻でもよいし、セッション終了に関わるアクセスを受信した時の現在時刻でもよいし、接続要求に埋め込まれているタイムスタンプが示す時刻でもよい。

また、「キャッシュ領域が満杯」とは、キャッシュされている全セッション情報セットの総容量が容量上限（例えば、キャッシュ領域の容量、又は、その所定割合）に達したことである。ここで言う「総容量」は、キャッシュされているセッション情報セットの数でもよく、同様に、「容量上限」は、キャッシュ領域にキャッシュ可能なセッション情報セットの数の最大値でよい。

以下、本実施形態を詳細に説明する。

図３は、セッションキャッシュＤＢ２１１の構成を示す。

セッションキャッシュＤＢ２１１は、セッション情報セットのＤＢである。セッションキャッシュＤＢ２１１は、セッション毎にレコードを有する。各レコードは、セッション情報セット３０１、ノードＩＤ３０２、次回接続予想時刻３０３及び接続オーバー時刻３０４といった情報を格納する。以下、１つのセッションを例に取る（図３の説明において「対象セッション」）。

セッション情報セット３０１は、対象セッションのセッション情報セットである。ノードＩＤ３０２は、対象セッションに対応したＩｏＴ機器１０１のノードＩＤを示す。次回接続予想時刻３０３は、対象セッションに対応した次の接続要求（セッション再開の要求）の受信に関わる予想時刻を示す。接続オーバー時刻３０４は、対象セッションに対応したセッション情報セットを次の接続要求を受信しないままキャッシュしておく最大時刻（許容される最も将来の時刻）を示す。接続オーバー時刻３０４は、対象セッションの次回接続予想時刻と、対象セッションに対応したクライアントについての許容遅延時間との合計（すなわち、次回接続予想時刻に許容遅延時間が加算されることにより得られた時刻）である。接続オーバー時刻及び次回接続予想時刻のいずれも、時刻算出部２３１により算出される。「許容遅延時間」は、次回接続予想時刻から接続要求の受信が遅延することが許容される時間である。

このように、キャッシュ領域にキャッシュされている各セッション情報セット３０１には、当該セッション情報セット３０１について算出された次回接続予想時刻３０３が関連付けられている。これにより、キャッシュミスヒットに関して算出された次回接続予想時刻を、キャッシュ領域にキャッシュされている各セッション情報セット３０１の次回接続予想時刻３０３と比較して、キャッシュミスヒットに関する新たなセッション情報セットをキャッシュするか否かを決定することができる。

キャッシュ領域は、上述したように、セッションキャッシュＤＢ２１１を格納する記憶領域の全部又は一部である。セッション情報セット３０１、ノードＩＤ３０２、次回接続予想時刻３０３及び接続オーバー時刻３０４のうち、少なくともセッション情報セット３０１がキャッシュ領域に格納される対象でよい。言い換えれば、セッションキャッシュＤＢ２１１を構成する各レコードは、論理的なレコードでよい。例えば、レコードの一部が、主記憶デバイスとしてのメモリ部上にあり、レコードの残りが、補助記憶デバイスとしてのＰＤＥＶ部上にあってもよい。

また、キャッシュ領域の容量上限の一例として、セッションキャッシュＤＢ２１１に格納可能なセッション情報セットの数の最大値が定められている。具体的には、例えば、図３に例示するように、セッションキャッシュＤＢ２１１を構成するレコードの最大数は５である。

なお、「セッション情報セット」は、セッションＩＤの他、通信の際に参照される情報（例えば、暗号化方式を示す情報、相互認証処理で参照された情報）を含んでよい。図３では、セッション情報セット３０１には、セッションＩＤのみ示されている。セッション情報セットは、更に、クライアントＩＤ（例えば、クライアント証明書のハッシュ値）を含んでもよい。

セッションキャッシュＤＢ２１１に対するアクセスは、キャッシュ制御部２２２により行われる。例えば、キャッシュ制御部２２２は、ＩｏＴ機器１０１からのセッションＩＤをキーにキャッシュ領域を検索し、ヒットしたセッション情報セットを読み出す。セッションＩＤの他に、ＩｏＴ機器１０１のクライアントＩＤもキーにされてもよい。また、例えば、キャッシュ制御部２２２は、セッション情報セット３０１、ノードＩＤ３０２、次回接続予想時刻３０３及び接続オーバー時刻３０４を含んだレコードをセッションキャッシュＤＢ２１１に追加（挿入）できる。つまり、キャッシュ制御部２２２は、新たなセッション情報セットをキャッシュできる。また、例えば、キャッシュ制御部２２２は、レコード（セッション情報セット）をセッションキャッシュＤＢ２１１（キャッシュ領域）から削除できる。セッション情報セットの追加や削除は、キャッシュ優先度に基づいてよい。キャッシュ優先度は、優先度算出部２４１により決定される。また、キャッシュ制御部２２２は、レコードを、次回接続予想時刻３０３及び接続オーバー時刻３０４のいずれかをキーにソートできる。

図４は、接続要求周期ＤＢ２１２の構成を示す。

接続要求周期ＤＢ２１２は、接続要求周期のＤＢである。接続要求周期ＤＢ２１２は、ＩｏＴ機器１０１毎にレコードを有する。各レコードは、ノードＩＤ４０１、接続要求周期４０２及び接続要求間隔履歴４０３といった情報を格納する。以下、１つのＩｏＴ機器１０１を例に取る（図４の説明において「対象ＩｏＴ機器１０１」）。

ノードＩＤ４０１は、対象ＩｏＴ機器１０１のノードＩＤを示す。接続要求周期４０２は、対象ＩｏＴ機器１０１の接続要求周期を示す。接続要求周期は、周期算出部２３２により算出される。接続要求間隔履歴４０３は、接続要求間隔（接続要求の受信間隔）の履歴（例えば、直近Ｎ回分（図ではＮ＝３）の接続要求間隔）を示す。

接続要求間隔ＤＢ２１２を構成する各レコードは、論理的なレコードでよい。例えば、レコードの一部が、主記憶デバイスとしてのメモリ部上にあり、レコードの残りが、補助記憶デバイスとしてのＰＤＥＶ部上にあってもよい。

接続制御部２２１における周期算出部２３２が、各ＩｏＴ機器１０１について、当該ＩｏＴ機器１０１の接続要求間隔履歴４０３を参照し、当該ＩｏＴ機器１０１の最新の接続要求間隔（最新の接続要求の受信に関わる時刻と１つ前の接続要求の受信に関わる時刻との間隔）を含む複数の接続要求間隔に基づき、当該ＩｏＴ機器１０１の接続要求周期を更新する。これにより、接続要求周期として適切な接続要求周期が得られることが期待でき、以って、キャッシュ制御の際に参照される次回接続予想時刻の適切性の向上が期待できる。接続要求周期の更新は、接続要求の処理における任意のタイミング（例えば、セッション終了に関わるアクセスを受信した時）に行われてよい。また、「接続要求周期」は、複数の接続要求間隔に基づく値（例えば、平均値、最大値又は最小値）である。

また、ノードＩＤは、ＴＬＳに従うセッション（例えば、フルのハンドシェークでの相互認証処理）において入手されるＩＤであり、ＩｏＴ機器１０１を一意に特定可能なＩＤである。このような当然に入手されるノードＩＤを利用することで（有効活用することで）、ＩｏＴ機器１０１と接続要求周期（及び接続要求間隔履歴）との対応関係を正確に維持することができる。なお、ノードＩＤは、例えば、ＩｏＴ機器１０１から入手されるクライアント証明書のハッシュ値でよい。

図５は、本実施形態で行われるキャッシュ制御の概要を示す。なお、以下の説明では、「セッションｎ」（ｎは自然数）は、セッションＩＤ＝ｎのセッションを意味する。また、図５の説明では、便宜上、ＩｏＴ機器１０１を、ノードＩＤを使用して呼ぶことにする。具体的には、例えば、「ノードＡ」は、ＩｏＴ機器１０１Ａを意味する（図１参照）。

例えば、時刻ｔ＝９０のときに、キャッシュ領域が満杯であるとする。例えば、セッションキャッシュＤＢ２１１には、セッション１〜５にそれぞれ対応した５件のセッション情報セット（５件のレコード）が格納されている。セッション１〜５は、ノードＡ〜Ｅにそれぞれ対応している。

そして、時刻ｔ＝１００のときに、ノードＦからセッション６が生じたとする。セッション６のセッション情報セットはキャッシュされていないため（セッション６に対応したレコードがセッションキャッシュＤＢ２１１に無いため）、キャッシュミスヒットが生じる。

この場合、時刻算出部２３１は、ノードＦについてセッション６に対応した次回接続予想時刻を算出する。ここでは、例えば、セッション６の次回接続予想時刻は、現在時刻とノードＦの接続間隔周期との合計である。この段落で言う「現在時刻」は、セッション６に関する接続要求の受信に関わる時刻の一例であり、例えば、セッション６に関するキャッシュアクセス時刻（例えば、セッション６についてのキャッシュヒット有無の判定のためにセッションキャッシュＤＢ２１１にアクセスした時刻）である。また、この段落で言う「接続間隔周期」は、ノードＦの最近の接続要求間隔と接続要求間隔履歴とに基づき更新された最新の周期である（図５の例によれば、当該周期は“２５”から“３０”に更新されている）。

優先度算出部２４１は、少なくともキャッシュ領域が満杯の場合に、セッション６のセッション情報セットのキャッシュ優先度と、キャッシュ領域にキャッシュされている各セッション情報セット（セッション１〜５の各々のセッション情報セット）のキャッシュ優先度とを算出する。キャッシュ制御部２２２は、それらのキャッシュ優先度を基に、セッション６のセッション情報セットをキャッシュ領域にキャッシュするか否かを決定する。各セッション情報セットのキャッシュ優先度は、当該セッション情報セットに関連付けられる次回接続予想時刻に基づく。接続オーバー時刻が無い場合、キャッシュ優先度が高いことと、次回接続予想時刻が現在時刻に近いこととが同義でよい。言い換えれば、キャッシュ優先度の算出と次回接続予想時刻の取得とが同義でよい。キャッシュ優先度の高さに応じて、セッション６のセッション情報セットをキャッシュするか否かと、セッション６のセッション情報セットのキャッシュのためにセッションキャッシュＤＢ２１１から削除するセッション情報セットの決定とを行うことができる。例えば、キャッシュ制御部２２２は、セッション６のセッション情報セットのキャッシュ優先度が、キャッシュ領域にキャッシュされているいずれのセッション情報セットのキャッシュ優先度よりも低い最低優先度か否かの判定（最低優先度判定）を行う。当該判定の結果が偽の場合、キャッシュ制御部２２２は、キャッシュ領域にキャッシュされているセッション情報セットのうちキャッシュ優先度が最も低いセッション情報セット（図５の例によれば、次回接続予想時刻が現在時刻ｔ＝１００から最も遠いセッション５のセッション情報セット）をキャッシュ領域から削除する。キャッシュ制御部２２２は、セッション６のセッション情報セットをキャッシュ（追加）する。

一方、キャッシュ制御部２２２は、最低優先度判定の結果が真の場合、セッション６のセッション情報セットを破棄する（或いは、セッション６のセッション情報セットを未作成のまま終了する）。

なお、優先度算出部２４１により算出される、各セッション情報セットのキャッシュ優先度は、当該セッション情報セットに関連付けられる次回接続予想時刻に加えて、当該セッション情報セットに関連付けられる接続オーバー時刻にも基づいていてよい。各セッション情報セットについて、接続オーバー時刻は、時刻算出部２３１により算出される。例えば、セッション６のセッション情報セットに関連付けられる次回接続予想時刻と、当該セッション情報セットに対応したノードＦに関連付けられている許容遅延時間との合計である。これにより、未使用のままセッション情報セットがキャッシュ領域に残り続けるといったことを回避できる適切なキャッシュ優先度が期待でき、結果として、キャッシュヒット率の向上が期待できる。

少なくとも１つのＩｏＴ機器１０１（ノード）についての許容遅延時間は、当該ＩｏＴ機器以外のいずれかのＩｏＴ機器１０１についての許容遅延時間と異なっていてよい。これにより、ＩｏＴ機器１０１の種類等に応じた適切な接続オーバー時刻が期待でき、以って、キャッシュヒット率の向上が期待できる。

また、各ＩｏＴ機器１０１についての許容遅延時間は、当該ＩｏＴ機器１０１に対応した接続要求周期と、当該ＩｏＴ機器１０１の接続要求間隔履歴とのうちの少なくとも１つに基づいていてよい。これにより、ＩｏＴ機器１０１の接続要求間隔の状況に適切な接続オーバー時刻が期待でき、以って、キャッシュヒット率の向上が期待できる。

また、キャッシュ優先度の関係として、下記（Ｒ１）〜（Ｒ３）の関係が採用されてよい。（Ｒ１）によれば、接続オーバー時刻を過ぎても未使用のままキャッシュ領域に残っているセッション情報セットを優先的にキャッシュ領域から削除することができる。（Ｒ２）によれば、接続オーバー時刻を過ぎても未使用のままキャッシュ領域に残っているセッション情報セットのうち、最も未使用である期間の長いセッション情報セットを優先的にキャッシュ領域から削除することができる。（Ｒ３）によれば、接続オーバー時刻に未到達であるが故に近い将来使用され得るセッション情報セットのうち、使用されることが最も遅いと予想されるセッション情報セットを優先的にキャッシュ領域から削除することができる。
（Ｒ１）現在時刻よりも過去の時刻が接続オーバー時刻であるセッション情報セットのキャッシュ優先度は、現在時刻又はそれよりも将来の時刻が接続オーバー時刻であるセッション情報セットのキャッシュ優先度より低い。
（Ｒ２）現在時刻よりも過去の時刻が接続オーバー時刻であるセッション情報セットに関し、接続オーバー時刻が現在時刻から遠い程、キャッシュ優先度が低い。
（Ｒ３）現在時刻又はそれよりも将来の時刻が接続オーバー時刻であるセッション情報セットに関し、次回接続予想時刻が現在時刻から遠い程、キャッシュ優先度が低い。

以下、本実施形態で行われる処理の例を説明する。

図６は、ＩｏＴ機器１０１とＩｏＴサーバ１０３間の処理の流れを示す。

例えば、ＩｏＴ機器１０１Ａ〜１０１Ｃの各々が、図４に例示の接続要求周期で接続要求を発行する。具体的には、例えば、ＩｏＴ機器１０１Ａが、接続要求周期“３０”で、接続要求をＩｏＴサーバ１０３に送信する（６０１Ａ）。ＩｏＴ機器１０１Ｂが、接続要求周期“７０”で、接続要求をＩｏＴサーバ１０３に送信する（６０１Ｂ）。ＩｏＴ機器１０１Ｃが、接続要求周期“６０”で、接続要求をＩｏＴサーバ１０３に送信する（６０１Ｃ）。

ＩｏＴサーバ１０３は、接続要求の受信の都度に、接続制御とキャッシュ制御とを含む一連の処理（６５０）を行う。

図７は、接続要求を受信したＩｏＴサーバ１０３により行われる一連の処理の流れを示す。以下、図７の説明において、当該受信した接続要求を「対象接続要求」と言い、対象接続要求に関連付けられているセッションＩＤに対応したセッションを「対象セッション」と言い、対象セッションのセッション情報セットを「対象セッション情報セット」と言い、対象接続要求の送信元のＩｏＴ機器１０１を、「対象ノード」と言う。

キャッシュ制御部２２２が、対象セッション情報セットがセッションキャッシュＤＢ２１１に存在するキャッシュヒットがあるか否かを判定する（Ｓ７００）。

Ｓ７００の判定結果が真の場合（Ｓ７００：Ｙｅｓ）、つまりキャッシュヒットがある場合、次の処理が行われる。すなわち、接続制御部２２１が、ヒットした対象セッション情報セットを用いたセッション再開の処理を行う（Ｓ７１１）。この処理では、簡略化されたハンドシェークが行われればよい。Ｓ７１２において、周期算出部２３２が、最新の接続要求間隔を基に、対象ノードの接続要求周期を更新する。また、Ｓ７１２において、時刻算出部２３１が、現在時刻（例えばＳ７００のときの時刻）と当該接続要求周期とから対象セッションの次回接続予想時刻を算出し、且つ、当該次回接続予想時刻と対象ノードの許容遅延時間とから接続オーバー時刻を算出する。キャッシュ制御部２２２が、対象セッションに対応したキャッシュレコード（セッションキャッシュＤＢ２１１内のレコード）を更新する（Ｓ７１３）。具体的には、キャッシュ制御部２２２が、キャッシュされている対象セッション情報に関連付けられている次回接続予想時刻３０３及び接続オーバー時刻３０４を、Ｓ７１２で算出された次回接続予想時刻及び接続オーバー時刻に更新する。

Ｓ７００の判定結果が偽の場合（Ｓ７００：Ｎｏ）、つまりキャッシュミスヒットがある場合、次の処理が行われる。すなわち、接続制御部２２１が、セッション確立処理を行う（Ｓ７２１）。この処理では、フルのハンドシェークが行われる。Ｓ７２２において、Ｓ７１２と同じ処理が行われる。キャッシュ制御部２２２が、キャッシュ領域が満杯か否かを判断する（Ｓ７２３）。Ｓ７２３の判定結果が偽の場合（Ｓ７２３：Ｎｏ）、キャッシュ制御部２２２が、対象セッション情報セットを含んだキャッシュレコードをセッションキャッシュＤＢ２１１に追加（対象セッション情報セットをキャッシュ）する（Ｓ７２４）。一方、Ｓ７２３の判定結果が真の場合（Ｓ７２３：Ｙｅｓ）、キャッシュ制御部２２２が、対象セッション情報セットのキャッシュ優先度と、キャッシュされている各セッション情報セットのキャッシュ優先度とを算出する（Ｓ７２５）。キャッシュ制御部２２２は、対象セッション情報セットのキャッシュ優先度が、キャッシュされているいずれのセッション情報セットのキャッシュ優先度よりも低い最低優先度か否かを判定する（Ｓ７２６）。Ｓ７２６の判定結果が真の場合（Ｓ７２６：Ｙｅｓ）、キャッシュ制御部２２２は、対象セッション情報セットを破棄する（Ｓ７２７）。Ｓ７２６の判定結果が偽の場合（Ｓ７２６：Ｎｏ）、キャッシュ制御部２２２は、最低のキャッシュ優先度のセッション情報セットを含んだキャッシュレコードをセッションキャッシュＤＢ２１１から削除し、対象セッション情報セットを含んだキャッシュレコードをセッションキャッシュＤＢ２１１に追加する（Ｓ７２８）。

なお、Ｓ７００〜Ｓ７２８のいずれかのタイミング（例えばＳ７２８）において、キャッシュ制御部２２２は、ガベージがあればそれをセッションキャッシュＤＢ２１１から削除してよい。ここで言う「ガベージ」とは、現在時刻よりも過去の時刻が接続オーバー時刻であるセッション情報セットを含んだキャッシュレコードである。ガベージが削除されることで、新たなセッション情報セットのキャッシュが可能となり、結果として、キャッシュヒット率の向上が期待できる。

図８は、接続要求を受信したＩｏＴサーバ１０３により行われる一連の処理の変形例に係る部分を示す。本変形例では、キャッシュ優先度に、接続オーバー時刻が考慮されないでもよい。

例えば、Ｓ７００：Ｎｏの場合、キャッシュ制御部２２２が、キャッシュ領域が満杯か否かを判定する（Ｓ８０１）。Ｓ８０１の判定結果が偽の場合（Ｓ８０１：Ｎｏ）、Ｓ７２４以降の処理が行われる。

Ｓ８０１の判定結果が真の場合（Ｓ８０１：Ｙｅｓ）、キャッシュ制御部２２２は、ガベージがあるか否か、すなわち、現在時刻よりも過去の時刻が接続オーバー時刻であるセッション情報セットを含んだキャッシュレコードがセッションキャッシュＤＢ２１１にあるか否かを判定する（Ｓ８０２）。Ｓ８０２の判定結果が真の場合（Ｓ８０２：Ｙｅｓ）、キャッシュ制御部２２２は、少なくとも１つのガベージをセッションキャッシュＤＢ２１１から削除する。これにより、キャッシュヒット有無判定のためのキャッシュアクセスの際にガベージ有無判定が行われる。つまり、効率的にガベージ削除が行われる。

Ｓ８０２の判定結果が偽の場合（Ｓ８０２：Ｎｏ）、キャッシュ領域が満杯のため、Ｓ７２１、Ｓ７２２及びＳ７２５以降が行われる。

なお、Ｓ８０２及びＳ８０３は、接続要求を受信した場合に行われる一連の処理とは非同期に（例えば定期的に）行われてもよいが、上述の実施形態や変形例のように、接続要求を受信した場合に行われる一連の処理において行われることで、効率的にガベージを削除することができる。

以上、一実施形態及び一変形例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態及び変形例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、実施形態では、説明を簡単にするために、ＩｏＴ機器１０１とセッションＩＤは１：１としたが（１つのＩｏＴ機器１０１とＩｏＴサーバ１０３との間では１つのセッションが行われるものとしたが）、ＩｏＴ機器１０１とセッションＩＤは１：多でもよい。ＩｏＴサーバ１０３の記憶部では、各ＩｏＴ機器１０１について、セッション別に、セッションＩＤ、接続要求周期、接続要求間隔履歴、及び許容遅延時間の少なくとも１つが管理されてもよい。例えば、或るクライアントの或るセッションについての次回接続予想時刻に加算される接続要求周期は、当該或るクライアントの当該或るセッションに対応した接続要求周期でよい。

１０３…ＩｏＴサーバ

Claims

セッションＩＤが関連付けられた接続要求をいずれかのクライアントから受信した場合に、当該セッションＩＤに一致するセッションＩＤを含んだセッション情報セットがキャッシュ領域にキャッシュされているキャッシュヒットがあれば、当該キャッシュされているセッション情報セットを用いたセッション再開を行うサーバであって、
当該接続要求の受信に関わる時刻と当該クライアントの接続要求周期との合計である次回接続予想時刻を算出する接続制御部と、
少なくとも前記キャッシュ領域が満杯の場合に、当該クライアントについて算出された次回接続予想時刻に基づいて、当該接続要求に関連付けられているセッションＩＤを含んだセッション情報セットである対象セッション情報セットを前記キャッシュ領域にキャッシュするか否かを決定するキャッシュ制御部と
を有し、
前記キャッシュ制御部は、前記対象セッション情報セットを前記キャッシュ領域にキャッシュするか否かを、前記対象セッション情報セットのキャッシュ優先度と、前記キャッシュ領域にキャッシュされている全セッション情報セットの各々のキャッシュ優先度とを基に決定し、
各セッション情報セットのキャッシュ優先度は、当該セッション情報セットに関連付けられる次回接続予想時刻に基づく、
サーバ。
前記接続制御部が、当該クライアントからの接続要求の最新の受信間隔を含む複数の接続要求間隔に基づき、当該クライアントの接続要求周期を更新する、
請求項１に記載のサーバ。
前記キャッシュ制御部は、前記対象セッション情報セットのキャッシュ優先度が、前記キャッシュ領域にキャッシュされている少なくとも１つのセッション情報セットのキャッシュ優先度よりも高い場合、前記キャッシュ領域にキャッシュされているセッション情報セットのうちキャッシュ優先度が最も低いセッション情報セットを前記キャッシュ領域から削除する、
請求項１に記載のサーバ。
前記キャッシュ領域にキャッシュされている各セッション情報セットには、当該セッション情報セットについて算出された次回接続予想時刻が関連付けられている、
請求項１に記載のサーバ。
前記各セッション情報セットのキャッシュ優先度は、当該セッション情報セットに関連付けられる次回接続予想時刻に加えて、当該セッション情報セットに関連付けられる接続オーバー時刻にも基づいており、
前記各セッション情報セットについて、接続オーバー時刻は、当該セッション情報セットに関連付けられる次回接続予想時刻と、当該セッション情報セットに対応したクライアントに関連付けられている許容遅延時間との合計である、
請求項１に記載のサーバ。
現在時刻よりも過去の時刻が接続オーバー時刻であるセッション情報セットのキャッシュ優先度は、前記現在時刻又はそれよりも将来の時刻が接続オーバー時刻であるセッション情報セットのキャッシュ優先度より低く、
前記現在時刻よりも過去の時刻が接続オーバー時刻であるセッション情報セットに関し、接続オーバー時刻が前記現在時刻から遠い程、キャッシュ優先度が低く、
前記現在時刻又はそれよりも将来の時刻が接続オーバー時刻であるセッション情報セットに関し、次回接続予想時刻が前記現在時刻から遠い程、キャッシュ優先度が低い、
請求項５に記載のサーバ。
１以上のクライアントの各々のクライアントＩＤに、当該クライアントの接続要求周期とそれの基になる接続要求間隔履歴とのうちの少なくとも１つが関連付けられており、
前記１以上のクライアントの各々について、当該クライアントのクライアントＩＤは、当該クライアントとの接続のためのセッションにおいて入手されるクライアントＩＤである、
請求項１に記載のサーバ。
いずれかのクライアントから受信された接続要求に関連付けられているセッションＩＤに一致するセッションＩＤを含んだセッション情報セットがキャッシュ領域にキャッシュされていないキャッシュミスヒットがある場合に、
前記クライアントからの最新の接続要求の受信に関わる時刻と前記クライアントの接続要求周期との合計である次回接続予想時刻を算出し、
少なくとも前記キャッシュ領域が満杯の場合に、前記クライアントについて算出された次回接続予想時刻に基づいて、前記最新の接続要求に関連付けられているセッションＩＤを含んだセッション情報セットである対象セッション情報セットを前記キャッシュ領域にキャッシュするか否かを決定し、
前記対象セッション情報セットを前記キャッシュ領域にキャッシュするか否かは、前記対象セッション情報セットのキャッシュ優先度と、前記キャッシュ領域にキャッシュされている全セッション情報セットの各々のキャッシュ優先度とを基に決定され、
各セッション情報セットのキャッシュ優先度は、当該セッション情報セットに関連付けられる次回接続予想時刻に基づく、
キャッシュ制御方法。
いずれかのクライアントから受信された接続要求に関連付けられているセッションＩＤに一致するセッションＩＤを含んだセッション情報セットがキャッシュ領域にキャッシュされていないキャッシュミスヒットがある場合に、
前記クライアントからの最新の接続要求の受信に関わる時刻と前記クライアントの接続要求周期との合計である次回接続予想時刻を算出し、
少なくとも前記キャッシュ領域が満杯の場合に、前記クライアントについて算出された次回接続予想時刻に基づいて、前記最新の接続要求に関連付けられているセッションＩＤを含んだセッション情報セットである対象セッション情報セットを前記キャッシュ領域にキャッシュするか否かを決定する、
ことを計算機に実行させるコンピュータプログラムであって、
前記対象セッション情報セットを前記キャッシュ領域にキャッシュするか否かは、前記対象セッション情報セットのキャッシュ優先度と、前記キャッシュ領域にキャッシュされている全セッション情報セットの各々のキャッシュ優先度とを基に決定され、
各セッション情報セットのキャッシュ優先度は、当該セッション情報セットに関連付けられる次回接続予想時刻に基づく、
コンピュータプログラム。