ＴＣＰセッション管理方法及びＴＣＰプロキシ装置
【課題】複数のセッション間でウィンドウ用メモリを共通化した場合であっても、共通メモリ領域におけるバッファあふれの発生を防止でき、かつ、メモリ利用効率の向上を図ることができるＴＣＰセッション管理方法を提供する。
【解決手段】各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファ３１と、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブル３２とを用いる。ウィンドウ管理テーブル３２を参照して、共通バッファ３１内に存在する複数のセッションにおける最大となるＡＣＫ番号と最小となるＡＣＫ番号との差に基づいて残メモリ量を算出し、しきい値を下回るときに、ＡＣＫ番号が最小であるセッションを切断する。
【解決手段】各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファ３１と、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブル３２とを用いる。ウィンドウ管理テーブル３２を参照して、共通バッファ３１内に存在する複数のセッションにおける最大となるＡＣＫ番号と最小となるＡＣＫ番号との差に基づいて残メモリ量を算出し、しきい値を下回るときに、ＡＣＫ番号が最小であるセッションを切断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１対多ライブ型のデータ配信サービスに適したセッション管理方法と、そのようなセッション管理方法によってセッションを管理するプロキシ装置と、に関する。
【背景技術】
【０００２】
昨今、ＩＰ（インターネット・プロトコル；Internet Protocol）網を用いて、多数のユーザに対してラジオ番組を配信したりスポーツ中継などのＴＶ（テレビジョン）ライブ配信を行ったりするライブ配信型あるいはライブストリーミング型のＩＰデータサービスが普及しつつある。これらのサービスは、単一のデータ配信サーバから多数のユーザー端末に対してほぼ同時に同一コンテンツを配信しようとするものである。そしてこれらのサービスは、ネットワーク層でのプロトコルとしてＩＰを用いるとともに、トランスポート層のプロトコルとして、ＲＦＣ ７９３（非特許文献１）に規定されたＴＣＰ（伝送制御プロトコル：Transmission Control Protocol）を用いている。したがって、このようなＩＰデータサービスでは、ユーザ端末とデータ配信サーバとの間にＴＣＰセッションを確立し、データ配信サーバのメモリ上に、ＴＣＰセッションごとにそのセッションの最大ウィンドウサイズ分の領域を確保し、ＴＣＰヘッダに記録されているシーケンス番号とＡＣＫ（肯定確認応答；acknowledgement）番号を管理しながらパケットの再送制御を行っている。多数のユーザへのライブ型データ配信を前提とすると、ＩＰネットワーク上においてユーザ端末とデータ配信サーバとの間にＴＣＰプロキシ装置が設けられ、ＴＣＰプロキシ装置を介してユーザ端末へのデータ配信が行われる場合も多いが、その場合は、ＴＣＰプロキシ装置と各ユーザ端末との間でＴＣＰセッションが確立され、ＴＣＰプロキシ装置のメモリ上に上記と同様にセッションごとに最大ウィンドウサイズ分の領域が確保され、パケット再送制御が行われることになる。
【０００３】
多数のユーザ端末に対してセッションを確立してライブ型データ配信を行うという点では、ライブ配信用のデータ配信サーバもＴＣＰプロキシ装置も変わるところがなく、ＴＣＰプロキシ装置に、さらに、ライブ型データ配信に適した形態にデータを加工する機能や、ユーザが配信コンテンツを選択できるようにする機能、ユーザアカウントの管理機能を設けたものがデータ配信サーバであるので、以下では、ライブ型データ配信に用いるＴＣＰプロキシ装置について説明する。
【０００４】
図１は、一般的なＴＣＰプロキシ装置のハードウェア構成を示すブロック図である。ＴＣＰプロキシ装置１０は、ＩＰ網であるネットワーク２０を介して多数のユーザ端末２１と接続してＴＣＰセッションを確立するものである。ＴＣＰプロキシ装置１０には、高速かつ広帯域のバス１１と、ネットワーク２０との接続に用いられるネットワークインタフェース１２と、バス１１とネットワークインタフェース１２との間に設けられてネットワーク２０との通信を制御するネットワークコントローラ１３と、プログラムやデータなどを格納するディスク装置１４と、バス１１とディスク装置１４との間に設けられてディスク装置１４に対するアクセス制御などを行うディスクコントローラ１５と、バス１１に接続するメモリ１６と、バス１１に接続するＣＰＵ（中央処理装置）１７と、を備えている。ＴＣＰセッションごとのウィンドウ用バッファはメモリ１６上に確保され、また、ＣＰＵ１７は、各ＴＣＰセッションについてのＴＣＰステート管理を行う。
【０００５】
例えば、ネットワークインタフェース１２の帯域幅が１０Ｇｂｐｓ（ギガビット／秒）であり、コンテンツの配信に必要な帯域幅が１ユーザあたり（すなわち１セッションあたり）１００ｋｂｐｓ（キロビット／秒）であるとする。１０Ｇｂｐｓ／１００ｋｂｐｓ＝１０００００であるから、１０Ｇｂｐｓのネットワークインタフェース１２を用いれば、必要帯域が１００ｋｂｐｓであるコンテンツを１０万人のユーザが同時に視聴できることになる。このようにライブ型データ配信により１０万ユーザが同じコンテンツを同時視聴する場合、各セッションごとに必要なウィンドウサイズが６４ＫＢ（キロバイト）であるとすると、全セッションについてのウインドウサイズ分のデータを貯めるためのメモリ量は、６４ＫＢ×１０００００＝６．４ＧＢ（ギガバイト）であって、メモリ１６の容量としては少なくとも６．４ＧＢが必要となる。各セッションがウィンドウスケーリングを適用している場合には、１０ＧＢ以上のメモリを必要とする。高速なＣＰＵ１７や高速なバス１１を備えることにより１０万セッションに対してＴＣＰのステート管理が可能な場合、この必要メモリサイズの大きさが問題となる。
【０００６】
ところでライブ型データ配信の場合、ユーザごとに全く異なるデータを送信するわけではなく、各ＴＣＰセッションでのＲＴＴ（往復伝搬遅延時間；Round-Trip Time）差のずれこそ生じるものの、同一コンテンツのデータをほぼ同じタイミングで各ユーザがダウンロードしている。そこで、セッション単位でメモリ領域を確保するのではなくてコンテンツ単位でメモリ領域を確保し、この確保されたメモリ領域を複数のセッションで共通に使用するものとして各セッションからこの共通メモリ領域を参照し、セッションごとにシーケンス番号とＡＣＫ番号を管理して再送制御を行えば、必要メモリサイズが大きくなりすぎるという問題は回避することができる。
【０００７】
しかしながら、このようにデータを保持するメモリ領域を複数のセッション間で共通化した場合、ダウンロード速度あるいはデータ転送速度の差により共通メモリ領域においてバッファあふれが発生する可能性がある。例えば、ダウンロード速度の遅いセッションＡが１０秒前のデータを視聴中である場合、セッションＡのために１０秒前から現時点までのデータをメモリ上に保持する必要があり、その結果、確保したメモリ領域を使い果して、他のセッションに新しいデータを提供できない問題が生じる。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】ＲＦＣ ７９３ "Transmission Control Protocol"，IETF (Internet Engineering Task Force)，１９８１年９月
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述のように、トランスポート層のプロトコルとしてＴＣＰを用いてライブ型のデータ配信を行う際に複数セッションでウィンドウ用メモリを共通に用いることは、同時配信数すなわちセッション数が大きいときにメモリサイズが大きくなることを抑制することに効果があるが、接続相手となるユーザ端末ごとのデータ転送速度差に伴って共通メモリ領域におけるバッファあふれが発生するおそれがある。
【００１０】
そこで本発明の目的は、複数のセッション間でウィンドウ用メモリを共通化した場合であっても、共通メモリ領域におけるバッファあふれの発生を防止でき、かつ、メモリ利用効率の向上を図ることができ、これによってライブ型データ配信サービスにおける収容ユーザ数を増加させることができるＴＣＰセッション管理方法と、そのようなＴＣＰセッション管理方法を実行するＴＣＰプロキシ装置とを提供することになる。
【課題を解決するための手段】
【００１１】
本発明の第１のＴＣＰセッション管理方法は、ＴＣＰにより配信すべきコンテンツに対応する複数のセッションを管理するＴＣＰセッション管理方法であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルとを保持し、ウィンドウ管理テーブルを参照して、共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する。
【００１２】
本発明の第２のＴＣＰセッション管理方法は、ＴＣＰにより配信すべきコンテンツに対応する複数のセッションを管理するＴＣＰセッション管理方法であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルとを保持し、ウィンドウ管理テーブルを参照して、共通バッファ内に存在する複数のセッションに関してセッションごとに往復伝搬遅延時間を測定し、複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、往復伝搬遅延時間の差をΔＲＴＴとし、ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する。
【００１３】
本発明の第１のＴＣＰプロキシ装置は、ネットワークに接続し、コンテンツに対応する複数のセッションを管理して、ネットワークに接続した各端末に対してＴＣＰによりコンテンツを配信するＴＣＰプロキシ装置であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルと、共通バッファ内のデータを各端末に送信するためにウィンドウ管理テーブルを参照してＴＣＰによるプロトコル処理を実行するＴＣＰ処理部と、ウィンドウ管理テーブルを参照して、共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部に指示するセッション切断判定部と、を有する。
【００１４】
本発明の第２のＴＣＰプロキシ装置は、ネットワークに接続し、コンテンツに対応する複数のセッションを管理して、ネットワークに接続した各端末に対してＴＣＰによりコンテンツを配信するＴＣＰプロキシ装置であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルと、共通バッファ内のデータを各端末に送信するためにウィンドウ管理テーブルを参照してＴＣＰによるプロトコル処理を実行するＴＣＰ処理部と、共通バッファ内に存在する複数のセッションに関してセッションごとに、ＴＣＰ処理部を介して往復伝搬遅延時間を測定するＲＴＴ測定部と、ウィンドウ管理テーブルを参照し、ＲＴＴ測定部での測定結果に基づき、複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、往復伝搬遅延時間の差をΔＲＴＴとし、ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部に指示するセッション切断判定部と、を有する。
【発明の効果】
【００１５】
本発明では、複数のＴＣＰセッションでウィンドウ用メモリを共通化した場合に、ある判断基準を用いて低速セッションの切断を行うようにする。その結果、共通メモリ内から古いデータを削除することが可能となり、バッファあふれを未然に防止することができるようになるとともに、ＴＣＰプロキシ装置やライブ型データ配信サーバにおけるメモリ利用効率が向上する。切断したセッションについては、再度、セッションを確立することもできる。
【図面の簡単な説明】
【００１６】
【図１】ＴＣＰプロキシ装置の一般的なハードウェア構成を示すブロック図である。
【図２】本発明の第１の実施形態のＴＣＰプロキシ装置の要部の論理的な構成を示すブロック図である。
【図３】メモリ管理を説明する図であって、（ａ）は従来のＴＣＰプロキシ装置におけるメモリ管理を示し、（ｂ）は本発明に基づくＴＣＰプロキシ装置でのメモリ管理を示す図である。
【図４】本発明の第２の実施形態のＴＣＰプロキシ装置の要部の論理的な構成を示すブロック図である。
【図５】ＴＣＰプロキシ装置の動作の概要を説明する図である。
【発明を実施するための形態】
【００１７】
次に、本発明の好ましい実施の形態について、図面を参照して説明する。
【００１８】
本発明に基づくＴＣＰセッション管理方法は、トランスポート層のプロトコルとしてＴＣＰを用いてコンテンツを配信する１対多ライブ型のデータ配信サービスに適したものである。ＴＣＰを用いた場合、複数のユーザ端末に対してほぼ同じタイミングで同じコンテンツを配信する場合、各ユーザ端末に対応した複数のＴＣＰセッションを管理する必要がある。そこで本発明に基づくＴＣＰセッション管理方法では、セッションごとにウィンドウ用バッファを設定することに伴うメモリサイズの増大を防ぐために、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域を共通バッファとして用いる。そして、配信すべきコンテンツに対応する複数のセッションを管理するために、さらに、各セッションごとに当該セッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルを使用し、共通バッファでのバッファあふれを防ぎメモリ利用効率を高めるために、ある判断基準を用いて、ダウンロード速度（転送速度）が低速であるセッションを切断し、共通バッファにおいてその切断されたセッションのみに使用されていた領域を解放して新たなデータを書き込めるようにする。
【００１９】
セッション切断のための判断基準は、確保したメモリ利用率に従うものであるが、具体的には、例えば、ＡＣＫ番号しきい値設定方式と、ダウンロード速度差しきい値設定方式がある。ＡＣＫ番号しきい値設定方式では、ウィンドウ管理テーブルを参照することにより共通バッファ中の各セクションのＡＣＫ番号を調べ、これらのＡＣＫ番号のうちの最大のものと最小のものとの差から残メモリ量を算出し、しきい値と比較して、残メモリ量がしきい値を下回った時に、低速セクションすなわちＡＣＫ番号が最小であるセクションを切断するものである。一方、ダウンロード速度差しきい値設定方式は、ウィンドウ管理テーブルを参照し、セクションごとの往復伝搬遅延時間（ＲＴＴ）を調べ、現状のデータ送信状況の下で残メモリ量が何秒後にゼロになってしまうかを予測して、ゼロとなるまでの時間がしきい値を下回る場合に、ＡＣＫ番号が最小であるセクションを切断するものである。
【００２０】
以下、このようなＴＣＰセッション管理方法を実行する本発明のＴＣＰプロキシ装置について説明する。なお、上述したように、多数のユーザ端末に対してセッションを確立してライブ型データ配信を行うという点では、ライブ配信用のデータ配信サーバもＴＣＰプロキシ装置も変わるところがないので、データ配信サーバそれ自体も本発明のＴＣＰプロキシ装置の範疇に含まれるものである。
【００２１】
図２は、本発明の第１の実施形態のＴＣＰプロキシ装置における要部の論理的な構成を示すブロック図である。本実施形態のＴＣＰプロキシ装置は、ハードウェア構成としては図１に示したものと同様のものであるが、セッション切断のための判断基準としてＡＣＫ番号しきい値設定方式を用いて本発明に基づくＴＣＰセッション管理方法を実行するために、論理的構成として、共通バッファ３１、ウィンドウ管理テーブル３２、セッション切断判定部３３、ＴＣＰ処理部３４及びＩＰ処理部３５を備えている。共通バッファ３１及びウィンドウ管理テーブル３２は、図１に示したハードウェア構成におけるメモリ１６上の領域として確保され、セッション切断判定部３３、ＴＣＰ処理部３４及びＩＰ処理部３５は、ＣＰＵ１７がソフトウェアプログラムを実行することによって実現されるものである。セッション切断判定部３３、ＴＣＰ処理部３４及びＩＰ処理部３５をそれぞれハードウェア構成により実現することもできる。
【００２２】
共通バッファ３１は、ソケットバッファとして、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるバッファ領域であり、例えばデータ配信サーバからのコンテンツのデータが供給される。ウィンドウ管理テーブル３２は、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するテーブルである。
【００２３】
ＴＣＰ処理部３４は、共通バッファ３１内のデータを各端末に送信するためにウィンドウ管理テーブル３２を参照してＴＣＰによるプロトコル処理を実行し、生成したＴＣＰセグメントをＩＰ処理部３４に送出する。ＩＰ処理部３５は、ＴＣＰ処理部３４からのＴＣＰセグメントをＩＰパケットに組み込んでネットワークインタフェースに送出し、これにより、各ユーザ端末にコンテンツのデータが配信されるようにする。
【００２４】
セッション接断判定部３３は、ウィンドウ管理テーブル３２を参照して、共通バッファ３１内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、ＴＣＰにおける最大セグメント長（ＭＳＳ）の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、共通バッファ３１内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部３４に指示し、さらに切断したセッションのみに関係するメモリ領域を解放（クリア）するように共通バッファ３１に指示する。
【００２５】
ここでαは、低速セッションを切断する際のしきい値に対応するものである。αをＭＳＳの倍数としていることから、αは、ＴＣＰセグメントが最長であるという最悪条件のもとでＴＣＰセグメント何個分の余裕をもたせて低速セッションを切断するかを示していると言える。ウィンドウサイズは、セッションごとに異なる可能性があるが、例えば、ウィンドウサイズが最大のセッションのウィンドウサイズをＷとすればよい。
【００２６】
図３は、セッション単位でメモリを確保する従来のＴＣＰプロキシ装置におけるメモリ管理と本発明のＴＣＰプロキシ装置におけるメモリ管理とを対比して示している。
【００２７】
図３（ａ）に示すように、従来のＴＣＰプロキシ装置では、セッションごとにウィンドウ用メモリ領域を確保する必要があり、概算で言えば、ウィンドウサイズ×セッション数だけのメモリ領域が必要となり、セッション数が多大である場合には、極めて多量のメモリ領域を必要とする。これに対して本発明に基づくプロキシ装置では、図３（ｂ）に示すように、ライブ型配信を行うことを前提としてコンテンツごとにメモリ領域を確保する。したがって、配信すべきコンテンツが１つであるとすると、低速セッション切断に用いるしきい値にも依存するが、ＴＣＰプロキシ装置で必要となるバッファサイズを、従来のものと比較して、｛（同一映像視聴ユーザ数−１）×ＴＣＰウィンドウサイズ｝だけ削減することが可能となり、１セッションあたりに必要なメモリサイズ削減による初期コストの低下・低電力化が期待できる。
【００２８】
図３には、ウィンドウ管理テーブル３２の内容の一例も示されている。ここではユーザ端末ごとにＴＣＰプロキシ装置からＴＣＰセッションが確立されるとして、ユーザ端末ごとに、すなわちセッションごとに、そのセッションの現在のＡＣＫ番号とウィンドウサイズとがウィンドウ管理テーブル３２に格納されていることが示されている。また、図３（ｂ）において、符号５１で示した破線の矢印は、複数のセッション（図示した例ではセッション１〜３）の中で最大のＡＣＫ番号と最小のＡＣＫ番号との間のメモリ部分を示しており、第１の実施形態では、このメモリ部分でのメモリ容量を残メモリ量として算出し、セッション切断のための判断に用いている。
【００２９】
次に、本発明の第２の実施形態のＴＣＰプロキシ装置について説明する。図４は、本発明の第２の実施形態のＴＣＰプロキシ装置の要部の論理的な構成を示すブロック図である。図４に示したＴＣＰプロキシ装置は図２に示したものと同様のものであるが、セッション切断のための判断基準としてダウンロード速度差しきい値設定方法を用いるものであり、そのため、ＲＴＴ測定部を備えるとともに、セッション切断判定部及びＴＣＰ処理部の動作の点で図２に示したものと異なっている。図４に示したＴＣＰプロキシ装置においても、共通バッファ３１及びウィンドウ管理テーブル３２は、図１に示したハードウェア構成におけるメモリ１６上の領域として確保され、セッション切断判定部３６、ＴＣＰ処理部３７、ＩＰ処理部３５及びＲＴＴ測定部３８は、例えば、ＣＰＵ１７がソフトウェアプログラムを実行することによって、あるいはハードウェア構成によって実現されるものである。以下、図４に示すＴＣＰプロキシ装置について、図２に示したものと異なる点を説明する。
【００３０】
ＲＴＴ測定部３８は、共通バッファ３１内に存在する複数のセッションに関してセッションごとに、ＴＣＰ処理部３７を介して往復伝搬遅延時間（ＲＴＴ）を測定する。ＲＴＴの測定方法としては、スリー・ウェイ・ハンドシェーク・パケットを用いて実行する方法がある。あるいは、送信するデータパケット内のシーケンス番号とそのデータパケットを送信した時刻と、データパケットに対応して受信するＡＣＫパケット内のＡＣＫ番号とそのＡＣＫパケットが到着した時刻を用い、最大セグメント長をＭＳＳとして、｛ＡＣＫ番号＞シーケンス番号＋ＭＳＳ｝を満たすときの（受信時刻−送信時刻）をＲＴＴとする方法がある。
【００３１】
ＴＣＰ処理部３７は、共通バッファ３１内のデータを各端末に送信するためにウィンドウ管理テーブル３２を参照してＴＣＰによるプロトコル処理を実行し、生成したＴＣＰセグメントをＩＰ処理部３４に送出し、さらに、スリー・ウェイ・ハンドシェーク・パケットを用いてＲＴＴ測定を行う場合にはスリー・ウェイ・ハンドシェークの処理を実行し、データパケットと対応するＡＣＫパケットの時刻に応じてＲＴＴを測定する場合には、必要な情報をＲＴＴ測定部３８に伝達する。
【００３２】
セッション切断判定部３６は、ウィンドウ管理テーブル３２を参照し、ＲＴＴ測定部３８での測定結果に基づき、複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差（ΔＲＴＴ）とウィンドウサイズの差（ΔＷ）を求め、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、共通バッファ３１内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部３７に指示し、さらに切断したセッションのみに関係するメモリ領域を解放（クリア）するように共通バッファ３１に指示する。
【００３３】
図３（ｂ）において符号５２で示す破線の矢印は、現時点で未使用となっているメモリ部分を示しており、第２の実施形態では、この未使用部分があと何秒後に使い切られてしまうかを予想して、セッション切断のための判断に利用している。
【００３４】
図５は、上述した各実施形態のＴＣＰプロキシ装置をデータ配信サーバと複数のユーザ端末との間に配置した場合の動作を示している。ここで、サーバには複数の映像コンテンツ（例えば、ビデオ１とビデオ２）が格納されているものとする。図２及び図４ではＴＣＰプロキシ装置におけるユーザ端末側へのセッションに関する構成のみが示されているが、図５では、配信サーバ側とのＴＣＰ処理及びユーザ端末側とのＴＣＰ処理の両方が示されている。図には示されていないが、ユーザのアカウント管理などのためにユーザ管理テーブルが設けられているものとする。
【００３５】
ビデオ１及びビデオ２の両方についてソケットバッファ（共通バッファ）が設定されており、配信サーバ側との処理においては、ＩＰ処理、ヘッダを分類するクラシファイア処理及びＴＣＰ処理を経て、各コンテンツのデータが対応するソケットバッファに格納される。コンテンツの識別は、クラシファイアからＨＴＴＰ Ｇｅｔ ｒｅｑｕｅｓｔパケットを抜き出し、ＨＴＴＰヘッダ処理を行って含まれるＵＲＩ(uniform resource identifier)に基づいて行うことができる。また、新規コンテンツの場合であれば、ＴＣＰ処理において新規セッションを確立し、既存コンテンツであれば、ＴＣＰのいわゆる５タプル(5-tuple)とコンテンツ情報とをひもづける。
【００３６】
ユーザ端末側との処理においては、まず、ユーザ端末からＨＴＴＰ Ｇｅｔ ｒｅｑｕｅｓｔパケットが到着した際に、宛先ＩＰアドレス、送信元ＩＰアドレス及びＵＲＩを確認し、ユーザ管理テーブル内で設定されたアドレスであって、かつ、ＴＣＰプロキシ内に該当映像が存在する場合にそのユーザ端末をセッションに参加させる。そして、その時点からユーザ端末にライブ配信を行うために、現在のソケットバッファ内に存在する最も知さなシーケンス番号をＳＹＮ／ＡＣＫパケット内に記述してユーザ端末に送信する。これにより、ユーザは、その指定したコンテンツのライブ配信を受けられるようになる。
【００３７】
なお、サーバが単一の映像のみを配信する場合には、ユーザ端末からＳＹＮパケットをが到着した際に、その宛先ＩＰアドレス及び送信元ＩＰアドレスを確認し、ユーザ管理テーブル内で設定されたアドレスである場合にそのユーザ端末をセッションに参加させる。そして、その時点からユーザ端末にライブ配信を行うために、現在のソケットバッファ内に存在する最も知さなシーケンス番号をＳＹＮ／ＡＣＫパケット内に記述してユーザ端末に送信する。これにより、ユーザは、コンテンツのライブ配信を受けられるようになる。
【符号の説明】
【００３８】
１０ ＴＣＰプロキシ装置
１１ バス
１２ ネットワークインタフェース
１３ ネットワークコントローラ
１４ ディスク装置
１５ ディスクコントローラ
１６ メモリ
１７ ＣＰＵ
２０ ネットワーク
２１ ユーザ端末
３１ 共通バッファ
３２ ウィンドウ管理テーブル
３３，３６ セッション切断判定部
３４，３７ ＴＣＰ処理部
３５ ＩＰ処理部
３８ ＲＴＴ測定部
【技術分野】
【０００１】
本発明は、１対多ライブ型のデータ配信サービスに適したセッション管理方法と、そのようなセッション管理方法によってセッションを管理するプロキシ装置と、に関する。
【背景技術】
【０００２】
昨今、ＩＰ（インターネット・プロトコル；Internet Protocol）網を用いて、多数のユーザに対してラジオ番組を配信したりスポーツ中継などのＴＶ（テレビジョン）ライブ配信を行ったりするライブ配信型あるいはライブストリーミング型のＩＰデータサービスが普及しつつある。これらのサービスは、単一のデータ配信サーバから多数のユーザー端末に対してほぼ同時に同一コンテンツを配信しようとするものである。そしてこれらのサービスは、ネットワーク層でのプロトコルとしてＩＰを用いるとともに、トランスポート層のプロトコルとして、ＲＦＣ ７９３（非特許文献１）に規定されたＴＣＰ（伝送制御プロトコル：Transmission Control Protocol）を用いている。したがって、このようなＩＰデータサービスでは、ユーザ端末とデータ配信サーバとの間にＴＣＰセッションを確立し、データ配信サーバのメモリ上に、ＴＣＰセッションごとにそのセッションの最大ウィンドウサイズ分の領域を確保し、ＴＣＰヘッダに記録されているシーケンス番号とＡＣＫ（肯定確認応答；acknowledgement）番号を管理しながらパケットの再送制御を行っている。多数のユーザへのライブ型データ配信を前提とすると、ＩＰネットワーク上においてユーザ端末とデータ配信サーバとの間にＴＣＰプロキシ装置が設けられ、ＴＣＰプロキシ装置を介してユーザ端末へのデータ配信が行われる場合も多いが、その場合は、ＴＣＰプロキシ装置と各ユーザ端末との間でＴＣＰセッションが確立され、ＴＣＰプロキシ装置のメモリ上に上記と同様にセッションごとに最大ウィンドウサイズ分の領域が確保され、パケット再送制御が行われることになる。
【０００３】
多数のユーザ端末に対してセッションを確立してライブ型データ配信を行うという点では、ライブ配信用のデータ配信サーバもＴＣＰプロキシ装置も変わるところがなく、ＴＣＰプロキシ装置に、さらに、ライブ型データ配信に適した形態にデータを加工する機能や、ユーザが配信コンテンツを選択できるようにする機能、ユーザアカウントの管理機能を設けたものがデータ配信サーバであるので、以下では、ライブ型データ配信に用いるＴＣＰプロキシ装置について説明する。
【０００４】
図１は、一般的なＴＣＰプロキシ装置のハードウェア構成を示すブロック図である。ＴＣＰプロキシ装置１０は、ＩＰ網であるネットワーク２０を介して多数のユーザ端末２１と接続してＴＣＰセッションを確立するものである。ＴＣＰプロキシ装置１０には、高速かつ広帯域のバス１１と、ネットワーク２０との接続に用いられるネットワークインタフェース１２と、バス１１とネットワークインタフェース１２との間に設けられてネットワーク２０との通信を制御するネットワークコントローラ１３と、プログラムやデータなどを格納するディスク装置１４と、バス１１とディスク装置１４との間に設けられてディスク装置１４に対するアクセス制御などを行うディスクコントローラ１５と、バス１１に接続するメモリ１６と、バス１１に接続するＣＰＵ（中央処理装置）１７と、を備えている。ＴＣＰセッションごとのウィンドウ用バッファはメモリ１６上に確保され、また、ＣＰＵ１７は、各ＴＣＰセッションについてのＴＣＰステート管理を行う。
【０００５】
例えば、ネットワークインタフェース１２の帯域幅が１０Ｇｂｐｓ（ギガビット／秒）であり、コンテンツの配信に必要な帯域幅が１ユーザあたり（すなわち１セッションあたり）１００ｋｂｐｓ（キロビット／秒）であるとする。１０Ｇｂｐｓ／１００ｋｂｐｓ＝１０００００であるから、１０Ｇｂｐｓのネットワークインタフェース１２を用いれば、必要帯域が１００ｋｂｐｓであるコンテンツを１０万人のユーザが同時に視聴できることになる。このようにライブ型データ配信により１０万ユーザが同じコンテンツを同時視聴する場合、各セッションごとに必要なウィンドウサイズが６４ＫＢ（キロバイト）であるとすると、全セッションについてのウインドウサイズ分のデータを貯めるためのメモリ量は、６４ＫＢ×１０００００＝６．４ＧＢ（ギガバイト）であって、メモリ１６の容量としては少なくとも６．４ＧＢが必要となる。各セッションがウィンドウスケーリングを適用している場合には、１０ＧＢ以上のメモリを必要とする。高速なＣＰＵ１７や高速なバス１１を備えることにより１０万セッションに対してＴＣＰのステート管理が可能な場合、この必要メモリサイズの大きさが問題となる。
【０００６】
ところでライブ型データ配信の場合、ユーザごとに全く異なるデータを送信するわけではなく、各ＴＣＰセッションでのＲＴＴ（往復伝搬遅延時間；Round-Trip Time）差のずれこそ生じるものの、同一コンテンツのデータをほぼ同じタイミングで各ユーザがダウンロードしている。そこで、セッション単位でメモリ領域を確保するのではなくてコンテンツ単位でメモリ領域を確保し、この確保されたメモリ領域を複数のセッションで共通に使用するものとして各セッションからこの共通メモリ領域を参照し、セッションごとにシーケンス番号とＡＣＫ番号を管理して再送制御を行えば、必要メモリサイズが大きくなりすぎるという問題は回避することができる。
【０００７】
しかしながら、このようにデータを保持するメモリ領域を複数のセッション間で共通化した場合、ダウンロード速度あるいはデータ転送速度の差により共通メモリ領域においてバッファあふれが発生する可能性がある。例えば、ダウンロード速度の遅いセッションＡが１０秒前のデータを視聴中である場合、セッションＡのために１０秒前から現時点までのデータをメモリ上に保持する必要があり、その結果、確保したメモリ領域を使い果して、他のセッションに新しいデータを提供できない問題が生じる。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】ＲＦＣ ７９３ "Transmission Control Protocol"，IETF (Internet Engineering Task Force)，１９８１年９月
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述のように、トランスポート層のプロトコルとしてＴＣＰを用いてライブ型のデータ配信を行う際に複数セッションでウィンドウ用メモリを共通に用いることは、同時配信数すなわちセッション数が大きいときにメモリサイズが大きくなることを抑制することに効果があるが、接続相手となるユーザ端末ごとのデータ転送速度差に伴って共通メモリ領域におけるバッファあふれが発生するおそれがある。
【００１０】
そこで本発明の目的は、複数のセッション間でウィンドウ用メモリを共通化した場合であっても、共通メモリ領域におけるバッファあふれの発生を防止でき、かつ、メモリ利用効率の向上を図ることができ、これによってライブ型データ配信サービスにおける収容ユーザ数を増加させることができるＴＣＰセッション管理方法と、そのようなＴＣＰセッション管理方法を実行するＴＣＰプロキシ装置とを提供することになる。
【課題を解決するための手段】
【００１１】
本発明の第１のＴＣＰセッション管理方法は、ＴＣＰにより配信すべきコンテンツに対応する複数のセッションを管理するＴＣＰセッション管理方法であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルとを保持し、ウィンドウ管理テーブルを参照して、共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する。
【００１２】
本発明の第２のＴＣＰセッション管理方法は、ＴＣＰにより配信すべきコンテンツに対応する複数のセッションを管理するＴＣＰセッション管理方法であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルとを保持し、ウィンドウ管理テーブルを参照して、共通バッファ内に存在する複数のセッションに関してセッションごとに往復伝搬遅延時間を測定し、複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、往復伝搬遅延時間の差をΔＲＴＴとし、ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する。
【００１３】
本発明の第１のＴＣＰプロキシ装置は、ネットワークに接続し、コンテンツに対応する複数のセッションを管理して、ネットワークに接続した各端末に対してＴＣＰによりコンテンツを配信するＴＣＰプロキシ装置であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルと、共通バッファ内のデータを各端末に送信するためにウィンドウ管理テーブルを参照してＴＣＰによるプロトコル処理を実行するＴＣＰ処理部と、ウィンドウ管理テーブルを参照して、共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部に指示するセッション切断判定部と、を有する。
【００１４】
本発明の第２のＴＣＰプロキシ装置は、ネットワークに接続し、コンテンツに対応する複数のセッションを管理して、ネットワークに接続した各端末に対してＴＣＰによりコンテンツを配信するＴＣＰプロキシ装置であって、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルと、共通バッファ内のデータを各端末に送信するためにウィンドウ管理テーブルを参照してＴＣＰによるプロトコル処理を実行するＴＣＰ処理部と、共通バッファ内に存在する複数のセッションに関してセッションごとに、ＴＣＰ処理部を介して往復伝搬遅延時間を測定するＲＴＴ測定部と、ウィンドウ管理テーブルを参照し、ＲＴＴ測定部での測定結果に基づき、複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、往復伝搬遅延時間の差をΔＲＴＴとし、ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部に指示するセッション切断判定部と、を有する。
【発明の効果】
【００１５】
本発明では、複数のＴＣＰセッションでウィンドウ用メモリを共通化した場合に、ある判断基準を用いて低速セッションの切断を行うようにする。その結果、共通メモリ内から古いデータを削除することが可能となり、バッファあふれを未然に防止することができるようになるとともに、ＴＣＰプロキシ装置やライブ型データ配信サーバにおけるメモリ利用効率が向上する。切断したセッションについては、再度、セッションを確立することもできる。
【図面の簡単な説明】
【００１６】
【図１】ＴＣＰプロキシ装置の一般的なハードウェア構成を示すブロック図である。
【図２】本発明の第１の実施形態のＴＣＰプロキシ装置の要部の論理的な構成を示すブロック図である。
【図３】メモリ管理を説明する図であって、（ａ）は従来のＴＣＰプロキシ装置におけるメモリ管理を示し、（ｂ）は本発明に基づくＴＣＰプロキシ装置でのメモリ管理を示す図である。
【図４】本発明の第２の実施形態のＴＣＰプロキシ装置の要部の論理的な構成を示すブロック図である。
【図５】ＴＣＰプロキシ装置の動作の概要を説明する図である。
【発明を実施するための形態】
【００１７】
次に、本発明の好ましい実施の形態について、図面を参照して説明する。
【００１８】
本発明に基づくＴＣＰセッション管理方法は、トランスポート層のプロトコルとしてＴＣＰを用いてコンテンツを配信する１対多ライブ型のデータ配信サービスに適したものである。ＴＣＰを用いた場合、複数のユーザ端末に対してほぼ同じタイミングで同じコンテンツを配信する場合、各ユーザ端末に対応した複数のＴＣＰセッションを管理する必要がある。そこで本発明に基づくＴＣＰセッション管理方法では、セッションごとにウィンドウ用バッファを設定することに伴うメモリサイズの増大を防ぐために、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるメモリ領域を共通バッファとして用いる。そして、配信すべきコンテンツに対応する複数のセッションを管理するために、さらに、各セッションごとに当該セッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルを使用し、共通バッファでのバッファあふれを防ぎメモリ利用効率を高めるために、ある判断基準を用いて、ダウンロード速度（転送速度）が低速であるセッションを切断し、共通バッファにおいてその切断されたセッションのみに使用されていた領域を解放して新たなデータを書き込めるようにする。
【００１９】
セッション切断のための判断基準は、確保したメモリ利用率に従うものであるが、具体的には、例えば、ＡＣＫ番号しきい値設定方式と、ダウンロード速度差しきい値設定方式がある。ＡＣＫ番号しきい値設定方式では、ウィンドウ管理テーブルを参照することにより共通バッファ中の各セクションのＡＣＫ番号を調べ、これらのＡＣＫ番号のうちの最大のものと最小のものとの差から残メモリ量を算出し、しきい値と比較して、残メモリ量がしきい値を下回った時に、低速セクションすなわちＡＣＫ番号が最小であるセクションを切断するものである。一方、ダウンロード速度差しきい値設定方式は、ウィンドウ管理テーブルを参照し、セクションごとの往復伝搬遅延時間（ＲＴＴ）を調べ、現状のデータ送信状況の下で残メモリ量が何秒後にゼロになってしまうかを予測して、ゼロとなるまでの時間がしきい値を下回る場合に、ＡＣＫ番号が最小であるセクションを切断するものである。
【００２０】
以下、このようなＴＣＰセッション管理方法を実行する本発明のＴＣＰプロキシ装置について説明する。なお、上述したように、多数のユーザ端末に対してセッションを確立してライブ型データ配信を行うという点では、ライブ配信用のデータ配信サーバもＴＣＰプロキシ装置も変わるところがないので、データ配信サーバそれ自体も本発明のＴＣＰプロキシ装置の範疇に含まれるものである。
【００２１】
図２は、本発明の第１の実施形態のＴＣＰプロキシ装置における要部の論理的な構成を示すブロック図である。本実施形態のＴＣＰプロキシ装置は、ハードウェア構成としては図１に示したものと同様のものであるが、セッション切断のための判断基準としてＡＣＫ番号しきい値設定方式を用いて本発明に基づくＴＣＰセッション管理方法を実行するために、論理的構成として、共通バッファ３１、ウィンドウ管理テーブル３２、セッション切断判定部３３、ＴＣＰ処理部３４及びＩＰ処理部３５を備えている。共通バッファ３１及びウィンドウ管理テーブル３２は、図１に示したハードウェア構成におけるメモリ１６上の領域として確保され、セッション切断判定部３３、ＴＣＰ処理部３４及びＩＰ処理部３５は、ＣＰＵ１７がソフトウェアプログラムを実行することによって実現されるものである。セッション切断判定部３３、ＴＣＰ処理部３４及びＩＰ処理部３５をそれぞれハードウェア構成により実現することもできる。
【００２２】
共通バッファ３１は、ソケットバッファとして、各セッションのウィンドウ用として複数のセッションに対して共通にコンテンツ単位で設定されるバッファ領域であり、例えばデータ配信サーバからのコンテンツのデータが供給される。ウィンドウ管理テーブル３２は、各セッションごとにそのセッションのＡＣＫ番号とウィンドウサイズとを管理するテーブルである。
【００２３】
ＴＣＰ処理部３４は、共通バッファ３１内のデータを各端末に送信するためにウィンドウ管理テーブル３２を参照してＴＣＰによるプロトコル処理を実行し、生成したＴＣＰセグメントをＩＰ処理部３４に送出する。ＩＰ処理部３５は、ＴＣＰ処理部３４からのＴＣＰセグメントをＩＰパケットに組み込んでネットワークインタフェースに送出し、これにより、各ユーザ端末にコンテンツのデータが配信されるようにする。
【００２４】
セッション接断判定部３３は、ウィンドウ管理テーブル３２を参照して、共通バッファ３１内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、ＴＣＰにおける最大セグメント長（ＭＳＳ）の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、共通バッファ３１内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部３４に指示し、さらに切断したセッションのみに関係するメモリ領域を解放（クリア）するように共通バッファ３１に指示する。
【００２５】
ここでαは、低速セッションを切断する際のしきい値に対応するものである。αをＭＳＳの倍数としていることから、αは、ＴＣＰセグメントが最長であるという最悪条件のもとでＴＣＰセグメント何個分の余裕をもたせて低速セッションを切断するかを示していると言える。ウィンドウサイズは、セッションごとに異なる可能性があるが、例えば、ウィンドウサイズが最大のセッションのウィンドウサイズをＷとすればよい。
【００２６】
図３は、セッション単位でメモリを確保する従来のＴＣＰプロキシ装置におけるメモリ管理と本発明のＴＣＰプロキシ装置におけるメモリ管理とを対比して示している。
【００２７】
図３（ａ）に示すように、従来のＴＣＰプロキシ装置では、セッションごとにウィンドウ用メモリ領域を確保する必要があり、概算で言えば、ウィンドウサイズ×セッション数だけのメモリ領域が必要となり、セッション数が多大である場合には、極めて多量のメモリ領域を必要とする。これに対して本発明に基づくプロキシ装置では、図３（ｂ）に示すように、ライブ型配信を行うことを前提としてコンテンツごとにメモリ領域を確保する。したがって、配信すべきコンテンツが１つであるとすると、低速セッション切断に用いるしきい値にも依存するが、ＴＣＰプロキシ装置で必要となるバッファサイズを、従来のものと比較して、｛（同一映像視聴ユーザ数−１）×ＴＣＰウィンドウサイズ｝だけ削減することが可能となり、１セッションあたりに必要なメモリサイズ削減による初期コストの低下・低電力化が期待できる。
【００２８】
図３には、ウィンドウ管理テーブル３２の内容の一例も示されている。ここではユーザ端末ごとにＴＣＰプロキシ装置からＴＣＰセッションが確立されるとして、ユーザ端末ごとに、すなわちセッションごとに、そのセッションの現在のＡＣＫ番号とウィンドウサイズとがウィンドウ管理テーブル３２に格納されていることが示されている。また、図３（ｂ）において、符号５１で示した破線の矢印は、複数のセッション（図示した例ではセッション１〜３）の中で最大のＡＣＫ番号と最小のＡＣＫ番号との間のメモリ部分を示しており、第１の実施形態では、このメモリ部分でのメモリ容量を残メモリ量として算出し、セッション切断のための判断に用いている。
【００２９】
次に、本発明の第２の実施形態のＴＣＰプロキシ装置について説明する。図４は、本発明の第２の実施形態のＴＣＰプロキシ装置の要部の論理的な構成を示すブロック図である。図４に示したＴＣＰプロキシ装置は図２に示したものと同様のものであるが、セッション切断のための判断基準としてダウンロード速度差しきい値設定方法を用いるものであり、そのため、ＲＴＴ測定部を備えるとともに、セッション切断判定部及びＴＣＰ処理部の動作の点で図２に示したものと異なっている。図４に示したＴＣＰプロキシ装置においても、共通バッファ３１及びウィンドウ管理テーブル３２は、図１に示したハードウェア構成におけるメモリ１６上の領域として確保され、セッション切断判定部３６、ＴＣＰ処理部３７、ＩＰ処理部３５及びＲＴＴ測定部３８は、例えば、ＣＰＵ１７がソフトウェアプログラムを実行することによって、あるいはハードウェア構成によって実現されるものである。以下、図４に示すＴＣＰプロキシ装置について、図２に示したものと異なる点を説明する。
【００３０】
ＲＴＴ測定部３８は、共通バッファ３１内に存在する複数のセッションに関してセッションごとに、ＴＣＰ処理部３７を介して往復伝搬遅延時間（ＲＴＴ）を測定する。ＲＴＴの測定方法としては、スリー・ウェイ・ハンドシェーク・パケットを用いて実行する方法がある。あるいは、送信するデータパケット内のシーケンス番号とそのデータパケットを送信した時刻と、データパケットに対応して受信するＡＣＫパケット内のＡＣＫ番号とそのＡＣＫパケットが到着した時刻を用い、最大セグメント長をＭＳＳとして、｛ＡＣＫ番号＞シーケンス番号＋ＭＳＳ｝を満たすときの（受信時刻−送信時刻）をＲＴＴとする方法がある。
【００３１】
ＴＣＰ処理部３７は、共通バッファ３１内のデータを各端末に送信するためにウィンドウ管理テーブル３２を参照してＴＣＰによるプロトコル処理を実行し、生成したＴＣＰセグメントをＩＰ処理部３４に送出し、さらに、スリー・ウェイ・ハンドシェーク・パケットを用いてＲＴＴ測定を行う場合にはスリー・ウェイ・ハンドシェークの処理を実行し、データパケットと対応するＡＣＫパケットの時刻に応じてＲＴＴを測定する場合には、必要な情報をＲＴＴ測定部３８に伝達する。
【００３２】
セッション切断判定部３６は、ウィンドウ管理テーブル３２を参照し、ＲＴＴ測定部３８での測定結果に基づき、複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差（ΔＲＴＴ）とウィンドウサイズの差（ΔＷ）を求め、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、共通バッファ３１内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するようにＴＣＰ処理部３７に指示し、さらに切断したセッションのみに関係するメモリ領域を解放（クリア）するように共通バッファ３１に指示する。
【００３３】
図３（ｂ）において符号５２で示す破線の矢印は、現時点で未使用となっているメモリ部分を示しており、第２の実施形態では、この未使用部分があと何秒後に使い切られてしまうかを予想して、セッション切断のための判断に利用している。
【００３４】
図５は、上述した各実施形態のＴＣＰプロキシ装置をデータ配信サーバと複数のユーザ端末との間に配置した場合の動作を示している。ここで、サーバには複数の映像コンテンツ（例えば、ビデオ１とビデオ２）が格納されているものとする。図２及び図４ではＴＣＰプロキシ装置におけるユーザ端末側へのセッションに関する構成のみが示されているが、図５では、配信サーバ側とのＴＣＰ処理及びユーザ端末側とのＴＣＰ処理の両方が示されている。図には示されていないが、ユーザのアカウント管理などのためにユーザ管理テーブルが設けられているものとする。
【００３５】
ビデオ１及びビデオ２の両方についてソケットバッファ（共通バッファ）が設定されており、配信サーバ側との処理においては、ＩＰ処理、ヘッダを分類するクラシファイア処理及びＴＣＰ処理を経て、各コンテンツのデータが対応するソケットバッファに格納される。コンテンツの識別は、クラシファイアからＨＴＴＰ Ｇｅｔ ｒｅｑｕｅｓｔパケットを抜き出し、ＨＴＴＰヘッダ処理を行って含まれるＵＲＩ(uniform resource identifier)に基づいて行うことができる。また、新規コンテンツの場合であれば、ＴＣＰ処理において新規セッションを確立し、既存コンテンツであれば、ＴＣＰのいわゆる５タプル(5-tuple)とコンテンツ情報とをひもづける。
【００３６】
ユーザ端末側との処理においては、まず、ユーザ端末からＨＴＴＰ Ｇｅｔ ｒｅｑｕｅｓｔパケットが到着した際に、宛先ＩＰアドレス、送信元ＩＰアドレス及びＵＲＩを確認し、ユーザ管理テーブル内で設定されたアドレスであって、かつ、ＴＣＰプロキシ内に該当映像が存在する場合にそのユーザ端末をセッションに参加させる。そして、その時点からユーザ端末にライブ配信を行うために、現在のソケットバッファ内に存在する最も知さなシーケンス番号をＳＹＮ／ＡＣＫパケット内に記述してユーザ端末に送信する。これにより、ユーザは、その指定したコンテンツのライブ配信を受けられるようになる。
【００３７】
なお、サーバが単一の映像のみを配信する場合には、ユーザ端末からＳＹＮパケットをが到着した際に、その宛先ＩＰアドレス及び送信元ＩＰアドレスを確認し、ユーザ管理テーブル内で設定されたアドレスである場合にそのユーザ端末をセッションに参加させる。そして、その時点からユーザ端末にライブ配信を行うために、現在のソケットバッファ内に存在する最も知さなシーケンス番号をＳＹＮ／ＡＣＫパケット内に記述してユーザ端末に送信する。これにより、ユーザは、コンテンツのライブ配信を受けられるようになる。
【符号の説明】
【００３８】
１０ ＴＣＰプロキシ装置
１１ バス
１２ ネットワークインタフェース
１３ ネットワークコントローラ
１４ ディスク装置
１５ ディスクコントローラ
１６ メモリ
１７ ＣＰＵ
２０ ネットワーク
２１ ユーザ端末
３１ 共通バッファ
３２ ウィンドウ管理テーブル
３３，３６ セッション切断判定部
３４，３７ ＴＣＰ処理部
３５ ＩＰ処理部
３８ ＲＴＴ測定部
【特許請求の範囲】
【請求項１】
ＴＣＰにより配信すべきコンテンツに対応する複数のセッションを管理するＴＣＰセッション管理方法であって、
各セッションのウィンドウ用として前記複数のセッションに対して共通に前記コンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとに当該セッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルとを保持し、前記メモリ領域において記憶されている、前記ＡＣＫ番号からウィンドウサイズの範囲内のデータを各セッションに対して配布することを特徴とするＴＣＰセッション管理方式。
【請求項２】
前記ウィンドウ管理テーブルを参照して、前記共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する、請求項１に記載のＴＣＰセッション管理方法。
【請求項３】
前記ウィンドウ管理テーブルを参照して、前記共通バッファ内に存在する複数のセッションに関してセッションごとに往復伝搬遅延時間を測定し、前記複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、前記往復伝搬遅延時間の差をΔＲＴＴとし、前記ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する、請求項１に記載のＴＣＰセッション管理方法。
【請求項４】
送信するデータパケット内のシーケンス番号と該データパケットを送信した時刻と、前記データパケットに対応して受信するＡＣＫパケット内のＡＣＫ番号と該ＡＣＫパケットが到着した時刻を用い、最大セグメント長をＭＳＳとして、｛ＡＣＫ番号＞シーケンス番号＋ＭＳＳ｝を満たすときの（受信時刻−送信時刻）を前記往復伝搬遅延時間とする、請求項３に記載のＴＣＰセッション管理方法。
【請求項５】
ネットワークに接続し、コンテンツに対応する複数のセッションを管理して、前記ネットワークに接続した各端末に対してＴＣＰにより前記コンテンツを配信するＴＣＰプロキシ装置であって、
各セッションのウィンドウ用として前記複数のセッションに対して共通に前記コンテンツ単位で設定されるメモリ領域である共通バッファと、
各セッションごとに当該セッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルと、
前記共通バッファ内のデータを各端末に送信するために前記ウィンドウ管理テーブルを参照してＴＣＰによるプロトコル処理を実行するＴＣＰ処理部と、
を有するＴＣＰプロキシ装置。
【請求項６】
前記ウィンドウ管理テーブルを参照して、前記共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するように前記ＴＣＰ処理部に指示するセッション切断判定部をさらに有する、請求項５に記載のＴＣＰプロキシ装置。
【請求項７】
前記共通バッファ内に存在する複数のセッションに関してセッションごとに、前記ＴＣＰ処理部を介して往復伝搬遅延時間を測定するＲＴＴ測定部と、
前記ウィンドウ管理テーブルを参照し、前記ＲＴＴ測定部での測定結果に基づき、前記複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、前記往復伝搬遅延時間の差をΔＲＴＴとし、前記ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するように前記ＴＣＰ処理部に指示するセッション切断判定部と、
を有する、請求項５に記載のＴＣＰプロキシ装置。
【請求項８】
前記ＲＴＴ測定部は、送信するデータパケット内のシーケンス番号と該データパケットを送信した時刻と、前記データパケットに対応して受信するＡＣＫパケット内のＡＣＫ番号と該ＡＣＫパケットが到着した時刻を用い、最大セグメント長をＭＳＳとして、｛ＡＣＫ番号＞シーケンス番号＋ＭＳＳ｝を満たすときの（受信時刻−送信時刻）を前記往復伝搬遅延時間とする、請求項７に記載のＴＣＰプロキシ装置。
【請求項１】
ＴＣＰにより配信すべきコンテンツに対応する複数のセッションを管理するＴＣＰセッション管理方法であって、
各セッションのウィンドウ用として前記複数のセッションに対して共通に前記コンテンツ単位で設定されるメモリ領域である共通バッファと、各セッションごとに当該セッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルとを保持し、前記メモリ領域において記憶されている、前記ＡＣＫ番号からウィンドウサイズの範囲内のデータを各セッションに対して配布することを特徴とするＴＣＰセッション管理方式。
【請求項２】
前記ウィンドウ管理テーブルを参照して、前記共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する、請求項１に記載のＴＣＰセッション管理方法。
【請求項３】
前記ウィンドウ管理テーブルを参照して、前記共通バッファ内に存在する複数のセッションに関してセッションごとに往復伝搬遅延時間を測定し、前記複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、前記往復伝搬遅延時間の差をΔＲＴＴとし、前記ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断する、請求項１に記載のＴＣＰセッション管理方法。
【請求項４】
送信するデータパケット内のシーケンス番号と該データパケットを送信した時刻と、前記データパケットに対応して受信するＡＣＫパケット内のＡＣＫ番号と該ＡＣＫパケットが到着した時刻を用い、最大セグメント長をＭＳＳとして、｛ＡＣＫ番号＞シーケンス番号＋ＭＳＳ｝を満たすときの（受信時刻−送信時刻）を前記往復伝搬遅延時間とする、請求項３に記載のＴＣＰセッション管理方法。
【請求項５】
ネットワークに接続し、コンテンツに対応する複数のセッションを管理して、前記ネットワークに接続した各端末に対してＴＣＰにより前記コンテンツを配信するＴＣＰプロキシ装置であって、
各セッションのウィンドウ用として前記複数のセッションに対して共通に前記コンテンツ単位で設定されるメモリ領域である共通バッファと、
各セッションごとに当該セッションのＡＣＫ番号とウィンドウサイズとを管理するウィンドウ管理テーブルと、
前記共通バッファ内のデータを各端末に送信するために前記ウィンドウ管理テーブルを参照してＴＣＰによるプロトコル処理を実行するＴＣＰ処理部と、
を有するＴＣＰプロキシ装置。
【請求項６】
前記ウィンドウ管理テーブルを参照して、前記共通バッファ内に存在する複数のセッションにおける最大となるＡＣＫ番号をＭａｘ＿ＡＣＫとし、最小となるＡＣＫ番号をＭｉｎ＿ＡＣＫとし、最大セグメント長の倍数である所定の数をαとし、ウィンドウサイズをＷとして、Ｍａｘ＿ＡＣＫとＭｉｎ＿ＡＣＫとの差を用いて、｛確保メモリサイズ＜（Ｍａｘ＿ＡＣＫ−Ｍｉｎ＿ＡＣＫ）＋Ｗ＋α｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するように前記ＴＣＰ処理部に指示するセッション切断判定部をさらに有する、請求項５に記載のＴＣＰプロキシ装置。
【請求項７】
前記共通バッファ内に存在する複数のセッションに関してセッションごとに、前記ＴＣＰ処理部を介して往復伝搬遅延時間を測定するＲＴＴ測定部と、
前記ウィンドウ管理テーブルを参照し、前記ＲＴＴ測定部での測定結果に基づき、前記複数のセッションのうちの最も大きいＡＣＫ番号を有するセッションと最も小さいＡＣＫ番号を有するセッションとの間での往復伝搬遅延時間の差とウィンドウサイズの差を求め、前記往復伝搬遅延時間の差をΔＲＴＴとし、前記ウィンドウサイズの差をΔＷとし、時間に関する予め定めたしきい値をβとして、｛（残メモリ量÷ΔＷ）×ΔＲＴＴ＜β｝を満たすときに、前記共通バッファ内に存在する複数のセッションのうちＡＣＫ番号が最小であるセッションを切断するように前記ＴＣＰ処理部に指示するセッション切断判定部と、
を有する、請求項５に記載のＴＣＰプロキシ装置。
【請求項８】
前記ＲＴＴ測定部は、送信するデータパケット内のシーケンス番号と該データパケットを送信した時刻と、前記データパケットに対応して受信するＡＣＫパケット内のＡＣＫ番号と該ＡＣＫパケットが到着した時刻を用い、最大セグメント長をＭＳＳとして、｛ＡＣＫ番号＞シーケンス番号＋ＭＳＳ｝を満たすときの（受信時刻−送信時刻）を前記往復伝搬遅延時間とする、請求項７に記載のＴＣＰプロキシ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１３−３４１０１（Ｐ２０１３−３４１０１Ａ）
【公開日】平成２５年２月１４日（２０１３．２．１４）
【国際特許分類】
【出願番号】特願２０１１−１６９２３０（Ｐ２０１１−１６９２３０）
【出願日】平成２３年８月２日（２０１１．８．２）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２５年２月１４日（２０１３．２．１４）
【国際特許分類】
【出願日】平成２３年８月２日（２０１１．８．２）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]