JP2009265932A - データ転送方法とプロキシサーバおよびストレージサブシステム - Google Patents

Abstract

【課題】プロトコルヘッダが配信要求毎に異なるときでも、プロトコルヘッダの生成に伴う処理をより少なくして、プロトコルヘッダとコンテンツをクライアントに配信すること。
【解決手段】プロキシサーバ１０は、クライアント１８からの配信要求で指定されたプロトコルヘッダとコンテンツが記憶装置２８に存在しないときには、配信要求をオリジンサーバ１２に転送し、オリジンサーバ１２から送信されたプロトコルヘッダとコンテンツを記憶装置２８に保存するとともにクライアント１８に送信し、且つオリジンサーバ１２から送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成して記憶装置２８に保存し、クライアント１８からの配信要求で指定されたプロトコルヘッダとコンテンツが記憶装置２８に存在するときには、これらを記憶装置２８から抽出してクライアント１８に配信する。
【選択図】図１

Description

本発明は、映像、音などのコンテンツをクライアントに配信する技術に関する。

近年、インターネットの急速な発展に伴い、HTML(Hyper Text Markup Language)で記述したファイルであるコンテンツをHTTP(Hyper Text Transfer Protocol)を用いてWWW(World Wide Web)サーバからクライアントに転送し、WWWブラウザで出力するWWWシステムが広く活用されている。

また、一般家庭へのブロードバンド回線普及や高性能なPC(Personal Computer)の普及に伴い、ネットワークを利用した高画質、大容量な動画をストリーミング配信するサービスが簡単に実現可能となっている。このストリーミング配信では、クライアント（クライアント端末）から配信サーバへリクエストメッセージを送信し、その応答として、配信サーバが、動画データをヘッダと共にクライアントに送信することが行われている。この際、クライアントは、そのデータを解釈して再生することができる。

現在のストリーミング配信の課題として、配信サーバの処理能力に限界がある。すなわち、配信サーバ１台当たりの配信数には制限がある。このため、多数のクライアントからのリクエストに対して、十分な品質でコンテンツを配信するためには、複数台の配信サーバを配置して、クライアントの要求に応える必要がある。

複数台のサーバを配置する方法としては、単純にサーバを並列配置し、クライアントからのリクエストを各サーバに分散させる方法や、コンテンツファイルを各サーバで共有し、各サーバが共有のコンテンツファイルから読み出す方法がある。

しかし、これらの方法では、コンテンツを保管するストレージの容量、多重読出し処理による性能低下が発生する。

そこで、オリジナルのコンテンツを有する配信サーバ（オリジンサーバ）の前段に、プロキシサーバを配置し、頻繁にクライアントからリクエストされるコンテンツをプロキシサーバにキャッシュデータとして保存し、クライアントから、プロキシサーバへ同一コンテンツのリクエストが到着した場合には、プロキシサーバは、オリジンサーバへアクセスすることなく、クライアントに応答を返すとともに、プロキシサーバに接続されている記憶装置にパケットをキャッシュデータとして保存するようにしたものが提案されている（特許文献１参照）。

また、オリジンサーバの前段にプロキシサーバを配置し、クライアントから配信要求を受けたプロキシサーバが、配信要求をオリジンサーバへ転送し、オリジンサーバが、プロトコルヘッダを付与するとともに、プロトコルヘッダが付与されたパケットをプロキシサーバに配信し、これを受けたプロキシサーバが、オリジンサーバから送信されたパケットの宛先をクライアントへと変更してクライアントに配信すると同時に、ストリーミングのパケットをキャプチャし、プロトコルヘッダや送信タイミングなどを記録したデータ（ヒントファイル）とコンテンツデータ（パケットファイル）をキャッシュデータとしてストレージに格納するようにしたものが提案されている（特許文献２参照）。
特開２００４−７０８６０号公報 特開２００５−２９５４６７号公報

前記従来技術のうち前者のものは、キャッシュデータとしてコンテンツのみを記憶装置に保存する構成を採用しているので、プロトコルヘッダの配信時に、プロキシサーバが、プロトコルヘッダにコンテンツデータを付与する必要がある。この結果、同一コンテンツへの要求がプロキシサーバに頻繁に届いた場合、毎回コンテンツデータにプロトコルヘッダを付与する処理が発生し、プロキシサーバの負荷が上昇することになる。

一方、後者のものは、ネットワークを流れるパケットのプロトコルは、動画配信プロトコルに依存しない形式であることを考慮している。このため、プロキシサーバは、動画配信プロトコル固有の処理を理解する機能を持つ必要がないとともに、キャッシュデータとして保存されているプロトコルと同一プロトコルで再度クライアントから要求された場合には、要求されたプロトコルをクライアントに配信可能である。しかし、クライアントから要求されたコンテンツが同一であってもプロトコルが異なった場合、プロキシサーバは、オリジンサーバからプロトコルヘッダとデータ本体を取得する必要があり、オリジンサーバとプロキシサーバとの間のネットワーク帯域を消費しやすくなる。

