JP6935799B2 - プロトコル終端装置、中継方法、プログラム - Google Patents

Description

本発明は、プロトコル終端装置、中継方法、プログラムに関する。

近年スマートフォンなどの携帯端末を利用するユーザは、特定サービスに専用のアプリケーションプログラムを携帯端末にダウンロードし、インターネット上に接続されている配信装置により提供されるサービスの提供を受けることができる。このサービスにおいては配信装置と、専用のアプリケーションプログラムを用いた携帯端末との間で制御信号を送受信しながら配信装置が配信データ等の送信制御を行う。配信装置から送信された配信データは携帯端末が受信する。

ところで、そのようなサービスを提供する事業者は、配信装置とスマートフォン上の専用のアプリケーションプログラム間のデータ送受信の制御において独自のルールを適用して配信装置の負荷が軽減されるよう工夫している。例えば、携帯端末などの配信データを要求する要求装置は、配信装置が送信した配信データを受信する。この時、配信データを受信した要求装置は配信データのパケットが到達したことを示す応答などを配信装置に送信する。要求装置からの応答を受信するまでに時間が経過すると、通常、配信装置は配信データの再送を行うが、そのような再送が頻発すると配信装置に負荷がかかる。したがってサービスを提供する業者は要求装置からの応答が無いと判定するまでの期間を短く設定し、その期間を超えたセッションについては配信装置が直ちに切断するよう設定して配信装置の処理負荷を軽減しようと試みる。なお関連する技術が特許文献１に開示されている。

特開２００８−１０４０１８号公報

ところで上述のような技術では配信装置と要求装置との間のプロトコル終端装置などの中継装置において配信データのパケットが滞留するなどした場合には、配信装置が短い期間で（早期に）セッションを切断してしまう。このため、ユーザにとってはサービス提供を満足に受けられない状態となる。また上述の特許文献１の技術は、上記配信装置に対応するサーバ装置と、上記要求装置に対応するクライアント端末とが接続された通信システムにおいて、サーバ装置がクライアント端末へ新たに送信するデータのデータ送信量を制御するものである。

配信装置と要求装置との間の通信経路が単位時間当たりのデータ送信量の異なる通信ネットワークにより構成されており、それら通信ネットワークを接続する中継装置が存在する場合において、上述のような配信装置による早期のセッション切断によるサービス中断を回避できる技術が求められている。

そこでこの発明は、上述の課題を解決するプロトコル終端装置、中継方法、プログラムを提供することを目的としている。

本発明の第１の態様によれば、プロトコル終端装置は、配信装置から送信された配信データを、当該配信データの要求元の要求装置へ転送する転送部と、前記転送の処理においてプロトコル終端装置の送信バッファから前記要求装置へ送信する前記配信データの単位時間当たりの送信量を監視し、当該単位時間当たりの送信量に相当するデータ量の前記配信データの前記配信装置からの送信を要求する抑制制御を行う抑制制御部と、を備える。

また本発明の第２の態様によれば、中継方法は、配信装置から送信された配信データを、当該配信データの要求元の要求装置へ転送し、前記転送の処理において自装置の送信バッファから前記要求装置へ送信する前記配信データの単位時間当たりの送信量を監視し、当該単位時間当たりの送信量に相当するデータ量の前記配信データの前記配信装置からの送信を要求する抑制制御を行う。

また本発明の第３の態様によれば、プログラムはコンピュータに、配信装置から送信された配信データを、当該配信データの要求元の要求装置へ転送し、前記転送の処理において自装置の送信バッファから前記要求装置へ送信する前記配信データの単位時間当たりの送信量を監視し、当該単位時間当たりの送信量に相当するデータ量の前記配信データの前記配信装置からの送信を要求する抑制制御を行う、処理を実行させる。

配信装置と要求装置との間の通信経路が単位時間当たりのデータ送信量の異なる通信ネットワークにより構成されており、それら通信ネットワークを接続するプロトコル終端装置が存在する場合において、配信装置による早期のセッション切断によるサービス中断を回避することができる。

