(57)【要約】【課題】配信するコンテンツのセグメントのキャッシュヒット率を向上させる。【解決手段】本発明のリバースプロキシ１は、クライアント２ａ〜２ｎから受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１符号化速度を有する第１セグメントを要求する情報である第２要求情報を、Webサーバ３ａ〜３ｇに送信し、コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１符号化速度と異なる第２符号化速度を有する第２セグメントを要求する情報である第３要求情報を、Webサーバ３ａ〜３ｇに送信し、Webサーバ３ａ〜３ｇから受信した第１セグメントを、クライアント２ａ〜２ｎに送信するデータ送受信部１２と、Webサーバ３ａ〜３ｇから受信した第２セグメントを、記憶部に記憶する制御部１１と、を有する。【選択図】図１
2019146124.tif 000002
【特許請求の範囲】
【請求項１】
第１通信装置から受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１伝送速度情報を有する第１セグメントを要求する情報である第２要求情報を、第２通信装置に送信する第１送信処理部と、
コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１伝送速度情報と異なる第２伝送速度情報を有する第２セグメントを要求する情報である第３要求情報を、第２通信装置に送信する第２送信処理部と、
第２通信装置から受信した第１セグメントを、第１通信装置に送信する第３送信処理部と、
第２通信装置から受信した第２セグメントを、記憶部に記憶する記憶処理部と、
を有することを特徴とする中継装置。
【請求項２】
前記記憶部は、前記第１セグメントの要求の履歴を示す要求履歴情報を記憶しており、
前記記憶処理部は、前記要求履歴情報に基づいて決定された前記第２セグメントを、前記記憶部に記憶する、
ことを特徴とする請求項１に記載の中継装置。
【請求項３】
前記記憶処理部は、前記要求履歴情報から推定されたネットワーク輻輳状況に基づいて決定された前記第２セグメントを、前記記憶部に記憶する、
ことを特徴とする請求項２に記載の中継装置。
【請求項４】
前記第１通信装置が要求した第３セグメントが、前記記憶部に記憶されていた場合、
前記第３送信処理部は、前記第３セグメントを前記第１通信装置に送信する、
ことを特徴とする請求項１から請求項３のいずれか１項に記載の中継装置。
【請求項５】
前記第２伝送速度情報は、前記第１伝送速度情報が示す情報と同じ情報を含む、
ことを特徴とする請求項１から請求項４のいずれか１項に記載の中継装置。
【請求項６】
中継装置のコンピュータを、
第１通信装置から受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１伝送速度情報を有する第１セグメントを要求する情報である第２要求情報を、第２通信装置に送信する第１送信処理部、
コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１伝送速度情報と異なる第２伝送速度情報を有する第２セグメントを要求する情報である第３要求情報を、第２通信装置に送信する第２送信処理部、
第２通信装置から受信した第１セグメントを、第１通信装置に送信する第３送信処理部、
第２通信装置から受信した第２セグメントを、記憶部に記憶する記憶処理部、
として機能させるための中継プログラム。
【請求項７】
中継装置の中継方法であって、
前記中継装置が、
第１通信装置から受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１伝送速度情報を有する第１セグメントを要求する情報である第２要求情報を、第２通信装置に送信するステップと、
コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１伝送速度情報と異なる第２伝送速度情報を有する第２セグメントを要求する情報である第３要求情報を、第２通信装置に送信するステップと、
第２通信装置から受信した第１セグメントを、第１通信装置に送信するステップと、
第２通信装置から受信した第２セグメントを、記憶部に記憶するステップと、
を実行することを特徴とする中継方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、中継装置、中継プログラム、および、中継方法に関し、特に、MPEG-DASH動画配信システムにおけるリバースプロキシサーバ（以下、「リバースプロキシ」と呼ぶ）に関するものである。
【背景技術】
【０００２】
従来、Dynamic Adaptive Streaming over HTTP（以下、DASHと記す）対応のリバースプロキシは、クライアントからセグメント要求を受信したとき、要求されたセグメントがキャッシュ内にない場合、ストリーミングサーバであるWebサーバから該当のセグメントを取得して応答していた（特許文献１参照）。また、DASH対応のリバースプロキシは、Webサーバからセグメントを取得するとき、キャッシュヒット率を改善するため、１または複数のセグメントを取得していた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２０１５−５３７４４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の方法ではクライアントから、異なる符号化速度のセグメント要求があったときには、リバースプロキシはまた改めて指定された符号化速度のセグメントをWebサーバから取得する必要があった。このため、従来のDASH対応のリバースプロキシでは、キャッシュヒット率が低いという問題点があった。
【０００５】
上記事情に鑑みて、本発明は、配信するコンテンツのセグメントのキャッシュヒット率を向上させることを課題とする。
【課題を解決するための手段】
【０００６】
前記課題を解決するため、本発明の中継装置は、第１通信装置から受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１伝送速度情報を有する第１セグメントを要求する情報である第２要求情報を、第２通信装置に送信する第１送信処理部と、コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１伝送速度情報と異なる第２伝送速度情報を有する第２セグメントを要求する情報である第３要求情報を、第２通信装置に送信する第２送信処理部と、第２通信装置から受信した第１セグメントを、第１通信装置に送信する第３送信処理部と、第２通信装置から受信した第２セグメントを、記憶部に記憶する記憶処理部と、を有することを特徴とする。
【０００７】
また、本発明の中継プログラムは、中継装置のコンピュータを、第１通信装置から受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１伝送速度情報を有する第１セグメントを要求する情報である第２要求情報を、第２通信装置に送信する第１送信処理部、コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１伝送速度情報と異なる第２伝送速度情報を有する第２セグメントを要求する情報である第３要求情報を、第２通信装置に送信する第２送信処理部、第２通信装置から受信した第１セグメントを、第１通信装置に送信する第３送信処理部、第２通信装置から受信した第２セグメントを、記憶部に記憶する記憶処理部、として機能させるための中継プログラムである。
【０００８】
また、本発明の中継方法は、中継装置の中継方法であって、前記中継装置が、第１通信装置から受信した第１要求情報を用いて得られた、コンテンツにおける第１セグメントを要求するための情報であり、第１伝送速度情報を有する第１セグメントを要求する情報である第２要求情報を、第２通信装置に送信するステップと、コンテンツにおいて第１セグメントよりも後に続く第２セグメントを要求するための情報であり、第１伝送速度情報と異なる第２伝送速度情報を有する第２セグメントを要求する情報である第３要求情報を、第２通信装置に送信するステップと、第２通信装置から受信した第１セグメントを、第１通信装置に送信するステップと、第２通信装置から受信した第２セグメントを、記憶部に記憶するステップと、を実行することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、配信するコンテンツのセグメントのキャッシュヒット率を向上させることができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態のリバースプロキシを含むストリーム配信システムの機能構成図である。
【図２】リバースプロキシの機能構成図である。
【図３】ファイル名・シーケンス番号管理部が有するテーブルのデータ構造図である。
【図４】クライアント要求履歴管理部が有するテーブルのデータ構造図である。
【図５】動画配信シーケンス図である。
【図６】リバースプロキシの制御部の処理を示すフローチャートである。
【図７】直近要求セグメントと近傍セグメントとの関係図（１）である。
【図８】直近要求セグメントと近傍セグメントとの関係図（２）である。
【図９】直近要求セグメントと近傍セグメントとの関係図（３）である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施するための形態を、適宜図面を参照しながら詳細に説明する。
各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。また、本実施形態では、本発明と直接的に関連しない構成や周知な構成については、説明を省略する場合がある。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。
【００１２】
［構成］
図１は、本実施形態のリバースプロキシを含むストリーム配信システムの機能構成図である。本実施形態の動画配信システムは、MPEG-DASH用のリバースプロキシ１と、動画視聴用の複数のクライアント２ａ〜２ｎと、動画配信用の複数のWebサーバ３ａ〜３ｇとを備える。リバースプロキシ１、クライアント２ａ〜２ｎ、Webサーバ３ａ〜３ｇは、ネットワークで通信可能に接続されている。
【００１３】
ここで、リバースプロキシ１は、「中継装置」の一例である。クライアント２ａ〜２ｎは、「第１通信装置」の一例である。Webサーバ３ａ〜３ｇは、「第２通信装置」の一例である。
【００１４】
配信されるコンテンツにおいて、符号化速度が1Mbps(1M), 2Mbps(2M), 3Mbps(3M),5Mbps(5M),7Mbps(7M),10Mbps(10M),15Mbps(15M)のものが用意されている。各符号化速度の同じコンテンツはそれぞれ、Webサーバ３ａ〜３ｇに格納されている。Webサーバ３ａ〜３ｇは、リバースプロキシ１を中継してクライアント２ａ〜２ｎと通信することができる。
【００１５】
リバースプロキシ１は、ＣＰＵ（Central Processing unit）と、メモリと、ハードディスクなどの記憶手段（記億部）と、ネットワークインタフェースとを有するコンピュータとして構成される。このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各種機能が実現される。
【００１６】
ここで、符号化速度は、「第１伝送速度情報」、「第２伝送速度情報」の一例である。
【００１７】
図２に示すように、リバースプロキシ１は、制御部１１と、データ送受信部１２と、セグメントキャッシュ部１３と、ファイル名・シーケンス番号管理部１４と、クライアント要求履歴管理部１５とを備える。制御部１１は、リバースプロキシ１が実行する処理を総合的に制御する。データ送受信部１２は、クライアント２ａ〜２ｎとWebサーバ３ａ〜３ｇとの間でやり取りされる情報の送受信をする。セグメントキャッシュ部１３は、Webサーバ３ａ〜３ｇから配信されたセグメントを高速に読み出し可能な状態で記憶する。
【００１８】
ここで、制御部１１は、「記憶処理部」の一例である。データ送受信部１２は、「第１送信処理部」、「第２送信処理部」、「第３送信処理部」の一例である。セグメントキャッシュ部１３は、「記憶部」の一例である。
【００１９】
リバースプロキシ１は、Webサーバ３ａ〜３ｇから受信したセグメントを、必要に応じてセグメントキャッシュ部１３にキャッシュしつつ、クライアント２ａ〜２ｎに転送することができる。
【００２０】
ファイル名・シーケンス番号管理部１４は、Webサーバ３ａ〜３ｇが配信するコンテンツを管理する。ファイル名・シーケンス番号管理部１４は、コンテンツを管理するためのテーブル１４Ａを有する。テーブル１４Ａのデータ構造を図３に示す。
【００２１】
一般に各動画コンテンツは、複数種類の符号化速度のファイルからなり、また、例えば、再生時間数秒から10秒程度のセグメントと呼ばれるファイルに分かれている。ファイル名・シーケンス番号管理部１４は、コンテンツ識別子ごとにテーブル１４Ａを格納している。コンテンツごとに、つまりコンテンツ識別子ごとに用意されたテーブル１４Ａは、符号化速度（x Mbps）、セグメント番号（segment xx）、セグメントのファイル名を関連付けている。
【００２２】
テーブル１４Ａはまた、各動画コンテンツのセグメント同士の関係も表している。すなわち、1つの動画コンテンツを１つのテーブルで表し、各行が１つの符号化速度、各列が各セグメントに対応し、対応するセグメントのファイル名を管理する。ただし、符号化速度、セグメント番号ともに昇順に整列する。本実施形態では、簡明さのために、各セグメントのファイル名は、“「コンテンツ識別子」_「符号化速度」「セグメント番号」”の形式としているが、どのようなファイル名でも構わない。また、セグメントの数、符号化速度の数も、図３に示すものに限らず、いくつでもよい。図３のテーブル１４Ａは、コンテンツ識別子が「123」であるコンテンツに対するテーブルである。符号化速度：1Mbps、セグメント番号「01」のファイル名は、“123_01m01”となる。
【００２３】
クライアント要求履歴管理部１５は、クライアント２ａ〜２ｎからのコンテンツ配信の要求の履歴を管理する。クライアント要求履歴管理部１５は、クライアント２ａ〜２ｎからの要求を管理するためのテーブル１５Ａを有する。テーブル１５Ａのデータ構造を図４に示す。
【００２４】
テーブル１５Ａは、クライアント２ａ〜２ｎからの要求ごとにエントリを生成し、要求ごとに、クライアントIPアドレス、クライアントポート番号、コンテンツ識別子、セグメント番号、符号化速度を関連付けている。「クライアントIPアドレス」は、要求を出力したクライアントのIPアドレスである。「クライアントポート番号」は、要求を出力したクライアントのコンテンツ視聴用のポート番号である。「コンテンツ識別子」は、要求対象のコンテンツの識別子である。「セグメント番号」は、要求対象のコンテンツ中の要求セグメントの識別子である。「符号化速度」は、要求対象のコンテンツの符号化速度である。
ここで、テーブル１５Ａは、「要求履歴情報」の一例である。
【００２５】
［動作］
本実施形態におけるリバースプロキシ１の動作例を説明する。説明の際、適宜図面を参照する。図５は、動画配信シーケンス図である。図６は、リバースプロキシの制御部の処理を示すフローチャートである。ここで、図５中、クライアント２は、図１のクライアント２ａ〜２ｎのいずれかである。また、図５中、Webサーバ３は、図１のWebサーバ３ａ〜３ｇのいずれかである。以下の動作の説明は、「クライアント２からの１回目の要求」、「クライアント２からの２回目の要求」、「クライアント２からの３回目の要求」の順に説明する。
【００２６】
＜クライアント２からの１回目の要求＞
まず、クライアント２は、利用者からの要求操作に応じ、リバースプロキシ１に対して接続を確立した後、コンテンツ識別子、符号化速度、セグメント番号を指定してセグメント要求を行う（図５ステップＰ１）。本動作例では、セグメント要求で指定する、コンテンツ識別子は「123」、符号化速度は「3M」、セグメント番号は1〜10であったとする。
ここで、クライアント２からリバースプロキシ１へのセグメント要求は、「第１要求情報」の一例である。
【００２７】
リバースプロキシ１のデータ送受信部１２が、クライアント２から受信したセグメント要求を制御部１１に送信すると、制御部１１は、当該セグメント要求を受信する（図６ステップＱ１）。制御部１１は、セグメント要求をしたクライアント２のクライアントIPアドレス、当該クライアント２のコンテンツ視聴用のポート番号、並びに、セグメント要求で要求された、コンテンツ識別子、符号化速度、および、セグメント番号を、クライアント要求履歴管理部１５に登録する（図６ステップＱ２）。その結果、例えば、図４中No.1のデータ（エントリ）が登録される。
【００２８】
次に、制御部１１は、ファイル名・シーケンス番号管理部１４を参照し、要求されたセグメント（セグメント要求で指定されたセグメント）に対応するセグメントファイル名を検索する（図６ステップＱ３）。本動作例では、「123_03m01〜123_03m10」が該当する。
【００２９】
次に、制御部１１は、要求されたセグメント（要求セグメント）がセグメントキャッシュ部１３に存在するか否かを検索する（図６ステップＱ４）。本動作例では、クライアント２からの要求が１回目であったため、「123_03m01〜123_03m10」のセグメントがセグメントキャッシュ部１３に存在しなかったとする。
【００３０】
次に、（セグメントキャッシュ部１３内に要求セグメントが存在していれば）制御部１１は、セグメントキャッシュ部１３に存在する要求セグメントを、データ送受信部１２に送信し（図６ステップＱ５）、データ送受信部１２がクライアント２に送信する（図５ステップＰ２）。本動作例では、セグメントキャッシュ部１３内に要求セグメントが存在していないため、クライアント２への送信はない。
【００３１】
よって、制御部１１は、要求されたセグメントを格納するWebサーバ３に対し、要求されたセグメントを、データ送受信部１２を通じて要求する（図５ステップＰ３）。本動作例では、制御部１１は、コンテンツ識別子「123」のコンテンツで「3M」セグメントを格納するWebサーバ３ｃ（図１）に対し、「123_03m01〜123_03m10」のセグメントを、データ送受信部１２を通じて要求する。
ここで、制御部１１を備えるリバースプロキシ１からWebサーバ３への、（クライアント２から）要求されたセグメントの要求は、「第２要求情報」の一例である。また、（クライアント２から）要求されたセグメント、つまり、要求セグメントは、「第１セグメント」の一例である。
【００３２】
また、制御部１１は、要求セグメントの要求と同時に、直近の要求セグメントの近傍セグメントを、当該近傍セグメントを格納するWebサーバ３に対し、データ送受信部１２を通じて要求する（図５ステップＰ３）。「直近の要求セグメント」とは、クライアント２からの最新のコンテンツ要求で指定されたセグメントのうち最後番のセグメントであり、本動作例では、１回目のコンテンツ要求で指定された「123_03m01〜123_03m10」のセグメントのうち、「123_03m10」のセグメントである。また、「近傍セグメント」とは、直近の要求セグメントに続くセグメントであって、直近の要求セグメントの符号化速度とは異なる符号化速度を有するセグメントである。図５ステップＰ３のために、制御部１１は、クライアント要求履歴管理部１５を参照し、直近の要求セグメントの近傍セグメントを決定する（図６ステップＱ６）。
ここで、制御部１１を備えるリバースプロキシ１からWebサーバ３への、近傍セグメントの要求は、「第３要求情報」の一例である。また、近傍セグメントは、「第２セグメント」の一例である。
【００３３】
（近傍セグメントの決定方法）
制御部１１による近傍セグメントの決定方法を説明する。ここでは、サイズe×sの近傍セグメントを決定する。ここで、eは、符号化速度の種類の数、sは、各符号化速度の近傍セグメントの時系列の数（近傍セグメントのセグメント番号の連続数）を表す。ネットワーク状況が変わりやすい環境では、eの値を大きくするとよく、逆に、ネットワーク状況が変わりにくい安定した環境では、eの値を小さくするとよい。ネットワーク状況が変わりやすさは、クライアント要求履歴管理部１５に保存されたクライアント２の要求履歴から判断することができる（詳細は後記）。また、sについては、要求セグメントの数や、クライアント要求履歴管理部１５に保存されたクライアント２の要求履歴から判断することができる（詳細は後記）。
【００３４】
本動作例では、ｓは、要求セグメントの数と同じとする。このため、最新のコンテンツ要求で指定されたセグメントの数、つまり、要求セグメントの数が10であったため、s=10とする。また、本動作例では、クライアント要求履歴管理部１５を参照すると、該当クライアント２からの要求が１回目であり、初めてのアクセスであることがわかるので、e=3（デフォルト値）とする。また、直近の要求セグメントは、すでに説明した通り、「123_03m10」のセグメント（図７符号Ｙ１）である。したがって、近傍セグメントは、ファイル名が「123_02m11〜123_02m20、123_03m11〜123_03m20、123_05m11〜123_05m20」のセグメント群（図７符号Ｚ１参照）が該当する。
【００３５】
図６に戻って説明を続ける。制御部１１は、決定した近傍セグメントがセグメントキャッシュ部１３に存在するか否かを検索する（図６ステップＱ７）。制御部１１は、セグメントキャッシュ部１３に存在しない近傍セグメントについては、当該近傍セグメントを格納するWebサーバ３に要求する。本動作例では、クライアント２からの要求が１回目であったため、近傍セグメントがセグメントキャッシュ部１３に全く存在しなかったとする。よって、制御部１１は、近傍セグメントの全体を該当のWebサーバ３に要求することになる。
【００３６】
なお、決定した近傍セグメントの少なくとも１部がセグメントキャッシュ部１３に存在していた場合、制御部１１は、当該セグメントに対するクライアント２からの要求に応じて配信する。例えば、過去に他のクライアント２からの要求に応じてセグメントキャッシュ部１３にキャッシュしていたセグメントが、今回決定した近傍セグメントに合致していた場合がある。
【００３７】
結果的に、本動作例では、制御部１１は、セグメントキャッシュ部１３に存在しない要求セグメントとして「123_03m01〜123_03m10」のセグメントを、3Mセグメントを格納するWebサーバ３ｃ（図１）に要求する。また、制御部１１は、セグメントキャッシュ部１３に存在しない近傍セグメントとして、「123_02m11〜123_02m20」のセグメントを、2Mセグメントを格納するWebサーバ３ｂ（図１）に要求し、「123_03m11〜123_03m20」のセグメントを、3Mセグメントを格納するWebサーバ３ｃ（図１）に要求し、「123_05m11〜123_05m20」のセグメントを、5Mセグメントを格納するWebサーバ３ｄ（図１）に要求する。
【００３８】
次に、制御部１１は、Webサーバ３からの応答によって、セグメントキャッシュ部１３に存在しない要求セグメントおよび近傍セグメントをWebサーバ３から取得する（図５ステップＰ４、図６ステップＱ８）。
【００３９】
次に、制御部１１は、Webサーバ３から取得した要求セグメントを、データ送受信部１２を通じてクライアント２に送信する（図５ステップＰ５、図６ステップＱ９）。本動作例では、制御部１１は、「123_03m01〜123_03m10」のセグメント、つまり、コンテンツ識別子「123」のコンテンツで符号化速度3Mbps の第１〜第１０セグメントのみをクライアント２に送信する。
なお、クライアント２は、リバースプロキシ１の制御部１１から取得した要求セグメントをデコードして表示装置に表示することができる。
【００４０】
次に、制御部１１は、Webサーバ３から取得した近傍セグメントをセグメントキャッシュ部１３に格納する（図６ステップＱ１０）。本動作例では、近傍セグメントとして、「123_02m11〜123_02m20」のセグメント、「123_03m11〜123_03m20」のセグメント、および、「123_05m11〜123_05m20」のセグメントをセグメントキャッシュ部１３に格納する。
以降、クライアント２から次のセグメント要求があると、図５、図６の処理を繰り返す。
【００４１】
（補足）
一般的に、近傍セグメントは以下のように定義することができる。
まず、符号化速度の種類の集合をC、セグメント番号の集合をSとする。図３の例に従った場合、
C={1Mbps, 2Mbps, 3Mbps, 5Mbps, 7Mbps, 10Mbps, 15Mbps}
S={1,2,3,…,99}
となる。
【００４２】
また、インデックスの集合E={1,2,3….}を定義する。また、集合Cから集合Eへの対応（関数）をfとする。符号化速度の大小に合わせてインデックスの大小を決める。図３の例に従った場合、集合E={1,2,3,4,5,6,7}であり、f(1Mbps)=1, f(2Mbps)=2, f(3Mbps)=3, f(5Mbps)=4, f(7Mbps)=5, f(10Mbps)=6, f(15Mbps)=7と定めることができる。
【００４３】
特定のコンテンツのコンテンツ識別子を「cid」と表し、cidの全セグメントの集合Fcidを
Fcid={Mcid(f(c), s)}
と表す。ここで、c∈C, s∈Sである。Mcidは、コンテンツ識別子「cid」のコンテンツ（コンテンツcidと記載する場合がある）の１つのセグメントを表す。図３の例に従った場合、cid=123であり、
F123={M123(f(1Mbps), 1), M123(f(1Mbps), 2), …, M123(f(1Mbps), 99), M123 (f(2Mbps), 1), …, M123 (f(2Mbps), 99), …, M123 (f(15Mbps), 99)}
となる。
【００４４】
クライアント２からコンテンツcid、 符号化速度c0、セグメント番号s’〜s0のセグメント要求があったとすると、直近セグメントファイルはMcid(f(c0), s0)となる。
【００４５】
c0に対応するインデックスをe0とする。すなわち、e0=f(c0)とする。
このとき、直近セグメントファイルMcid(f(c0), s0)に対応するサイズe1×s1の近傍セグメントの集合Nは以下のように定義される。
【００４６】
N={Mcid(e0-e1/2, s0+1), Mcid(e0-e1/2, s0+2), … , Mcid(e0-e1/2, s0+s1), … , 
Mcid(e0-e1/2+1, s0+1), Mcid(e0-e1/2+1, s0+2), … , Mcid(e0-e1/2+1, s0+s1), … ,
… ,
Mcid(e0, s0+1), Mcid(e0, s0+2), … , Mcid(e0, s0+s1), … ,
Mcid(e0+1, s0+1), Mcid(e0+1, s0+2), … , Mcid(e0+1, s0+s1), … ,
… ,
Mcid(e0+e1/2, s0+1), Mcid(e0+e1/2, s0+2),…, Mcid(e0+e1/2, s0+s1) } ∩  Fcid
または
N={Mcid(e0-e, s0+s)} ∩  Fcid  （-e1/2 ≦ e ≦ e1/2, 1≦ s ≦ s1）
e1の値は、デフォルトで決定されたり、ネットワークの状況に応じて決定されたりする。
【００４７】
＜クライアント２からの２回目の要求＞
クライアント２は自身の計算能力とネットワーク輻輳状況を考慮して、より符号化速度の高いセグメントの再生が可能と判断し、また、セグメントを多めに取得することに決定した。よって、クライアント２は、リバースプロキシ１に対して、上記判断、決定に応じたセグメント要求を行う（図５ステップＰ１）。本動作例では、セグメント要求で指定する、コンテンツ識別子は「123」、符号化速度は（「3M」→）「5M」、セグメント番号は11〜30であったとする。
【００４８】
リバースプロキシ１のデータ送受信部１２が、クライアント２から受信したセグメント要求を制御部１１に送信すると、制御部１１は、当該セグメント要求を受信する（図６ステップＱ１）。制御部１１は、セグメント要求をしたクライアント２のクライアントIPアドレス、当該クライアント２のコンテンツ視聴用のポート番号、並びに、セグメント要求で要求された、コンテンツ識別子、符号化速度、および、セグメント番号を、クライアント要求履歴管理部１５に登録する（図６ステップＱ２）。その結果、例えば、図４中No.2のデータ（エントリ）が登録される。
【００４９】
次に、制御部１１は、ファイル名・シーケンス番号管理部１４を参照し、要求されたセグメント（セグメント要求で指定されたセグメント）に対応するセグメントファイル名を検索する（図６ステップＱ３）。本動作例では、「123_05m11〜123_05m30」が該当する。
【００５０】
次に、制御部１１は、要求されたセグメント（要求セグメント）がセグメントキャッシュ部１３に存在するか否かを検索する（図６ステップＱ４）。本動作例では、クライアント２からの１回目の要求で「123_05m11〜123_05m20」をセグメントキャッシュ部１３に格納している（図６ステップＱ１０参照）。このため、「123_05m11〜123_05m20」のセグメントについては成功し、「123_05m21〜123_05m30」のセグメントについては、セグメントキャッシュ部１３に存在せず、失敗する。
【００５１】
次に、制御部１１は、セグメントキャッシュ部１３に存在する要求セグメントを、データ送受信部１２に送信し（図６ステップＱ５）、データ送受信部１２がクライアント２に送信する（図５ステップＰ２）。本動作例では、セグメントキャッシュ部１３に存在する要求セグメント「123_05m11〜123_05m20」をクライアント２に送信する。
ここで、セグメントキャッシュ部１３に存在するセグメントであって、クライアント２が要求し、クライアント２に送信するセグメントは、「第３セグメント」の一例である。「第３セグメント」は、過去に他のクライアント２からの要求に応じてセグメントキャッシュ部１３にキャッシュしていたセグメントも含む。例えば、過去に他のクライアントからの要求に対し、近傍セグメントとして「123_05m21〜123_05m30」がセグメントキャッシュ部１３にキャッシュされていた場合、制御部１１は、「123_05m11〜123_05m20」だけでなく、「123_05m21〜123_05m30」もクライアント２に送信することができる。
【００５２】
また、制御部１１は、要求されたセグメントを格納するWebサーバ３に対し、要求されたセグメントを、データ送受信部１２を通じて要求する（図５ステップＰ３）。本動作例では、制御部１１は、コンテンツ識別子「123」のコンテンツで「5M」セグメントを格納するWebサーバ３ｄに対し、セグメントキャッシュ部１３に存在しなかった「123_05m21〜123_05m30」のセグメントを、データ送受信部１２を通じて要求する。
【００５３】
また、制御部１１は、要求セグメントの要求と同時に、直近の要求セグメントの近傍セグメントを、当該近傍セグメントを格納するWebサーバ３に対し、データ送受信部１２を通じて要求する（図５ステップＰ３）。「直近の要求セグメント」は、本動作例では、２回目のコンテンツ要求で指定された「123_05m11〜123_05m30」のセグメントのうち、「123_05m30」のセグメントである。また、図５ステップＰ３のために、制御部１１は、クライアント要求履歴管理部１５を参照し、直近の要求セグメントの近傍セグメントを決定する（図６ステップＱ６）。
【００５４】
まず、近傍セグメントのサイズe×sを決定する。２回目の要求では、クライアント２が要求する符号化速度は5Mbpsに増えているが、クライアント要求履歴管理部１５を参照すると、クライアント２が起動して間もないことがわかるため、過渡期と判断し、eは同じ（デフォルト値のe=3）とする。また、要求するセグメント数が（10→）20に増えたため、s=20に変更する。e=3、s=20において、直近の要求セグメントは、すでに説明した通り、「123_05m30」のセグメント（図８符号Ｙ２）である。したがって、近傍セグメントは、ファイル名が「123_03m31〜123_03m50、123_05m31〜123_05m50、123_07m31〜123_07m50」のセグメント群（図８符号Ｚ２参照）が該当する。
【００５５】
図６に戻って説明を続ける。制御部１１は、決定した近傍セグメントがセグメントキャッシュ部１３に存在するか否かを検索する（図６ステップＱ７）。制御部１１は、セグメントキャッシュ部１３に存在しない近傍セグメントについては、当該近傍セグメントを格納するWebサーバ３に要求する。本動作例では、クライアント２からの２回目の要求に対して決定した近傍セグメントはセグメントキャッシュ部１３に存在しない。よって、制御部１１は、近傍セグメントの全体を該当のWebサーバ３に要求することになる。
【００５６】
結果的に、本動作例では、制御部１１は、セグメントキャッシュ部１３に存在しない要求セグメントとして「123_05m21〜123_05m30」のセグメントを、5Mセグメントを格納するWebサーバ３ｄ（図１）に要求する。また、制御部１１は、セグメントキャッシュ部１３に存在しない近傍セグメントとして、「123_03m31〜123_03m50」のセグメントを、3Mセグメントを格納するWebサーバ３ｃ（図１）に要求し、「123_05m31〜123_05m50」のセグメントを、5Mセグメントを格納するWebサーバ３ｄ（図１）に要求し、「123_07m31〜123_07m50」のセグメントを、7Mセグメントを格納するWebサーバ３ｅ（図１）に要求する。
【００５７】
次に、制御部１１は、Webサーバ３からの応答によって、セグメントキャッシュ部１３に存在しない要求セグメントおよび近傍セグメントをWebサーバ３から取得する（図５ステップＰ４、図６ステップＱ８）。なお、本動作例では、セグメントキャッシュ部１３に存在する２回目の要求セグメントの一部をWebサーバ３から取得することは無い。
【００５８】
次に、制御部１１は、Webサーバ３から取得した要求セグメントを、データ送受信部１２を通じてクライアント２に送信する（図５ステップＰ５、図６ステップＱ９）。本動作例では、制御部１１は、「123_05m21〜123_05m30」のセグメント、つまり、コンテンツ識別子「123」のコンテンツで符号化速度5Mbps の第２１〜第３０セグメントのみをクライアント２に送信する。要求された「123_05m11〜123_05m20」のセグメントは、送信済みである（図６ステップＱ５）。
なお、クライアント２は、リバースプロキシ１の制御部１１から取得した要求セグメントをデコードして表示装置に表示することができる。
【００５９】
次に、制御部１１は、Webサーバ３から取得した近傍セグメントをセグメントキャッシュ部１３に格納する（図６ステップＱ１０）。本動作例では、近傍セグメントとして、「123_03m31〜123_03m50」のセグメント、「123_05m31〜123_05m50」のセグメント、および、「123_07m31〜123_07m50」のセグメントをセグメントキャッシュ部１３に格納する。
以降、クライアント２から次のセグメント要求があると、図５、図６の処理を繰り返す。
【００６０】
＜クライアント２からの３回目の要求＞
クライアント２はネットワークに輻輳が発生していることを検知して、符号化速度を下げた方がよいと判断し、また、セグメントを少なめに取得することに決定した。よって、クライアント２は、リバースプロキシ１に対して、上記判断、決定に応じたセグメント要求を行う（図５ステップＰ１）。本動作例では、セグメント要求で指定する、コンテンツ識別子は「123」、符号化速度は（「5M」→）「3M」、セグメント番号は31〜40であったとする。
【００６１】
リバースプロキシ１のデータ送受信部１２が、クライアント２から受信したセグメント要求を制御部１１に送信すると、制御部１１は、当該セグメント要求を受信する（図６ステップＱ１）。制御部１１は、セグメント要求をしたクライアント２のクライアントIPアドレス、当該クライアント２のコンテンツ視聴用のポート番号、並びに、セグメント要求で要求された、コンテンツ識別子、符号化速度、および、セグメント番号を、クライアント要求履歴管理部１５に登録する（図６ステップＱ２）。その結果、例えば、図４中No.3のデータ（エントリ）が登録される。
【００６２】
次に、制御部１１は、ファイル名・シーケンス番号管理部１４を参照し、要求されたセグメント（セグメント要求で指定されたセグメント）に対応するセグメントファイル名を検索する（図６ステップＱ３）。本動作例では、「123_03m31〜123_03m40」が該当する。
【００６３】
次に、制御部１１は、要求されたセグメント（要求セグメント）がセグメントキャッシュ部１３に存在するか否かを検索する（図６ステップＱ４）。本動作例では、クライアント２からの２回目の要求で「123_03m31〜123_03m40」をセグメントキャッシュ部１３に格納している（図６ステップＱ１０参照）。このため、すべての要求セグメントについて成功する。
【００６４】
次に、制御部１１は、セグメントキャッシュ部１３に存在する要求セグメントを、データ送受信部１２に送信し（図６ステップＱ５）、データ送受信部１２がクライアント２に送信する（図５ステップＰ２）。本動作例では、セグメントキャッシュ部１３に存在するすべての要求セグメント「123_03m31〜123_03m40」をクライアント２に送信する。
【００６５】
また、制御部１１は、要求されたセグメントを格納するWebサーバ３に対し、要求されたセグメントを、データ送受信部１２を通じて要求する（図５ステップＰ３）。本動作例では、すべての要求セグメント「123_03m31〜123_03m40」が検索成功し、クライアント２に送信されるため、「3M」セグメントを格納するWebサーバ３ｃに対し、何ら要求することは無い。
【００６６】
また、制御部１１は、要求セグメントの要求と同時に、直近の要求セグメントの近傍セグメントを、当該近傍セグメントを格納するWebサーバ３に対し、データ送受信部１２を通じて要求する（図５ステップＰ３）。「直近の要求セグメント」は、本動作例では、３回目のコンテンツ要求で指定された「123_03m31〜123_03m40」のセグメントのうち、「123_03m40」のセグメントである。また、図５ステップＰ３のために、制御部１１は、クライアント要求履歴管理部１５を参照し、直近の要求セグメントの近傍セグメントを決定する（図６ステップＱ６）。
【００６７】
まず、近傍セグメントのサイズe×sを決定する。３回目の要求では、クライアント２が要求する符号化速度は3Mbpsに減少しており、クライアント要求履歴管理部１５を参照すると、過去２回でその都度要求する符号化速度が変わっていることから、ネットワーク環境は安定していないと判断（推定）し、eの値を大きくし、e=5とする。また、要求するセグメント数が（20→）10に減少したが、ネットワーク環境が安定していないことを考慮して、過去最大値のs=20のままとする。e=5、 s=20において、直近の要求セグメントは、すでに説明した通り、「123_03m40」のセグメント（図９符号Ｙ３）である。したがって、近傍セグメントは、ファイル名が「123_01m41〜123_01m60、123_02m41〜123_02m60、123_03m41〜123_03m60、123_05m41〜123_05m60、123_07m41〜123_07m60」のセグメント群（図９符号Ｚ３参照）が該当する。
【００６８】
図６に戻って説明を続ける。制御部１１は、決定した近傍セグメントがセグメントキャッシュ部１３に存在するか否かを検索する（図６ステップＱ７）。制御部１１は、セグメントキャッシュ部１３に存在しない近傍セグメントについては、当該近傍セグメントを格納するWebサーバ３に要求する。本動作例では、クライアント２からの２回目の要求に対して決定した近傍セグメントとして、123_03m41〜123_03m50、123_05m41〜123_05m50、123_07m41〜123_03m50がセグメントキャッシュ部１３に存在しているので、Webサーバ３への要求対象から除外する。よって、制御部１１は、近傍セグメントの残り、123_01m41〜123_01m60、123_02m41〜123_02m60、123_03m51〜123_03m60、123_05m51〜123_05m60、123_07m51〜123_07m60を該当のWebサーバ３に要求することになる。
【００６９】
結果的に、本動作例では、制御部１１は、３回目の要求セグメント「123_03m31〜123_03m40」のセグメントを、3Mセグメントを格納するWebサーバ３ｃ（図１）に要求しない。また、制御部１１は、セグメントキャッシュ部１３に存在しない近傍セグメントとして、「123_01m41〜123_01m60」のセグメントを、1Mセグメントを格納するWebサーバ３ａ（図１）に要求し、「123_02m41〜123_02m60」のセグメントを、2Mセグメントを格納するWebサーバ３ｂ（図１）に要求し、「123_03m51〜123_03m60」のセグメントを、3Mセグメントを格納するWebサーバ３ｃ（図１）に要求し、「123_05m51〜123_05m60」のセグメントを、5Mセグメントを格納するWebサーバ３ｄ（図１）に要求し、「123_07m51〜123_07m60」のセグメントを、7Mセグメントを格納するWebサーバ３ｅ（図１）に要求する。
【００７０】
次に、制御部１１は、Webサーバ３からの応答によって、セグメントキャッシュ部１３に存在しない要求セグメントおよび近傍セグメントをWebサーバ３から取得する（図５ステップＰ４、図６ステップＱ８）。なお、本動作例では、セグメントキャッシュ部１３に存在する、３回目の要求セグメントの全体および近傍セグメントの一部を、Webサーバ３から取得することは無い。
【００７１】
次に、制御部１１は、Webサーバ３から取得した要求セグメントを、データ送受信部１２を通じてクライアント２に送信する（図５ステップＰ５、図６ステップＱ９）。本動作例では、要求された「123_03m31〜123_03m40」のセグメントは、送信済みである（図６ステップＱ５）ため、制御部１１は、何もしない。
なお、クライアント２は、リバースプロキシ１の制御部１１から取得した要求セグメントをデコードして表示装置に表示することができる。
【００７２】
次に、制御部１１は、Webサーバ３から取得した近傍セグメントをセグメントキャッシュ部１３に格納する（図６ステップＱ１０）。本動作例では、近傍セグメントとして、「123_01m41〜123_01m60」のセグメント、「123_02m41〜123_02m60」のセグメント、「123_03m51〜123_03m60」のセグメント、「123_05m51〜123_05m60」のセグメント、および、「123_07m51〜123_07m60」のセグメントをセグメントキャッシュ部１３に格納する。
以降、クライアント２から次のセグメント要求があると、図５、図６の処理を繰り返す（説明略）。
【００７３】
≪まとめ≫
本実施形態によれば、クライアント要求履歴管理部１５を設けたので、リバースプロキシ１は、クライアント２からの要求に対して次の要求セグメントを予測し、クライアント２から要求されたセグメントだけでなく、次にクライアント２が要求すると予測されるセグメントも同時にWebサーバ３に要求し、セグメントキャッシュ部１３にキャッシュする。これにより、配信するコンテンツのセグメントのキャッシュヒット率を向上させることができる。
【００７４】
また、ネットワークの輻輳状況あっても、クライアント２が要求すると予測するセグメントとセグメントの数を変更することで動的に対応できるという効果が得られる。例えば、ネットワークが輻輳しているときは、低符号化速度のセグメントをキャッシュし、輻輳していないときは高符号化速度のセグメントをキャッシュすることで、輻輳の変化に適切に対応することができる。
【００７５】
また、ネットワーク輻輳状況が変動しやすいときは、多くのセグメントをキャッシュし、安定しているときは少なくキャッシュすることで、輻輳状況の変動しやすさにも対応することができる。
【００７６】
その上、リバースプロキシ１は自らネットワークの輻輳状況は調べることなく、クライアント２からの要求パラメータから判断するので、負荷を抑えることができる。
【００７７】
≪その他≫
本実施形態のリバースプロキシ１は、ネットワークの輻輳状況を、クライアント要求履歴管理部１５に保存されたクライアント２の要求履歴から判断した。しかし、例えば、リバースプロキシ１が、ネットワークのトラヒックを監視する外部の監視装置からトラヒック情報を取得し、トラヒック情報に基づいてネットワークの輻輳状況を判断してもよい。
【符号の説明】
【００７８】
１      リバースプロキシ
２、２ａ〜２ｎ  クライアント
３、３ａ〜３ｇ  Webサーバ
１１    制御部
１２    データ送受信部
１３    セグメントキャッシュ部
１４    ファイル名・シーケンス番号管理部
１５    クライアント要求履歴管理部
【図１】
2019146124.tif 000003
【図２】
2019146124.tif 000004
【図３】
2019146124.tif 000005
【図４】
2019146124.tif 000006
【図５】
2019146124.tif 000007
【図６】
2019146124.tif 000008
【図７】
2019146124.tif 000009
【図８】
2019146124.tif 000010
【図９】
2019146124.tif 000011