本発明の目的は、配信要求で指定されたプロトコルヘッダが配信要求毎に異なるときでも、プロトコルヘッダの生成に伴う処理をより少なくして、プロトコルヘッダとコンテンツをクライアントに配信することができるデータ転送方法とプロキシサーバおよびストレージサブシステムを提供することにある。

前記目的を達成するために、本発明は、クライアントからの配信要求を識別して、配信要求で指定されたプロトコルヘッダとコンテンツが記憶部に保存されていないことを条件に、配信要求をオリジンサーバに転送し、オリジンサーバから送信されたプロトコルヘッダとコンテンツを記憶部に保存するとともに、クライアントに送信し、且つオリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成し、生成した他のプロトコルヘッダとコンテンツを互いに関連付けて記憶部に保存し、クライアントからの配信要求で指定されたプロトコルヘッダとコンテンツが記憶部に保存されているときには、保存されているプロトコルヘッダとコンテンツをクライアントに配信することを特徴とするものである。

本発明によれば、配信要求で指定されたプロトコルヘッダが配信要求毎に異なるときでも、プロトコルヘッダの生成に伴う処理をより少なくして、プロトコルヘッダとコンテンツをクライアントに配信することができる。

以下、本発明の実施形態を図面に基づいて説明する。図１は、本発明に係るストレージサブシステムの一実施例を示すブロック構成図である。図１において、ストレージサブシステムは、プロキシサーバ１０と、オリジンサーバ１２を備えており、NAS（Network Attached Storage）のハードウエアとして、通信ネットワークとしてのLAN（Local Area Network）１４を介してオリジンサーバ１２に接続されている。さらにプロキシサーバ１０は、通信ネットワークとしてのインターネット１６を介してクライアント（クライアント端末）１８に接続されている。

プロキシサーバ１０は、プロキシサーバ１０全体の処理を統括するCPU（Central Processing Unit）２０と、各種情報を記憶する主メモリ２２と、ネットワークインターフェイス２４と、管理インターフェイス２６と、記憶部としての記憶装置２８と、内部バス３０を備えて構成されており、各部は内部バス３０を介して互いに接続されている。ネットワークインターフェイス２４は、LAN１４とインターネット１６に接続され、管理インターフェイス２６は、保守用管理PC３２に接続されている。

CPU２０は、主メモリ２２と記憶装置２８のデータを読み書きし、プログラムにしたがって各種のデータ処理を実行するようになっている。この際、CPU２０は、記憶装置２８からプログラムを読出し、読み出したプログラムを主メモリ２２にロードするようになっている。

主メモリ２２には、管理テーブル３４が格納され、記憶装置２８には、OS（Operating System）として、要求転送プログラム３６と要求処理プログラム３８が格納されているとともに、受信部４０として、パケットキャプチャ制御プログラム４２とヘッダ変換プログラム４４が格納され、配信部４６として、配信手段プログラム４８とファイル選択プログラム５０が格納されている。すなわち、OSに関連するプログラムは主メモリ２２にロードされている。

オリジンサーバ１２は、LAN１４に接続されたインターフェイス５２、各種プログラムが格納された記憶装置５４、プログラムに基づいてプロキシサーバ１０と情報の授受を行うCPU（図示せず）を備えて構成されている。

CPU２０、主メモリ２２、ネットワークインターフェイス２４は、図２および図３に示すように、制御部５６として構成され、管理テーブル３４には、図４に示すように、キャッシュリストテーブル５８、プロトコル変換テーブル６０、ヘッダ変換キューテーブル６２、過負荷判定用テーブル６４が格納されている。

キャッシュリストテーブル５８は、図５（a）に示すように、コンテンツ名の識別子が格納されたコンテンツ名フィールド６６、プロトコル名が格納されたプロトコルフィールド６８、コンテンツの容量が格納されたサイズフィールド７０から構成されている。

プロトコル変換テーブル６０は、図５（b）に示すように、元のプロトコルの名称を示す元プロトコルフィールド７２、変換後の新たなプロトコル名を示す新プロトコルフィールド７４から構成されている。

ヘッダ変換キューテーブル６２は、図５（c）に示すように、コンテンツ名の識別子が格納されるコンテンツ名フィールド７６、変換先のプロトコルを示す変換先プロトコルフィールド７８、登録時刻を示す登録時刻フィールド８０から構成されている。

過負荷判定テーブル６４は、図５（d）に示すように、稼働率の閾値が格納される稼働率閾値フィールド８２、ヘッダ変換を実施するときの負荷判定に用いる最長待ち時間を示す最長待ち時間フィールド８４から構成されている。なお、これらのテーブルでは、プロトコルとしてHTTP、RTSP（Real-Time Streaming Protocol）を用いた例を示している。

制御部５６は、要求処理手段部８６と、要求転送手段部８８と、パケットキャプチャ手段部９０と、ヘッダ変換手段部９２と、配信手段部９４と、ファイル選択手段部９６としての機能を備えている。ヘッダ変換手段部９２は、図６に示すように、ヘッダ変換エンジン部９８と、ヘッダ互換判定部１００と、デキュー実行判断部１０２としての機能を備えている。