本発明の一実施形態による通信システムの概要を示す図である。 標準のプロトコル終端装置を含む通信ネットワークにおける処理概要を示す図である。 本発明の一実施形態によるプロトコル終端装置の機能ブロック図である。 本発明の一実施形態によるプロトコル終端装置のハードウェア構成図である。 本発明の一実施形態によるプロトコル終端装置を含む通信ネットワークの処理概要を示す図である。 本発明の一実施形態によるプロトコル終端装置の処理フローを示す第一の図である。 本発明の一実施形態によるプロトコル終端装置の処理フローを示す第二の図である。 本発明の一実施形態によるプロトコル終端装置の処理フローを示す第三の図である。 本発明の一実施形態によるプロトコル終端装置の最小構成を示す図である。

以下、本発明の一実施形態によるプロトコル終端装置を備えた通信システムを図面を参照して説明する。
図１は同実施形態による通信システムの概要を示す図である。
この図が示すように通信システムは、配信装置１、要求装置２、プロトコル終端装置（第一中継装置）１０、中継装置（第二中継装置）３が通信ネットワークを介して接続されている。具体的には、配信装置１と要求装置２とがインターネット網などの第一通信ネットワーク（広帯域網）２０と、無線伝送路などの第二通信ネットワーク（狭帯域網）３０を介して接続される。配信装置１と要求装置２との間の伝送経路においてプロトコル終端装置１０と中継装置３が設けられる。プロトコル終端装置１０は第一通信ネットワーク２０を介して配信装置１から配信データを受信して中継装置３へ転送する。中継装置３はプロトコル終端装置１０から受信した配信データを、第二通信ネットワーク３０を介して要求装置２へ転送する。なお第一通信ネットワーク２０は第二通信ネットワーク３０よりも広帯域な通信ネットワークである。
図１に示すような輻輳制御システムにおいて、要求装置２は配信装置１に対して配信データを要求する。配信装置１は要求装置２の要求に基づいて配信データを要求装置２へ送信する。

図２は一般的なプロトコル終端装置を含む通信ネットワークにおける処理概要を示す図である。
プロトコル終端装置１０は第一通信ネットワーク（広帯域網）２０と第二通信ネットワーク（狭帯域網）３０との間の経路に位置する。なお説明の便宜上、図２は、図１で示した中継装置３を除いて図示している。配信装置１と要求装置２が通信を行うとき、その通信を中継するプロトコル終端装置１０は第一通信ネットワーク２０を介して接続されている配信装置１から送信された配信データの通信プロトコルの終端処理を行う。またプロトコル終端装置１０はその終端処理を行った通信プロトコルによって一旦自装置内に蓄積した配信データを要求装置２に向けて転送する。このようなプロトコルの終端処理を行い一方の通信ネットワークから他方の通信ネットワークへＴＣＰ（Transmission Control Protocol）プロトコルの通信を転送することをＴＣＰ_Ｓｐｌｉｔｔｉｎｇと呼ぶことがある。

図２のような通信システムにおいては、上述したように要求装置２からの配信要求に基づいて配信装置１が配信データを要求装置２へ送信する。プロトコル終端装置１０は配信装置１から送信された配信データを効率よく要求装置２へ転送するために、ヘッダ等に設定されるウィンドウサイズの値を大きく設定したパケット（応答）を配信装置１に送信する。このような場合、配信装置１はウィンドウサイズに基づいて配信データを短期間Ｔ１でできるだけ多く送信しようとする。プロトコル終端装置１０の受信バッファのサイズが十分大きければ、短期間Ｔ１で配信データが大量に送信されたとしてもプロトコル終端装置１０はその配信データを受信して受信バッファに蓄積することができる。

プロトコル終端装置１０は配信データの通信の終端処理を行い、送信バッファに配信データを書き込む。プロトコル終端装置１０は送信バッファから第二通信ネットワーク３０を介して接続された要求装置２へ配信データを送信する。ここで第二通信ネットワーク３０は第一通信ネットワーク２０と比較して単位時間当たりに送受信できるデータ量が少ない狭帯域（低帯域）の無線ネットワークであるとする。このような場合、プロトコル終端装置１０は期間Ｔ１の間に配信装置１から受信した配信データを、期間Ｔ１より長い期間Ｔ２程度かけて要求装置２へ送信することとなる。

他方、配信装置１は期間Ｔ１で配信データの総量を送信した後、要求装置２から次の配信要求を受信するまで待機する。配信装置１は期間Ｔ１の期間で配信データの総量を送信した後はセッションを切断するか否かを判断するためのタイマのカウントを開始する（Ｓ１）。このような状況においてプロトコル終端装置１０による配信データの転送に期間Ｔ２の時間がかかった場合、期間Ｔ２の経過前にタイマが満了すると、配信装置１はセッションを切断する（Ｓ２）。配信装置１を運用する業者等はセッションのタイマの満了時間を早めることにより、大量の要求装置２との通信を行う場合などの配信装置１の処理負荷を軽減することができる。つまりタイマの満了時間を早めることで維持するセッションの量が削減される。これにより処理負荷の軽減やＣＰＵ（Central Processing Unit）などのリソース開放を行うことができる。要求装置２は期間Ｔ２の経過時付近で配信データの総量を受信したとする。次の要求がある場合、要求装置２は配信装置１に向けて同一セッションを使用して要求を送信する（Ｓ３）。しかしながらその要求の前に配信装置１がセッションを切断しているとする（Ｓ２）。この場合、配信装置１は、同一セッションによる接続を拒絶する（Ｓ４）。つまり、接続のエラーが生じる。プロトコル終端装置１０はエラーによる切断の返信を要求装置２へ送信する（Ｓ５）。これにより同一セッションによる配信装置１から要求装置２へのサービスの提供が不可能となる。
これに対し、本実施形態によるプロトコル終端装置１０はこのようにサービスの提供が不可能となることを回避し、効率よく配信データを転送することができる。

図３はプロトコル終端装置の機能ブロック図である。
図３で示すように、プロトコル終端装置１０は、起動後にプログラムを実行することにより、転送部１１、抑制開始判定部１２、抑制制御部１３の各機能を備える。
転送部１１は、配信装置１から送信された配信データを、当該配信データを要求する要求装置２へ転送する。
抑制開始判定部１２は、抑制制御を開始するか否かを判定する。
抑制制御部１３は、転送の処理において自装置の送信バッファ１６（図４）から要求装置２へ送信する配信データの単位時間当たりの送信量を監視する。抑制制御部１３はその監視結果に基づいて、単位時間当たりの送信量に相当するデータ量の配信を配信装置１へ要求する抑制制御を行う。

図４はプロトコル終端装置のハードウェア構成図である。
この図で示すようにプロトコル終端装置１０は、ＣＰＵ４１、記憶部４２、通信部４３などのハードウェアを有するコンピュータである。記憶部４２はＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）などであってよい。通信部４３は受信バッファ１５、送信バッファ１６を備える。

図５は本実施形態によるプロトコル終端装置を含む通信ネットワークの処理の概要を示す図である。
次にプロトコル終端装置１０の処理の概要を説明する。
図２で示した例と同様に、プロトコル終端装置１０は第一通信ネットワーク（広帯域網）２０と第二通信ネットワーク（狭帯域網）３０との間の経路上に位置する。配信装置１と要求装置２が通信を行うとき、その通信を中継するプロトコル終端装置１０は第一通信ネットワーク２０を介して接続されている配信装置１から送信された配信データの通信プロトコルの終端処理を行う。またプロトコル終端装置１０はその終端処理を行った配信データを要求装置２に向けて転送する。

そして要求装置２は配信データの配信要求を配信装置１に送信する（Ｓ５０１）。要求装置２からの配信要求に基づいて配信装置１が配信データを要求装置２へ送信する（Ｓ５０２）。プロトコル終端装置１０は配信装置１から送信された配信データを効率よく要求装置２へ転送するために、ヘッダ等に設定されるウィンドウサイズを大きくしたパケットを配信装置１に送信する。プロトコル終端装置１０は配信装置１から受信した配信データのパケットを受信して受信バッファ１５に順次蓄積する。プロトコル終端装置１０は、受信バッファ１５に蓄積する配信データを送信バッファ１６に書き込み、要求装置２へ順次送信する。この時、プロトコル終端装置１０の抑制開始判定部１２は抑制制御を開始するかどうかを判定する。抑制開始判定部１２は、例えば、自装置の受信バッファ１５に蓄積するデータ量を、自装置における現在の単位時間当たりの送信量で除して得た受信バッファ蓄積評価値が、その閾値（蓄積量閾値）を超える場合に、抑制制御を開始すると判定する。プロトコル終端装置１０の抑制制御部１３は抑制制御において、自装置における現在の単位時間当たりの送信量に相当するデータ量の配信データを当該単位時間に送信するよう配信装置１を制御する。例えば抑制制御部１３は、抑制制御において配信装置１へ送信待機要求を送信する。この送信待機要求はウィンドウ０応答である。ウィンドウ０応答は、ウィンドウサイズに「０（ゼロ）」を指定した応答である。配信装置１はウィンドウ０応答を受信すると配信データの送信を一時中断する（Ｓ５０３）。そして配信装置１はプロトコル終端装置１０からウィンドウサイズが「０」ではない応答が返ってくるまで、配信データの送信を待機する。プロトコル終端装置１０はウィンドウサイズを調整することにより、現在の自装置の単位時間当たりの送信量に相当するデータ量が、当該単位時間に送信されるよう配信装置１を制御することとなる。
このような処理により、配信装置１にセッションタイムアウト（タイマの満了時間）の短縮設定がされている場合にも、配信装置１がタイムアウトを検出して要求装置２との間に張られているセッションを早期に切断することがなくなる。