次に、制御部５６の具体的な内容について説明する。まず、要求処理手段部８６の処理を図７のフローチャートに従って説明する。要求処理手段部８６は、図７に示すように、クライアント１８からの配信要求（プロトコル+コンテンツ名）を受けたときに、管理テーブル３４を参照し、配信要求で指定されたプロトコルとコンテンツ名を解釈し（S１）、プロトコルとコンテンツの組み合わせがヒットしたか否かを判定する（S２）。ヒットしないとき、すなわち、プロトコルとコンテンツの組合せが記憶装置２８に保存されていないと判定したとき、要求処理手段部８６は、記憶装置２８に、プロトコルとコンテンツ名がキャッシュデータとして保存されていないとして、要求転送手段部８８をコールし（S３）、このルーチンでの処理を終了する。

一方、要求処理手段部８６は、プロトコルとコンテンツの組合せがヒットしたときには、これらのデータがキャッシュデータとして記憶装置２８に保存されているとして、配信手段部２４をコールし（S４）、このルーチンでの処理を終了する。

要求転送手段部８８は、図８に示すように、プロトコルとコンテンツの組合せがキャッシュデータとして記憶装置２８に保存されていないとして、プロトコルとコンテンツの要求をオリジンサーバ１２に送信し、このルーチンでの処理を終了する（S１１）。

このあと、オリジンサーバ１２は、要求転送手段部８８からの指示に応答して、ヘッダ生成手段部１０４を起動し、ヘッダ生成手段部１０４により、指示に従ってヘッダを生成し、生成したヘッダにコンテンツを付与した配信データを受信部４０に送信する。このあと受信部４０は、パケットキャプチャ手段部９０の処理によってパケットキャプチャを実行する。

具体的には、パケットキャプチャ手段部９０は、図９に示すように、流れているパケットが、キャッシュされていないコンテンツとヘッダの組合せか否かを判定し（S２１）、肯定の判定結果を得たときには、ヘッダキュー変換テーブル６２にコンテンツ名、変換先プロトコル、登録時刻を登録し（S２２）、且つパケットを記憶装置２８に登録し（S２３）、パケットを配信部４６へ転送し（S２４）、EOF（End Of File）か否かを判定し（S２５）、EOFとなるまでS２３からS２５の処理を繰り返し、EOFとなったときには、このルーチンでの処理を終了する。

一方、パケットキャプチャ手段部９０は、ステップS２１で否定の判定結果を得たときには、パケットを配信部４６へ転送し（S２６）、EOFか否かを判定し（S２７）、EOFとなるまでステップS２６の処理を繰り返し、EOFとなったときには、このルーチンでの処理を終了する。

次に、ヘッダ変換手段部９２の処理を図１０のフローチャートにしたがって説明する。ヘッダ変換手段部９２は、オリジンサーバ１２から送信されたヘッダを基に別の動画配信プロトコルヘッダを生成するために、過負荷判定用テーブル６４を参照し、負荷の状態から、ヘッダ変換が可能か否かを判定し（S３１）、肯定の判定結果を得たときには、ヘッダ変換エンジン部９８に、ヘッダ変換を実行させ（S３２）、このルーチンでの処理を終了する。

一方、ヘッダ変換手段部９２は、ステップS３１で否定の判定結果を得たときには、その理由は過負荷か否かを判定し（S３３）、過負荷であると判定したときには、過負荷が解消されるのを待つためにステップS３１の処理に戻り、理由は過負荷でないときには、設定された時間を経過してもヘッダの変換が不可能な場合あるいは直接の変換が難しいヘッダ同士、例えば、データ全体を参照しないとヘッダ交換ができないプロトコルに変換する場合などには、オリジンサーバ１２でのヘッダの変換を指示し（S３４）、このルーチンでの処理を終了する。

次に、ヘッダ互換判定部１００の処理を図１１のフローチャートにしたがって説明する。ヘッダ互換判定部１００は、オリジンサーバ１２からの配信データを取り込み、この配信データからコンテンツ名とプロトコルを取り出し（S４１）、取り出したプロトコルがプロトコル変換テーブル７４にマッチするか否かを判定し（S４２）、オリジンサーバ１２からの配信データから取り出したプロトコルがプロトコル変換テーブル７４とマッチすると判定したときには、ヘッダキュー変換テーブル６２を参照し、変換キューは満杯であるか否かを判定し（S４３）、満杯でないときにはヘッダ変換キューテーブル６２に変換先プロトコルを追加し（S４４）、このルーチンでの処理を終了する。

一方、ヘッダ互換判定部１００は、クライアント１８からの配信要求で指定されたプロトコルがプロトコル変換テーブル６２にマッチしていないと判定したときには、オリジンサーバ１２へ要求を転送し（S４５）、このルーチンでの処理を終了する。