図６はプロトコル終端装置の処理フローを示す第一の図である。
次にプロトコル終端装置１０の処理フローについて順を追って説明する。
図５を用いて説明したように、要求装置２の配信要求に基づいて配信装置１が配信データを送信する。プロトコル終端装置１０の転送部１１は受信した配信データを中継装置３へ転送する。

転送部１１が中継装置３へ配信データを転送している状況において、抑制開始判定部１２は抑制開始判定処理を行う。抑制開始判定部１２はこの処理において、配信データの総データ量ＣＬ（Ｃｏｎｔｅｎｔ Ｌｅｎｇｔｈ）を特定可能であるか否かを判定する（ステップＳ６１）。通常は配信装置１が配信データのヘッダ等に配信データの総データ量を格納して配信データを送信している。配信装置１の配信する配信データがストリーミングデータや、暗号化データである場合には配信データの総データ量を確認できないこともある。抑制開始判定部１２は配信データの総データ量ＣＬが特定可能な場合（ステップＳ６１のＹＥＳ）、後続の抑制開始判定処理を行う。一方、抑制開始判定部１２は総データ量ＣＬが特定できない場合には（ステップＳ６１のＮＯ）、ステップＳ６３の処理に移行する。

配信データの総データ量ＣＬが特定可能である場合、抑制開始判定部１２は、その配信データの総データ量ＣＬが、中継装置３の受信バッファ１５に設定された総データ量閾値Ｘ（第一の抑制開始閾値（第一閾値））よりも大きいかを判定する（ステップＳ６２）。配信データの総データ量ＣＬが総データ量閾値Ｘよりも大きい場合には（ステップＳ６２のＹＥＳ）、抑制開始判定部１２はその配信データについて後続の抑制開始判定処理を行う。一方、配信データの総データ量ＣＬが総データ量閾値Ｘ以下の場合には（ステップＳ６２のＮＯ）抑制開始判定部１２は、ステップＳ６９の標準の転送処理を行うと判定する。

転送部１１は、ステップＳ６１において総データ量ＣＬが特定できない場合（ステップＳ６１のＮＯ）、または、総データ量ＣＬが閾値Ｘよりも大きい場合に（ステップＳ６２のＹＥＳ）配信データをまず中継する（ステップＳ６３）。この中継においては出来るだけ多くの配信データを中継できるよう制御する標準の転送処理を行う。そして抑制開始判定部１２は送信バッファ１６から転送している配信データの現在の単位時間当たりの送信量を示すスループットＴＰを算出する。抑制開始判定部１２は、現在のスループットＴＰがスループット閾値Ｙ（第二の抑制開始閾値（第二閾値））以上か否かを判定する（ステップＳ６４）。スループット閾値Ｙは現在のスループットＴＰが十分であるかを判定する為の値である。スループットＴＰがスループット閾値Ｙ未満である場合（ステップＳ６４のＮＯ）、スループットＴＰが十分でないことを示す。スループットＴＰが十分である場合、つまり閾値Ｙ以上の場合（ステップＳ６４のＹＥＳ）、抑制開始判定部１２は標準の転送処理（ステップＳ６９）を行うと判定する。一方、スループットＴＰが十分でない場合、つまりスループットＴＰが閾値Ｙ未満の場合（ステップＳ６４のＮＯ）、抑制開始判定部１２は後続の抑制開始判定処理を行う。

抑制開始判定部１２は後続の抑制開始判定処理において、要求装置２へ送信済みの配信データのうち要求装置２から受信確認を受けていない配信データのデータ量の合計ＳＵＭ（ＩＦ）を算出する。「ＩＦ」は「Inflight」の略でありプロトコル終端装置１０から要求装置２の間で滞留しているパケットのデータ量を示す。受信確認を受けたか否かは、ＨＴＴＰ（Hypertext Transfer Protocol）の通信におけるＡＣＫ（acknowledgement）が要求装置２から配信装置１へ返信されたかどうかにより特定される。プロトコル終端装置１０が中継装置３に向けて配信データを転送した後に、要求装置２からその配信データについてのＡＣＫを示すデータ（パケット）を受信した場合、プロトコル終端装置１０はその配信データが要求装置２に到達したことを検知する。一方、要求装置２からプロトコル終端装置１０にＡＣＫが返信されていないデータ（パケット）は中継装置３のバッファ内にまだ残されている可能性が有る。抑制開始判定部１２は要求装置２に送信したパケットの情報を記憶しておき、ＡＣＫが返信されていないパケットのデータ量を合計することによりＳＵＭ（ＩＦ）を算出することができる。

プロトコル終端装置１０の抑制開始判定部１２はＳＵＭ（ＩＦ）を算出することにより、プロトコル終端装置１０から中継装置３に向けて転送され、未だ要求装置２に到達していないデータ量を算出する。プロトコル終端装置１０の抑制開始判定部１２は、ＳＵＭ（ＩＦ）と、中継装置３の受信バッファ閾値Ｚ（第三の抑制開始閾値（第三閾値））を示すデータ量とを比較して、ＳＵＭ（ＩＦ）が中継装置３の受信バッファ閾値Ｚを示すデータ量以下かを判定する（ステップＳ６５）。ＳＵＭ（ＩＦ）が中継装置３の受信バッファ閾値Ｚを示すデータ量より大きい場合には（ステップＳ６５のＮＯ）、抑制開始判定部１２は後続の抑制開始判定処理を行う。一方、ＳＵＭ（ＩＦ）が中継装置３の受信バッファ閾値Ｚを示すデータ量以下の場合には（ステップＳ６５のＹＥＳ）、抑制開始判定部１２は標準の中継処理（ステップＳ６９）を行うと判定する。ＳＵＭ（ＩＦ）が中継装置３の受信バッファ閾値Ｚを示すデータ量以下の場合は配信データがスムーズに流れている可能性が高いため、配信装置１でセッションが切断される可能性が低い。したがって、標準の中継処理が行われる。他方、ＳＵＭ（ＩＦ）が中継装置３の受信バッファ閾値Ｚを示すデータ量より大きい場合には、抑制開始判定部１２は後続の抑制開始判定処理を行うと決定する。

抑制開始判定部１２は後続の抑制開始判定処理において、自装置の受信バッファ１５に蓄積するデータ量ＲＳＣＢ（Receive Socket Buffer Size）を、単位時間当たりの送信量であるスループットＴＰで除して（ＲＳＣＢ÷ＴＰ）、受信バッファ蓄積評価値を算出する。抑制開始判定部１２はその受信バッファ蓄積評価値と蓄積量閾値Ｔｈを比較して、受信バッファ蓄積評価値が蓄積量閾値Ｔｈ以下か否かを判定する（ステップＳ６６）。受信バッファ蓄積評価値が蓄積量閾値Ｔｈ以下である場合（ステップＳ６６のＹＥＳ）、プロトコル終端装置１０が中継装置３に転送する効率が良い。このため、抑制開始判定部１２は、標準の中継処理（ステップＳ６９）を行うと決定する。一方、受信バッファ蓄積評価値が蓄積量閾値Ｔｈより大きい場合には（ステップＳ６６のＮＯ）、プロトコル終端装置１０が中継装置３に送信するデータの転送効率は低く、配信装置１によってセッションが切断されてしまう可能性が高まる。したがって抑制開始判定部１２は受信バッファ蓄積評価値が蓄積量閾値Ｔｈより大きい場合には、抑制制御（ステップＳ６７）を開始すると判定する。

抑制開始判定部１２が抑制制御を開始すると判定すると、抑制制御部１３は、自装置の送信バッファ１６から要求装置２へ送信する配信データの単位時間当たりの送信量を監視する。抑制制御部１３は、当該単位時間当たりの送信量に相当する単位時間当たりの量の配信データの配信を配信装置１に要求する。これにより配信装置１は、プロトコル終端装置１０が要求装置２に向けて転送する単位時間当たりのデータ量に相当する配信データを単位時間当たりに送信する（ステップＳ６７）。抑制制御部１３は抑制制御の処理を終了した後は、配信データの総量の転送処理を行ったかを判定し（ステップＳ６８）、総量の転送処理を行った場合には（ステップＳ６８のＹＥＳ）その配信データについての処理を終了する。また配信データの総量の転送を行って行いない場合には（ステップＳ６８のＮＯ）、抑制制御部１３は、その配信データについてステップＳ６３の処理から繰り返す。