次に、ヘッダ変換エンジン部９８の処理を図１２のフローチャートにしたがって説明する。ヘッダ変換エンジン部９２は、オリジンサーバ１０４からのヘッダを基に別の動画配信プロトコルヘッダに変換可能であるときに、元のパケットサイズを読み込み（S５１）、変換先のプロトコルヘッダ固定部分を生成し（S５２）、シーケンスナンバーなどの動的値を生成し（S５３）、このルーチンでの処理を終了する。

次に、デキュー実行判断部１０２の処理を図１３のフローチャートにしたがって説明する。デキュー実行判断部１０２は、キューにジョブがあるか否かを判定し（S６１）、キューにジョブがあることを条件に、負荷が閾値以下であるか否かを判定し（S６２）、負荷が閾値以下であると判定したときには、ヘッダ変換エンジン部９８をコールし（S６３）、ヘッダ変換エンジン部９８の処理が終了するのを待ち（S６４）、待ち時間をリセットし（S６５）、キューからジョブを削除し（S６６）、このルーチンでの処理を終了する。

一方、デキュー実行判断部１０２は、負荷が閾値よりも高いと判定したときには、キューの末端のジョブか否かを判定し（S６７）、キューの末端のジョブであるときには、このルーチンでの処理を終了し、キューの末端のジョブでないと判定したときには、待ち時間制限値を越えているジョブか否かを判定し（S６８）、待ち時間制限値を越えているジョブのときにはオリジンサーバ１２へ要求を転送し（S６９）、キューからジョブを削除し（S７０）、一方、待ち時間制限値を越えているジョブでないと判定したときには、待ち時間を更新し（S７１）、次のジョブへ移行するための処理を行い（Ｓ７２）、ステップＳ６７の処理に戻る。

次に、パケットキャプチャとヘッダ変換処理の具体的内容を図１４に示す。オリジンサーバ１２とプロキシサーバ１０との間およびプロキシサーバ１０とクライアント１８との間では、データリンク層フレーム２００で構成された動画配信パケットの授受が行われる。データリンク層フレーム２００はIP（Internet Protocol）ヘッダ２０２、TCP（Transmission Control Protocol）/UDP（User Datagram Protocol）ヘッダ２０４、動画配信ヘッダ２０６、動画データn２０８から構成されている。

この際、データリンク層フレーム２００で構成された動画配信パケットは、コンテンツごとにパケットに分割され、分割されたコンテンツにヘッダが付与されて送信される。これは、動画配信ヘッダは、動画データに依存して内容が決定されるため、予め生成が可能である。この際、ヒントファイルとしてのプロトコルAは、制御情報として、配信時刻２１０、先頭から何番目のファイルかを示すオフセット２１２、サイズ２１４で構成され、データパケットファイル２１６は、動画配信ヘッダ２１８、＃１の動画データ２２０、＃２の動画データ２２２、＃３の動画データ２２４、＃４の動画データ２２６、＃５の動画データ２２８で構成される。そしてプロキシサーバ１０では、プロトコルAを基にプロトコルAとは異なるプロトコルBを生成する。このプロトコルＢは、制御情報として、配信時刻２３０、オフセット２３２、サイズ２３４で構成される。データパケットファイル２３６は、動画配信ヘッダ２３８、＃１の動画データ２２０、＃２の動画データ２２２、＃３の動画データ２２４、＃４の動画データ２２６、＃５の動画データ２２８で構成される。プロトコルＡ、Ｂは、キャプチャデータとして記憶装置２８に保存されるとともに、パケットを再構築する際、データリンク層フレーム２００に付加されてクライアント１８に配信される。

次に、図１５に、HTTPヘッダ３００の構成とRTP（Real-time Transport Protocol）ヘッダ３０２の例を示す。

HTTPヘッダ３００は、項目として、HTTPボディ３０４、CRLF３０６、コマンド３０８、長さ３１０、シーケンスナンバー３１２、ID３１４、フラグ３１６、長さ３１８を備えている。HTTPボディ３０４には、ヘッダ生成時に生成されたデータパケットサイズが格納され、シーケンスナンバー３１２には、ヘッダ生成時に動的に生成されたナンバーが格納され、フラグ３１６には、ヘッダ生成時に生成された、「００」、「０４」、「０８」などの数値が格納される。なお、他の項目は固定された値となっている。

RTPヘッダ３０２は、バージョン３２０、パディング３２２、拡張子３２４、CSRC（Contributing Source）３２６、マーカ３２８、ペイロードタイプ３３０、シーケンスナンバー３３２、PTS（Presentation Time Stamp）３３４、SSID３３６、オフセット値３３８の項目で構成されている。

次に、ヘッダをHTTPヘッダからRTPヘッダに変換するときの処理を図１６のフローチャートにしたがって説明する。ヘッダ変換エンジン部９８は、バージョン３２０を１０bとし（S８１）、RTPデータパケットに含めるHTTPデータパケット数U＝RTPパケットサイズ/HTTPパケットサイズとし（S８２）、Uが整数であるか否かを判定し（S８３）、Uが整数のときにはパディング３２２を０とし（S８４）、Uが整数でないときには、Uの少数部分を切り捨て（S８５）、パディング３２２を１とし（S８６）、そのあと拡張子３２４を０とし（S８７）、CSRC３２６を００００bとし（S８８）、末尾のパケットか否かを判定する（S８９）。