なおステップＳ６２、ステップＳ６４、ステップＳ６５、ステップＳ６６の処理において抑制制御の候補となる配信データが削減される。このような削減によって、最終的に抑制制御を行う配信データを絞り込むことができる。これにより、標準の転送制御以外の処理を行うことによるプロトコル終端装置１０の負荷を軽減することができる。なお、ステップＳ６２、ステップＳ６４、ステップＳ６５の処理の何れか１つまたは複数の処理を行わないようにしてもよい。なお、図６のフローチャートによると、ステップＳ６２において、配信データの総データ量ＣＬが総データ量閾値Ｘよりも大きい場合に（ステップＳ６２のＹＥＳ）、抑制開始判定部１２は後続の抑制開始判定処理を行う。ただし、抑制開始判定部１２は、配信データの総データ量ＣＬが総データ量閾値Ｘ以上である場合に、後続の抑制開始判定処理を行ってもよい。

図７はプロトコル終端装置の処理フローを示す第二の図である。
図７では、図６のフローチャートで上述した抑制制御の処理（ステップＳ６７）の具体例について説明する。
抑制制御部１３は抑制制御を開始すると、プロトコル終端装置１０における送信側のスループットＴＰを監視する（ステップＳ７１）。抑制制御部１３はプロトコル終端装置１０における送信側のスループットＴＰと、プロトコル終端装置１０における受信側の受信スループットＲＴＰとが同等となるよう制御する（ステップＳ７２）。具体的には、送信側のスループットＴＰに応じて、ウィンドウ０応答を配信装置１に送信する。これにより配信装置１はウィンドウ０を受信した後に配信データの転送を中断して待機する。配信装置１による余計な配信データの送信が待機されるため、プロトコル終端装置１０における送信側のスループットＴＰと、プロトコル終端装置１０における受信側の受信スループットＲＴＰとが同等に維持される。配信装置１は、配信データの転送の待機状態においてウィンドウサイズを問い合わせる信号をプロトコル終端装置１０へ送信する。その結果ウィンドウ０応答ではないウィンドウサイズ０より大きい値が示されている応答を受信した場合、配信データの送信を再開する。このように抑制制御部１３はプロトコル終端装置１０における送信側のスループットＴＰと、プロトコル終端装置１０における受信側の受信スループットＲＴＰとが同等となるよう制御する。

抑制制御部１３は配信データの総量の転送処理が完了したかを判定し（ステップＳ７３）、総量の転送処理が完了した場合には（ステップＳ７３のＹＥＳ）その配信データについての抑制制御の処理を終了する。また、配信データの総量の転送処理が完了していない場合には（ステップＳ７３のＮＯ）、抑制制御部１３は単位時間当たりのＳＵＭ（ＩＦ）の値が変動したか否かを判定する（ステップＳ７４）。抑制制御部１３はＳＵＭ（ＩＦ）の値が変動した場合には（ステップＳ７４のＹＥＳ）、ステップＳ７１の処理から繰り返して、新たな送信側のスループットＴＰを算出する。一方、抑制制御部１３はＳＵＭ（ＩＦ）の値が変動していない場合には（ステップＳ７４のＮＯ）、ステップＳ７２の処理から繰り返す。

図８はプロトコル終端装置の処理フローを示す第三の図である。
図８では、図７のフローチャートで上述のスループットＴＰの監視処理（ステップＳ７１）について詳しく説明する。
抑制制御部１３はスループットＴＰの監視を開始すると、タイマＴをスタートする（ステップＳ７１１）。抑制制御部１３はタイマＴが、その満了を判定するための閾値Ｗ以上か否かを判定する（ステップＳ７１２）。抑制制御部１３は、タイマＴが閾値Ｗ未満である場合には（ステップＳ７１２のＮＯ）、送信バッファ１６からの配信データの送信を継続する（ステップＳ７１３）。次に抑制制御部１３は配信データの総量の送信が完了したか否かを判定する（ステップＳ７１４）。そして送信完了した場合には（ステップＳ７１４のＹＥＳ）抑制制御部１３はその配信データについての監視処理を終了する。また抑制制御部１３は配信データの総量の送信が完了していない場合には（ステップＳ７１４のＮＯ）ステップＳ７１２から処理を繰り返す。ステップＳ７１２においてタイマＴが閾値Ｗ以上であると判定すると（ステップＳ７１２のＹＥＳ）、抑制制御部１３は、タイマＴのスタート時から満了するまでの間に送信した配信データのデータ量を閾値Ｗが示す時間で除して、スループットＴＰを算出する（ステップＳ７１５）。これによりスループットＴＰが算出できる。また抑制制御部１３は、スループットＴＰをメモリ等に記録する（ステップＳ７１６）。抑制制御部１３はまたタイマＴをリセットする（ステップＳ７１７）。抑制制御部１３は抑制制御を行っている間、スループットＴＰの監視において上記ステップＳ７１１〜ステップＳ７１７の処理を繰り返す。

上述の処理によれば、プロトコル終端装置１０は自装置の送信側のスループットＴＰと、自装置の受信側の受信スループットＲＴＰとが同等となるよう配信装置１から配信される単位時間当たりのデータ量を制御する。これにより配信装置１がタイムアウトによりセッションを切断するタイミングが無くなる。このため、配信装置１において独自のルールに基づいた要求装置２からの応答が無いことによる早期のセッションの切断の動作を回避することができる。

図９は一実施形態のプロトコル終端装置の最小構成を示す図である。
この図が示すようにプロトコル終端装置１０は、少なくとも転送部１１と、抑制制御部１３とを備える。

上述のプロトコル終端装置１０では、受信バッファ１５においてできるだけ多くの配信データを蓄積しておくことで効率よく配信データの転送を行う。つまり、プロトコル終端装置１０は受信バッファ１５の容量を配信装置１に通知する際に、その値を減少させず、常に広告ウィンドウサイズを大きくしたまま維持する。これにより、プロトコル終端装置１０の送信側の輻輳や効率の改善が成された際に、受信バッファ１５に蓄積しているデータを活用して即座に送信量を増大させることが可能となる。同時に、受信バッファ１５に蓄積されていたデータを要求装置２側に送信している間に配信装置１からも単位時間当たりの送信データ量が改善した状態で配信データを取得する事でより効率よく転送処理を行うことができる。

さらに上述のプロトコル終端装置１０によれば、効果実現の為に配信装置１に対向する自装置（プロトコル終端装置１０）の通信インターフェースの受信性能やリソース抑制を行う必要が無い。一般的な方式における受信性能を抑制する手法としては受信バッファサイズを小さくし、配信装置１との通信における通信性能自体の上限を抑制する事で瞬間的データ受信速度を低くする方式がある。但し、この方式の場合、配信装置１との通信状態(ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ)により、その効果が左右されてしまい、確実な効果を得る事が出来ない。また、効果を求め過ぎて通信性能に制限を掛け過ぎると要求装置２との通信状態が改善された場合にプロトコル終端装置１０自体が通信性能のボトルネックになってしまう可能性が有る。これに対し、上述の実施形態は、通信性能自体に制限を掛ける事無く受信制限を行う事で、抑制制御の解消時には元の通信性能を保つことができる方法である。

さらに上述のプロトコル終端装置１０によれば、配信装置から送信された配信データの総データ量ＣＬが閾値以上である場合、または、閾値より大きい場合に抑制制御を行っている。このため、プロトコル終端装置１０は、総データ量ＣＬが小さい場合には標準の転送処理を行う。これにより、プロトコル終端装置１０は、総データ量ＣＬが小さい配信データは抑制制御を一切行わない為、その配信データの通信効率を落とすことが無い。またプロトコル終端装置１０は、総データ量を特定できなかった場合でも、その配信データの送信効率（スループットＴＰ）を周期的に監視して効率が悪くなった場合にのみ抑制制御を行う。このため、プロトコル終端装置１０は、送信処理の最初からその配信データの通信効率に影響を与えない。

上述の各装置は内部にコンピュータシステムを有している。そして、各装置に上述した各処理を行わせるためのプログラムは、それら各装置のコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムを各装置のコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。
また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。

また、上記プログラムは、前述した各処理部の機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