このあと、ヘッダ変換エンジン部９８は、パケットが末尾のパケットのときには、マーカ３２８を１とし（S９０）、パケットが末尾のパケットでないときにはマーカ３２８を０とし（S９１）、そのあとペイロード３３０を１１０００００bとし（S９２）、シーケンスナンバー３３２を先頭からの通しナンバーとし（S９３）、PTS３３４を、先頭から順に付与された再生時刻とし（S９４）、Synchronization ID＝NULLとし（S９５）、オフセット値３３８を、直前までに送信したバイト数とし（S９６）、ヘッダにデータパケットを付与し（S９７）、Uの数だけデータパケットを付与したか否かを判定し（S９８）、Uの数だけデータパケットを付与したときにはこのルーチンでの処理を終了し、それ以外のときにはデータパケットを追加し（S９９）、ステップS９８の処理を繰り返す。これにより、HTTPヘッダ３００をRTPヘッダ３０２に変換することができる。

次に、配信手段部９４の処理を図１７のフローチャートにしたがって説明する。配信手段部９４は、配信時に、記憶装置２８からファイルを選択し（S１０１）、クライアント１８へヘッダとコンテンツ本体を配信（送信）し（S１０２）、このルーチンでの処理を終了する。

次に、クライアント１８からの配信要求に応答してプロキシサーバがキャッシュデータを保存するときの動作として、低負荷時の処理を図１８にしたがって説明する。クライアント１８からプロトコルAのコンテンツ１を含む配信要求がプロキシサーバ１０に送信されたときに、プロキシサーバ１０は、要求処理手段部８６を起動する。要求処理手段部８６は管理テーブル３４を参照し、記憶装置２８に、配信要求で指定されたプロトコルAのコンテンツ１が存在しないときにはコンテンツ１の配信要求を、要求転送手段部８８からオリジンサーバ１２へ送信させる。

オリジンサーバ１２は、プロキシサーバ１０からの配信要求を受けると、ヘッダ生成手段部１０４を起動し、プロトコルAのヘッダを生成し、生成したヘッダにコンテンツ１を付与してプロキシサーバ１０へ送信する。

プロキシサーバ１０は、プロトコルAのヘッダとコンテンツ１を配信手段部９４からクライアント１８に送信する。それと同時に、パケットキャプチャ手段部９０は、プロトコルAのヘッダとコンテンツ１を記憶装置２８に保存するとともに、ヘッダ変換キューテーブル６２にヘッダ変換ジョブを登録する。この際、ヘッダ変換手段部９２は、プロキシサーバ１０のヘッダの生成や配信に伴う負荷が低い場合は、即座にヘッダ変換キューテーブル６２からジョブを取り出し、別のプロトコルヘッダ、例えば、プロトコルB用のヘッダを生成し、生成したプロトコルBのヘッダにコンテンツを付与し、別のキャッシュデータとして記憶装置２８に保存する。

次に、過負荷時の処理を図１９にしたがって説明する。クライアント１８からプロトコルAのコンテンツ１を含む配信要求がプロキシサーバ１０に送信されたときに、プロキシサーバ１０は、記憶装置２８に配信要求で指定されたプロトコルAのコンテンツが存在しないときには、オリジンサーバ１２へ配信要求を転送する。この処理までは、図１８の場合と同様であるが、オリジンサーバ１２からプロトコルAのヘッダにコンテンツ１が付与されたデータがプロキシサーバ１０に送信され、プロキシサーバ１０において、オリジンサーバ１２からのプロトコルAのヘッダを基に別のヘッダを生成するときに、ヘッダ変換手段部９２が負荷の状態を監視し、過負荷状態と判定したときにはプロトコルAのキャプチャは実施するが、変換ジョブをヘッダ変換キューテーブル６２に溜めるための処理を行う。

この際、ヘッダ変換手段部９２は、一定の時間間隔をおいて、キューに変換ジョブがあるか否か、すなわち過負荷状態であるか否かを監視し、過負荷状態が解消されたことを条件に、キューに変換ジョブが残っている場合、プロトコルヘッダの変換処理を開始する。一方、過負荷状態が一定時間あるいは設定時間以上継続していると判断したときには、ヘッダ変換手段部９２は、オリジンサーバ１２に対して、他のプロトコルヘッダの生成を指示し、オリジンサーバ１２で生成されたプロトコルヘッダ、例えば、プロトコルBヘッダをキャプチャし、記憶装置２８にキャッシュデータとして保存する。