この出願は、２０１６年９月２３日に日本出願された特願２０１６−１８５２６１号を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明によれば、配信装置と要求装置との間の通信経路が単位時間当たりのデータ送信量の異なる通信ネットワークにより構成されており、それら通信ネットワークを接続するプロトコル終端装置が存在する場合において、配信装置による早期のセッション切断によるサービス中断を回避することができる。

１・・・配信装置
２・・・要求装置
３・・・中継装置
１０・・・プロトコル終端装置
１１・・・転送部
１２・・・抑制開始判定部
１３・・・抑制制御部
１５・・・受信バッファ
１６・・・送信バッファ
２０・・・第一通信ネットワーク
３０・・・第二通信ネットワーク

Claims (8)

1. 配信装置から送信された配信データを、当該配信データの要求元の要求装置へ転送する転送部と、
   前記転送の処理において自装置の送信バッファから前記要求装置へ送信する前記配信データの単位時間当たりの送信量を監視し、当該単位時間当たりの送信量に相当するデータ量の前記配信データの前記配信装置からの送信を要求する抑制制御を行う抑制制御部と、
   自装置の受信バッファに蓄積するデータ量を前記単位時間当たりの送信量で除して得た受信バッファ蓄積評価値が蓄積量閾値を超える場合に、前記抑制制御を行うと判定する抑制開始判定部と、
   を備え、
   前記抑制開始判定部は、前記配信データの送信開始から送信終了までのデータ総量が第一閾値以上であるかを判定し、前記データ総量が前記第一閾値以上である場合に、前記抑制制御を行うと判定する、
   プロトコル終端装置。
2. 前記抑制制御部は、前記要求装置へ転送済みの前記配信データのうち前記要求装置から受信確認を受けていない前記配信データのデータ量の変化を判定し、当該データ量に変化があった場合に、前記単位時間当たりの送信量を再計算する
   請求項１に記載のプロトコル終端装置。
3. 前記抑制制御部は、前記抑制制御において前記配信装置へ送信待機要求を送信する請求項１または請求項２に記載のプロトコル終端装置。
4. 前記送信待機要求はウィンドウサイズに０を指定した応答である請求項３に記載のプロトコル終端装置。
5. 前記抑制開始判定部は、前記要求装置へ転送する前記配信データの前記単位時間当たりの送信量が第二閾値未満であるかを判定し、前記単位時間当たりの送信量が前記第二閾値未満である場合に、前記抑制制御を行うと判定する
   請求項１乃至請求項４の何れか一項に記載のプロトコル終端装置。
6. 前記抑制開始判定部は、前記要求装置へ転送済みの前記配信データのうち前記要求装置から受信確認を受けていない前記配信データのデータ量が、第三閾値より大きい場合に、前記抑制制御を行うと判定する
   請求項１乃至請求項５の何れか一項に記載のプロトコル終端装置。
7. 配信装置から送信された配信データを、当該配信データの要求元の要求装置へ転送し、
   前記転送の処理において自装置の送信バッファから前記要求装置へ送信する前記配信データの単位時間当たりの送信量を監視し、当該単位時間当たりの送信量に相当するデータ量の前記配信データの前記配信装置からの送信を要求する抑制制御を行い
   自装置の受信バッファに蓄積するデータ量を前記単位時間当たりの送信量で除して得た受信バッファ蓄積評価値が蓄積量閾値を超える場合に、前記抑制制御を行うと判定する、
   方法であって、
   前記配信データの送信開始から送信終了までのデータ総量が第一閾値以上であるかを判定し、前記データ総量が前記第一閾値以上である場合に、前記抑制制御を行うと判定する、
   中継方法。
8. コンピュータに、
   配信装置から送信された配信データを、当該配信データの要求元の要求装置へ転送し、
   前記転送の処理において自装置の送信バッファから前記要求装置へ送信する前記配信データの単位時間当たりの送信量を監視し、当該単位時間当たりの送信量に相当するデータ量の前記配信データの前記配信装置からの送信を要求する抑制制御を行い、
   自装置の受信バッファに蓄積するデータ量を前記単位時間当たりの送信量で除して得た受信バッファ蓄積評価値が蓄積量閾値を超える場合に、前記抑制制御を行うと判定する、
   処理を実行させるプログラムであって、
   前記配信データの送信開始から送信終了までのデータ総量が第一閾値以上であるかを判定し、前記データ総量が前記第一閾値以上である場合に、前記抑制制御を行うと判定する、
   プログラム。

Images