次に、過負荷状態継続時の処理を図２０にしたがって説明する。プロキシサーバ１０における過負荷状態が継続され、過負荷状態が解消されないときには、ヘッダ変換手段部９２は、オリジンサーバ１２に対してプロトコルヘッダの生成を指示する。このあとオリジンサーバ１２から指定のプロトコルヘッダ、例えば、プロトコルBヘッダが転送されたときには、先に記憶装置２８にキャプチャデータとして保存したコンテンツ本体とともに記憶装置２８にキャッシュデータとして保存するとともに、キャッシュリストテーブル５８にその内容を登録する。

次に、同一コンテンツであって別のプロトコルの要求がクライアントからあったときの処理を図２１にしたがって説明する。クライアント１８から、以前の配信要求で指定されたプロトコルAヘッダとはプロトコルは異なるがコンテンツは同一の配信要求、例えば、プロトコルBとコンテンツ１を含む配信要求が送信されたときに、要求処理手段部８６は、同一コンテンツであって、キャッシュ済みのプロトコルであると判別したときには、ファイルの選択をファイル選択手段９６に指示する。ファイル選択手段部９６は、記憶装置２８からプロトコルBヘッダとコンテンツ１のデータを記憶装置２８から抽出して配信手段部９４に出力する。配信手段部９４は、抽出したプロトコルBヘッダとコンテンツ１のデータをクライアント１８に配信する。

このときクライアント１８は、プロトコルＢヘッダとコンテンツ１のデータを解釈し、コンテンツ１の再生を開始する。なお、この際、プロトコルBが記憶装置２８に保存されていないときには、要求転送手段部８８からオリジンサーバ１２に対してプロトコルBのヘッダの生成を指示することになる。

上記の処理によって、コンテンツのデータ本体が同一で、ヘッダだけが異なる場合には、プロキシサーバ１０内のデータを使用することができる。この際、記憶装置２８には、プロトコルAヘッダ+コンテンツ１のデータと、プロトコルBヘッダ+コンテンツ１のデータが保存されるため、データ量がほぼ２倍となる。この際、各プロトコルごとにヘッダを生成し、生成したヘッダとコンテンツのデータとを記憶装置２８の異なる記憶領域に保存し、配信時に、各記憶領域に保存されていたヘッダとコンテンツデータを結合して配信する構成を採用することもできる。

本実施形態によれば、プロキシサーバ１０は、クライアント１８からの配信要求を識別して、配信要求で指定されたプロトコルヘッダとコンテンツが記憶装置２８に保存されていないときには、配信要求をオリジンサーバ１２に転送し、オリジンサーバ１２から送信されたプロトコルヘッダとコンテンツを記憶装置２８に保存するとともにクライアント１８に送信し、且つオリジンサーバ１２から送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成し、他のプロトコルヘッダとコンテンツを互いに関連付けて記憶装置２８に保存し、クライアント１８からの配信要求で指定されたプロトコルヘッダとコンテンツが記憶装置２８に保存されているときには、プロトコルヘッダとコンテンツを記憶装置２８から抽出してクライアント１８に配信するようにしたため、配信要求で指定されたプロトコルヘッダが配信要求毎に異なるときでも、プロトコルヘッダの生成に伴う処理をより少なくして、プロトコルヘッダとコンテンツをクライアントに配信することができる。

本発明の一実施形態を示すストレージサブシステムのブロック構成図。 オリジンサーバとプロキシサーバおよびクライアントとの関係を説明するためのブロック図。 制御部の構成図。 管理テーブルの構成図。 キャッシュリストテーブルと、プロトコル変換テーブルと、ヘッダ変換キューテーブルおよび過負荷判定テーブルの構成図。 ヘッダ変換手段部の構成図。 要求処理手段部の処理を説明するためのフローチャート。 要求転送手段部の処理を説明するためのフローチャート。 パケットキャプチャ手段部の処理を説明するためのフローチャート。 ヘッダ変換手段部の処理を説明するためのフローチャート。 ヘッダ互換判定部の処理を説明するためのフローチャート。 ヘッダ変換エンジン部の処理を説明するためのフローチャート。 デキュー実行判断部の処理を説明するためのフローチャート。 オリジンサーバとプロキシサーバおよびクライアント間で送受信される動画配信パケットの構成を説明するための図。 HTTPヘッダとRTPヘッダの構成図。 HTTPヘッダをRTPヘッダに変換するときの処理を説明するためのフローチャート。 配信手段部の処理を説明するためのフローチャート。 新規にキャッシュするときの処理であって、低負荷時の処理を説明するための構成図。 新規にキャッシュするときの処理であって、過負荷時の処理を説明するための構成図。 過負荷状態継続時の処理を説明するための構成図。 同一コンテンツであって異なるプロトコルが要求されたときの処理を説明するための構成図。

符号の説明

１０ プロキシサーバ、１２ オリジンサーバ、１６ クライアント、２０ CPU、２２ 主メモリ、２８ 記憶装置、８６ 要求処理手段部、８８ 要求転送手段部、９０ パケットキャプチャ手段部、９２ ヘッダ変換手段部、９４ 配信手段部 、９６ ファイル選択手段部、９８ ヘッダ変換エンジン部、１００ ヘッダ互換判断部、１０２ デキュー実行判断部

Claims (15)

1. クライアントおよびオリジンサーバと通信ネットワークを介して情報の授受を行うとともに前記情報を処理する制御部と、前記制御部の処理に伴う情報を記憶する記憶部とを備え、
   前記制御部は、前記クライアントからの配信要求を識別して、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に保存されていないときには、前記配信要求をオリジンサーバに転送するステップと、前記転送された配信要求に応答して前記オリジンサーバから送信されたプロトコルヘッダとコンテンツを前記記憶部に保存するステップと、前記転送された配信要求に応答して前記オリジンサーバから送信されたプロトコルヘッダとコンテンツを前記クライアントに送信するステップと、前記転送された配信要求に応答して前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するステップと、当該ステップで生成した他のプロトコルヘッダと前記コンテンツを互いに関連づけて前記記憶部に保存するステップと、前記クライアントからの配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に保存されているときには、当該プロトコルヘッダとコンテンツを前記記憶部から抽出して前記クライアントに配信するステップを実行する、データ転送方法。
2. 前記制御部は、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、プロトコル毎にヘッダを生成するステップを実行するとともに、前記ステップで生成したヘッダを前記記憶部の記憶領域のうち前記コンテンツとは異なる記憶領域に保存するステップと、前記クライアントへの配信時に、前記コンテンツとは異なる記憶領域に保存されているヘッダと前記コンテンツとを結合して前記クライアントに配信するステップを実行する、請求項１に記載のデータ転送方法。
3. 前記制御部は、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、前記他のプロトコルヘッダの生成に伴う負荷の状態を判定するステップと、前記ステップで前記負荷の状態が過負荷でないことを条件に前記他のプロトコルヘッダを生成するステップを実行する、請求項１に記載のデータ転送方法。
4. 前記制御部は、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、前記他のプロトコルヘッダの生成に伴う負荷の状態を判定するステップと、前記ステップで前記負荷の状態が過負荷であることが設定時間以上継続されているときには、前記オリジンサーバに前記他のプロトコルヘッダの生成を指示するステップと、前記指示に応答して前記オリジンサーバから送信されたプロトコルヘッダと当該プロトコルヘッダに対応したコンテンツとして前記記憶部から抽出したコンテンツを前記クライアントに送信するステップと、前記指示に応答して前記オリジンサーバから送信されたプロトコルヘッダを当該プロトコルヘッダに対応したコンテンツと互いに関連づけて前記記憶部に保存するステップとを実行する、請求項１に記載のデータ転送方法。
5. 前記制御部は、前記クライアントからの配信要求を識別して、前記配信要求で指定されたプロトコルヘッダとコンテンツが以前の配信要求で指定されたプロトコルヘッダとコンテンツと同一であるか否かを判定するステップと、当該ステップで前記プロトコルヘッダは異なるが前記コンテンツは同一であると判定したときには、前記記憶部を検索するステップと、当該ステップの検索により、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部から抽出されたときには、抽出されたプロトコルヘッダとコンテンツを前記クライアントに配信するステップと、前記ステップの検索により、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に存在しないときには、前記配信要求で指定されたプロトコルヘッダの生成を前記オリジンサーバに指示するステップを実行する、請求項１に記載のデータ転送方法。
6. クライアントおよびオリジンサーバと通信ネットワークを介して情報の授受を行うとともに前記情報を処理する制御部と、前記制御部の処理に伴う情報を記憶する記憶部とを備え、
   前記制御部は、前記クライアントからの配信要求を識別して、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に保存されていないときには、前記配信要求をオリジンサーバに転送し、前記転送された配信要求に応答して前記オリジンサーバから送信されたプロトコルヘッダとコンテンツを前記記憶部に保存するとともに、前記クライアントに送信し、かつ前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成し、前記生成した他のプロトコルヘッダと前記コンテンツを互いに関連づけて前記記憶部に保存し、前記クライアントからの配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に保存されているときには、当該プロトコルヘッダとコンテンツを前記記憶部から抽出して前記クライアントに配信してなる、プロキシサーバ。
7. 前記制御部は、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、プロトコル毎にヘッダを生成するとともに、前記生成したヘッダを前記記憶部の記憶領域のうち前記コンテンツとは異なる記憶領域に保存し、前記クライアントへの配信時に、前記コンテンツとは異なる記憶領域に保存されているヘッダと前記コンテンツとを結合して前記クライアントに配信してなる、請求項６に記載のプロキシサーバ。
8. 前記制御部は、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、前記他のプロトコルヘッダの生成に伴う負荷の状態を判定し、前記負荷の状態が過負荷でないことを条件に前記他のプロトコルヘッダを生成してなる、請求項６に記載のプロキシサーバ。
9. 前記制御部は、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、前記他のプロトコルヘッダの生成に伴う負荷の状態を判定し、前記負荷の状態が過負荷であることが設定時間以上継続されているときには、前記オリジンサーバに前記他のプロトコルヘッダの生成を指示し、前記指示に応答して前記オリジンサーバから送信されたプロトコルヘッダと当該プロトコルヘッダに対応したコンテンツとして前記記憶部から抽出したコンテンツを前記クライアントに送信するとともに、前記指示に応答して前記オリジンサーバから送信されたプロトコルヘッダを当該プロトコルヘッダに対応したコンテンツと互いに関連づけて前記記憶部に保存してなる、請求項６に記載のプロキシサーバ。
10. 前記制御部は、前記クライアントからの配信要求を識別して、前記配信要求で指定されたプロトコルヘッダとコンテンツが以前の配信要求で指定されたプロトコルヘッダとコンテンツと同一であるか否かを判定し、前記プロトコルヘッダは異なるが前記コンテンツは同一であると判定したときには、前記記憶部を検索し、この検索により、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部から抽出されたときには、抽出されたプロトコルヘッダとコンテンツを前記クライアントに配信し、前記検索により、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に存在しないときには、前記配信要求で指定されたプロトコルヘッダの生成を前記オリジンサーバに指示してなる、請求項６に記載のプロキシサーバ。
11. クライアントと通信ネットワークを介して情報の授受を行うとともに前記情報を処理するプロキシサーバと、前記プロキシサーバと前記通信ネットワークとは異なる通信ネットワークを介して情報の授受を行うオリジンサーバと、を備え、
    前記プロキシサーバは、ストレージとして記憶デバイスで構成された記憶部を備え、前記クライアントからの配信要求を識別して、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に保存されていないときには、前記配信要求をオリジンサーバに転送し、前記転送された配信要求に応答して前記オリジンサーバから送信されたプロトコルヘッダとコンテンツを前記記憶部に保存するとともに、前記クライアントに送信し、かつ前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成し、前記生成した他のプロトコルヘッダと前記コンテンツを互いに関連づけて前記記憶部に保存し、前記クライアントからの配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に保存されているときには、当該プロトコルヘッダとコンテンツを前記記憶部から抽出して前記クライアントに配信し、
    前記オリジンサーバは、前記プロキシサーバから転送された配信要求に応答して、前記配信要求で指定されたプロトコルヘッダを生成し、生成したプロトコルヘッダに前記配信要求で指定されたコンテンツを付与して前記プロキシサーバに送信してなる、ストレージサブシステム。
12. 前記プロキシサーバは、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、プロトコル毎にヘッダを生成するとともに、前記生成したヘッダを前記記憶部の記憶領域のうち前記コンテンツとは異なる記憶領域に保存し、前記クライアントへの配信時に、前記コンテンツとは異なる記憶領域に保存されているヘッダと前記コンテンツとを結合して前記クライアントに配信してなる、請求項１１に記載のストレージサブシステム。
13. 前記プロキシサーバは、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、前記他のプロトコルヘッダの生成に伴う負荷の状態を判定し、前記負荷の状態が過負荷でないことを条件に前記他のプロトコルヘッダを生成してなる、請求項１１に記載のストレージサブシステム。
14. 前記プロキシサーバは、前記オリジンサーバから送信されたプロトコルヘッダを基に他のプロトコルヘッダを生成するときに、前記他のプロトコルヘッダの生成に伴う負荷の状態を判定し、前記負荷の状態が過負荷であることが設定時間以上継続されているときには、前記オリジンサーバに前記他のプロトコルヘッダの生成を指示し、前記指示に応答して前記オリジンサーバから送信されたプロトコルヘッダと当該プロトコルヘッダに対応したコンテンツとして前記記憶部から抽出したコンテンツを前記クライアントに送信するとともに、前記指示に応答して前記オリジンサーバから送信されたプロトコルヘッダを当該プロトコルヘッダに対応したコンテンツと互いに関連づけて前記記憶部に保存し、
    前記オリジンサーバは、前記プロキシサーバからの指示に応答して、前記指示に従ってプロトコルヘッダを生成し、生成したプロトコルヘッダを前記プロキシサーバに送信してなる、請求項１１に記載のストレージサブシステム。
15. 前記プロキシサーバは、前記クライアントからの配信要求を識別して、前記配信要求で指定されたプロトコルヘッダとコンテンツが以前の配信要求で指定されたプロトコルヘッダとコンテンツと同一であるか否かを判定し、前記プロトコルヘッダは異なるが前記コンテンツは同一であると判定したときには、前記記憶部を検索し、この検索により、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部から抽出されたときには、抽出されたプロトコルヘッダとコンテンツを前記クライアントに配信し、前記検索により、前記配信要求で指定されたプロトコルヘッダとコンテンツが前記記憶部に存在しないときには、前記配信要求で指定されたプロトコルヘッダの生成を前記オリジンサーバに指示、
    前記オリジンサーバは、前記プロキシサーバからの指示に応答して、前記指示に従ってプロトコルヘッダを生成し、生成したプロトコルヘッダを前記プロキシサーバに送信してなる、請求項１１に記載のストレージサブシステム。

Images