JP2010224821A - リクエスト受付方法およびシステム - Google Patents
リクエスト受付方法およびシステム Download PDFInfo
- Publication number
- JP2010224821A JP2010224821A JP2009070795A JP2009070795A JP2010224821A JP 2010224821 A JP2010224821 A JP 2010224821A JP 2009070795 A JP2009070795 A JP 2009070795A JP 2009070795 A JP2009070795 A JP 2009070795A JP 2010224821 A JP2010224821 A JP 2010224821A
- Authority
- JP
- Japan
- Prior art keywords
- access path
- request
- access
- end server
- user terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】エンドサーバのサービス処理レートに基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを制御するリクエスト受付方法およびシステムを提供する。
【解決手段】ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバAPSが、エンドサーバへのサービス要求を試行するサービス要求試行部16と、試行したサービス要求の処理時間に基づいてエンドサーバの能力を計測するサーバ能力計測部17と、アクセスパス要求を受信するアクセスパス要求受信部11と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいてエンドサーバへのアクセスタイミングを決定するアクセスタイミング決定部13と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成部14と、アクセスパス応答をユーザ端末へ返信するアクセスパス応答返信部15とを含む。
【選択図】図2
【解決手段】ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバAPSが、エンドサーバへのサービス要求を試行するサービス要求試行部16と、試行したサービス要求の処理時間に基づいてエンドサーバの能力を計測するサーバ能力計測部17と、アクセスパス要求を受信するアクセスパス要求受信部11と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいてエンドサーバへのアクセスタイミングを決定するアクセスタイミング決定部13と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成部14と、アクセスパス応答をユーザ端末へ返信するアクセスパス応答返信部15とを含む。
【選択図】図2
Description
本発明は、ユーザ端末から送信されたアクセスパス要求を予め受け付けて、各ユーザ端末からエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するリクエスト受付方法およびシステムに関する。
災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるエンドサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。これは同サービスを利用するユーザの満足度を低下させると共に、リクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。
イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、瞬間的には10倍から100倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。
一方、2003年12月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。
特許文献1には、アクセス集中により受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるシステムが開示されている。
ここでは、サービスを提供するエンドサーバに多数のアクセスが集中すると、受け付けられないユーザに対して、現在混んでいる旨と、次回優先接続される時間帯が提示される。同ユーザが改めて優先接続時間帯にアクセスしてきた場合、このリクエストメッセージは他のリクエストメッセージよりも優先的に受け付けられる。
しかしながら、特許文献1では一のユーザがリクエストメッセージを送信した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザがリクエストメッセージを送信した際に受付側の負荷が解消していると、当該他の一のユーザのリクエストメッセージが先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。
このような技術課題に対して、本発明の発明者等は特許文献2および非特許文献1において、ユーザにサービスを提供するエンドサーバとは別に、ユーザ端末から事前に送信されるアクセスパス要求を受け付けて各ユーザ端末からエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するアクセスサーバを設けることにより、ユーザ端末からのアクセスを漏れなく、かつ順序逆転なく公平に受け付けられるようにしたリクエスト受付方法およびシステムを提案している。
「整理券発行機能を用いたアクセス制御システムの提案」,信学技法 vol.1 108 No.218, p81-p86.
エンドサーバにおいてユーザ端末からのサービス要求のアクセスを滞りなく処理するためには、エンドサーバに入力されるサービス要求の周期とエンドサーバが一つのサービス要求を処理するのに要する時間、すなわちサービス時間TAT(Turn Around Time)とが一致していることが望ましい。そこで、上記した特許文献2および非特許文献1に開示された技術では、各エンドサーバのサービス時間を予め統計的に推定し、この推定値に従ってサービス要求が各エンドサーバで処理されるという前提で各ユーザ端末のアクセスタイミングを決定していた。
しかしながら、例えばコンテンツ配信のサービス要求に応答してエンドサーバがユーザ端末へ動画などのコンテンツを配信するサービスでは、エンドサーバのサービス時間がユーザ端末におけるコンテンツのダウンロード速度に依存する。そして、ユーザ端末のダウンロード速度は、アクセス回線の容量や接続方式(有線LANまたは有線LANなど)に依存するので、提供するサービスが同一であってもエンドサーバのサービス時間が一定になるとは限らない。
したがって、上記の従来技術では、エンドサーバのサービス時間に関する推定値と実績値とに乖離が生じる場合があり、これが大きくなると、推定値<実績値であればエンドサーバに輻輳が生じ、その逆に推定値>実績値であればエンドサーバの運用効率が低下してしまう。
本発明の目的は、上記した従来技術の課題を解決し、エンドサーバの実際のサービス時間(実績処理レート)に基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを適正に制御できるリクエスト受付方法およびシステムを提供することにある。
上記した目的を達成するために、本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、このアクセスパスサーバが以下のような手段を具備した点に特徴がある。
(1)ユーザ端末からアクセスパス要求を受信するアクセスパス要求受信手段と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、アクセスパス応答を要求元にユーザ端末へ返信するアクセスパス応答返信手段と、エンドサーバへのサービス要求を試行するサービス要求試行手段と、試行したサービス要求の実績処理レートを計測するサーバ能力計測手段と、計測結果に基づいてエンドサーバの能力を見直す見直手段とを具備したことを特徴とする。
(2)サービス要求試行手段は、第1の周期でサービス要求を試行した際の実績処理レートに基づいてサーバ能力を見直すか否かを決定し、エンドサーバの能力を見直す際は前記第1の周期よりも短い第2の周期でサービス要求を繰り返し試行し、見直手段は、第2の周期でサービス要求を繰り返し試行して得られた複数回の処理レートに基づいてエンドサーバの能力を見直すことを特徴とする。
本発明によれば、以下のような効果が達成される。
(1)エンドサーバの実績処理レート(サービス時間と同義)を監視し、この監視結果に基づいて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定するので、エンドサーバにサービス要求が集中して輻輳を生じさせたり、あるいはサービス要求が規制され過ぎてエンドサーバの運用効率を低下させたりすることなく、各ユーザ端末に対して最適なアクセスタイミングを決定できるようになる。
(2)アクセスパスサーバからエンドサーバへのサービス要求の試行が、最初は第1の周期で行われ、サーバ能力を見直す必要があると判定されると、今度は第1の周期よりも短い第2の周期で繰り返される。したがって、常時は試行の周期を長くすることができ、エンドサーバの負荷を軽減できるようになる。
以下、図面を参照して本発明の実施の形態について詳細に説明する。 図1は、本発明のリクエスト受付システムが適用されるネットワークの構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES(サービス提供サーバ)へコンテンツの配信サービスを要求する場合を例にして説明する。
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは基地局APを経由して携帯電話網あるいはインターネット等のIPネットワークNWに接続されている。また、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESjが、アクセスパスサーバAPSと共に前記IPネットワークNWに接続されている。
前記アクセスパスサーバAPSは、各ユーザ端末MNにエンドサーバESjへのアクセス(サービス要求)を許可するタイミングを決定して各ユーザ端末MNへ通知する機能を備え、ユーザ端末MNから、アクセス先のエンドサーバESjの識別情報およびコンテンツの識別情報などを含むアクセスパス要求のメッセージを受信すると、エンドサーバESjの能力や状況に基づいてアクセスタイミングを決定し、これを要求元のユーザ端末MNへ通知する。ユーザ端末MNは、通知されたアクセスタイミングを待ってエンドサーバESjへサービス要求を送信し、当該エンドサーバESjからコンテンツ配信などのサービスを受ける。
図2は、前記アクセスパスサーバAPSの主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。なお、アクセスパスサーバAPSが各ユーザ端末MNからアクセスパス要求を受信するごとに実行する応答処理は低負荷なので、アクセスパス要求が短時間に集中的に受信される場合でも、アクセスパスサーバAPSは全てのアクセスパス要求を受信順に滞りなく受付処理できる。
アクセスパス要求受信部11は、各ユーザ端末MNから送信されたアクセスパス要求を受信する。サーバ処理管理部12は、各エンドサーバESjにおけるサービス要求の処理状況をキュー値で仮想的に管理する。
アクセスタイミング決定部13は、各エンドサーバESjがユーザ端末MNから受信した一つのサービス要求を処理するのに要するサービス時間TATを、各エンドサーバESjにおけるサービスの処理状況をアクセスパスサーバAPS上で模すための仮想的な処理レートCjとして管理する処理レート管理部131を具備し、後に詳述するように、前記サーバ処理管理部12で管理されている各エンドサーバESjのキュー値や処理レートCjをパラメータとして、各ユーザ端末MNに対して許可する各エンドサーバESjへのアクセスタイミングをアクセスパス要求ごとに決定する。
アクセスパス応答生成部14は、エンドサーバESjへのアクセスタイミングを含むアクセスパス応答を生成する。アクセスパス応答返信部15は、前記アクセスパス応答を前記アクセスパス要求の送信元に返信する。
サービス要求試行部16は、ダミーのサービス要求を各エンドサーバESjへ周期的に送信するサービス要求送信部161と、前記サービス要求に応答して各エンドサーバESjで開始されたサービスの終了を検知するサービス終了検知部162とを含む。
サーバ能力計測部17は、前記サービスの開始タイミングおよび終了タイミングに基づいて各エンドサーバESjの実績処理レートCrealを算出する実績処理レート算出部171と、前記実績処理レートCrealに基づいて、前記処理レート管理部131で管理されている各エンドサーバの処理レートCjを見直す処理レート見直部172とを含む。
次いで、フローチャートを参照して本実施形態の動作を詳細に説明する。図3は、コンテンツ配信を要求するユーザ端末MNにおけるリクエスト処理の手順を示したフローチャートであり、図4,5,6,7,8は、アクセスパスサーバAPSの動作を示したフローチャートである。
ユーザがユーザ端末MNのキースイッチ等を操作してコンテンツのリクエスト操作を実施し、これが図3のステップS11で検知されるとステップS12へ進む。ステップS12では、リクエストするコンテンツの識別子および当該コンテンツを提供するエンドサーバESjの識別子を含み、アクセスパスサーバAPSを宛先とするアクセスパス要求が生成され、ステップS13において送信される。
図4へ進み、アクセスパスサーバAPSは、図4のステップS31において前記アクセスパス要求を受信すると、ステップS32では、前記アクセスタイミング決定部13において、ユーザ端末MNに前記エンドサーバESjへのアクセスを許可するタイミングが以下の手順で決定される。
図5は、アクセスタイミング決定処理の手順を示したフローチャートであり、主に前記アクセスタイミング決定部13の動作を示している。なお、各符号の定義は以下の通りである。
i:アクセスパス要求の識別子
j:エンドサーバESの識別子
ti,j:エンドサーバESjに対するi番目のアクセス要求時刻
di,j:エンドサーバESjに対するi番目のアクセス要求に対して割り当てられるアクセスタイミングまでの待機時間
Cj:各エンドサーバESjの処理能力(処理レート)
Qmax_j:各エンドサーバESjのキュー値の上限値
bi,j:重み値
δ:アクセスパスサーバAPSからユーザ端末MNへのアクセスパス要求の想定伝達遅延時間
Qj(ti,j)−:時刻tiでアクセスパス要求を受信する直前のエンドサーバESjのキュー値
Qj(ti,j)+:時刻tiでアクセスパス要求を受信した直後のエンドサーバESjのキュー値
pj:エンドサーバESjへアクセスパス要求を送信したユーザ端末MNが、許可されたアクセスタイミングでエンドサーバESjへサービス要求を送信する推定確率
j:エンドサーバESの識別子
ti,j:エンドサーバESjに対するi番目のアクセス要求時刻
di,j:エンドサーバESjに対するi番目のアクセス要求に対して割り当てられるアクセスタイミングまでの待機時間
Cj:各エンドサーバESjの処理能力(処理レート)
Qmax_j:各エンドサーバESjのキュー値の上限値
bi,j:重み値
δ:アクセスパスサーバAPSからユーザ端末MNへのアクセスパス要求の想定伝達遅延時間
Qj(ti,j)−:時刻tiでアクセスパス要求を受信する直前のエンドサーバESjのキュー値
Qj(ti,j)+:時刻tiでアクセスパス要求を受信した直後のエンドサーバESjのキュー値
pj:エンドサーバESjへアクセスパス要求を送信したユーザ端末MNが、許可されたアクセスタイミングでエンドサーバESjへサービス要求を送信する推定確率
図5のステップS321では、受信したアクセスパス要求に登録されている識別子に対応したエンドサーバESjに関して、前回のアクセスパス要求を時刻[ti-1]で受信した直後のキュー値[Qj(ti-1,j)+]が前記サーバ処理管理部12から取り込まれる。本実施形態では、一つのキューが一つのサービス要求を代表している。
ステップS322では、エンドサーバESjの処理レートCjが処理レート管理部131から取り込まれる。なお、この処理レートCjは、後に図8のフローチャートを参照して詳述するように、各エンドサーバESjの負荷に応じて動的に見直される。ステップS323では、時刻[ti,j]でエンドサーバESj宛のアクセスパス要求を受信する直前の当該エンドサーバESjの未処理リクエスト量、すなわちキュー値[Qj(ti,j)−]が次式(1)で求められる。
ステップS324では、時刻[ti,j]でアクセスパス要求を受信した直後のキュー値[Qj(ti,j)+]が次式(2)で求められる。
ここで、重み値[bi,j]はサービス要求を処理するエンドサーバESjの処理負荷に依存し、例えば、アクセスパス要求が音楽コンテンツの配信要求であれば、リクエストする音楽ファイルのサイズが大きいほど大きな重み値bi,jが割り当てられる。なお、重み付けが不要であれば、前記重み値[bi,j]には所定の定数(例えば、「1」)が割り当てられる。
ステップS325では、アクセスパス要求を送信したユーザ端末MNに通知するアクセスタイミングが、当該アクセスパス要求の受信時刻[ti,j]を基準にした待機時間[di,j]として次式(3)で求められる。ステップS326では、前記キュー値[Qj(ti,j)+]の計算結果が前記サーバ処理管理部12へ更新登録される。
なお、ユーザ端末MNがアクセスパス応答を受信しても、回線状況の変化等が原因で、許可されたアクセスタイミングにおいてサービス要求を送信できなくなる場合がある。次式(4)では、このような状況を考慮して、サービス要求を送信したユーザ端末MNが、さらにサービス要求を送信する推定確率pj(ti,j)をエンドサーバESjごとに統計的に求めて前記待機時間[di,j]に反映させている。
図6は、前記推定確率Pj(ti,j)をエンドサーバESjへのアクセスレートに基づいて算出する手順を示したフローチャートである。
ステップS71において、エンドサーバESjに関するアクセスパス要求が受信されると、ステップS72では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるエンドサーバESjへのアクセス数ni,j、すなわちサービス要求の総数が算出される。
ステップS73では、今回のアクセスパス要求を受信する直前のエンドサーバESjのキュー値[Qj(ti,j)−]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)−]がゼロよりも大きければステップS74へ進み、キュー値[Qj(ti,j)−]が最後にゼロとなった以降の累積アクセス数Mおよび経過時刻Tが算出される。ステップS75では、エンドサーバESjへの平均アクセスレートARj(ti,j)が、前記累積アクセス数Mおよび経過時刻Tに基づいて算出される。ステップS76では、次式(5)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは0<Pmin<1の定数である。
これに対して、前記ステップS73においてキュー値[Qj(ti,j)−]がゼロと判定されると、ステップS77において推定確率Pj(ti,j)に「1」が登録される。ステップS78では、前記累積アクセス数Mおよび経過時刻Tがリセットされる。
図7は、前記推定確率Pj(ti,j)をサービス要求やコンテンツのボリューム(以下、アクセスボリュームで総称する)に基づいて算出する手順を示したフローチャートである。
ステップS81において、エンドサーバESjに関するアクセスパス要求が受信されると、ステップS82では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるエンドサーバESjのアクセスボリュームvi,jが算出される。
ステップS83では、今回のアクセスパス要求を受信する直前のエンドサーバESjのキュー値[Qj(ti,j)−]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)−]がゼロよりも大きければステップS84へ進み、キュー値[Qj(ti,j)−]が最後にゼロとなった以降の累積アクセスボリュームWおよび経過時刻Tが算出される。ステップS85では、エンドサーバESjへの平均アクセスボリュームVRj(ti,j)が、前記累積アクセスボリュームWおよび経過時刻Tに基づいて算出される。ステップS86では、次式(6)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは0<Pmin<1の定数である。
これに対して、前記ステップS83においてキュー値[Qj(ti,j)−]がゼロと判定されると、ステップS87において推定確率Pj(ti,j)に「1」が登録される。ステップS88では、前記累積アクセスボリュームWおよび経過時刻Tがリセットされる。
図4へ戻り、ステップS33では、前記アクセスタイミングとしての待機時間[di,j]を含むアクセスパス応答が前記アクセスパス応答生成部14で生成され、ステップS34において、前記アクセスパス応答返信部15から、前記アクセスパス要求を送信したユーザ端末MN宛に返信される。
図3へ戻り、ユーザ端末MNでは、前記アクセスパス応答がステップS14で受信されると、ステップS15では、このアクセスパス応答に登録されているアクセスタイミングとしての待機時間[di,j]が抽出される。ステップS16では、抽出された待機時間[di,j]が所定の上限値dmaxと比較され、待機時間[di,j]>dmaxであればステップS17へ進み、サービスを提供できない旨のエラーメッセージを端末ディスプレーに表示して当該処理を中止する。これに対して、待機時間[di,j]≦dmaxであればステップS18へ進み、図9(a),(b)に一例を示したように、リクエストが先着順に処理されている旨を示す受付完了メッセージが端末ディスプレーに表示される。
ステップS19では、配信を要求するコンテンツの識別子およびエンドサーバの識別子を含むコンテンツ要求がサービス要求として生成される。ステップS20では、前記ステップS13においてアクセス要求パスを送信してからの経過時間が前記待機時間[di,j]に達したか否かに基づいてアクセスタイミングであるか否かが判定され、アクセスタイミングを待ってステップS21へ進む。ステップS21では、前記ステップS19で生成されたサービス要求(ここでは、コンテンツ配信要求)が、前記エンドサーバESjを宛先として送信される。このようなユーザ端末MNにおけるアクセスタイミングまでの待機処理は、Java(登録商標)scriptなどの各種スクリプト言語やFlash機能を利用することで実装できる。
このサービス要求を受信したエンドサーバESjは、要求されているコンテンツを用意して前記ユーザ端末MNへ配信する。
ユーザ端末MNは、前記コンテンツをステップS22で受信すると、ステップS23へ進んで当該コンテンツを保存する。ステップS24では、図10に一例を示したダウンロード完了メッセージが端末ディスプレーに表示される。
図8は、各エンドサーバESjの処理レートCjを動的に見直すサービス要求試行部16およびサーバ能力計測部17の動作を示したフローチャートである。
ステップS49では、未だ処理負荷の低い監視対象のエンドサーバESjに対して、前記サービス要求試行部16によりダミーのサービス要求が試行され、その応答が受信される。ステップS50では、前記サーバ能力計測部17により、前記試行されたサービス要求およびその応答に基づいて、試行された一つのサービス要求をエンドサーバESjが処理するのに要するサービス時間が計測され、これがエンドサーバESjの現在の実績処理レートCrealとされる。
図11,12,13は、実績処理レートCrealの計測方法の一例を示したシーケンスフローであり、サービス要求およびサービス応答がTCPセッションを利用して行われる場合、SYN/FINパケット、HTTP METHOD、あるいはHTTPメッセージボディを監視することで実績処理レートCrealが求められる。
図11は、サービス開始時刻およびサービス終了時刻をSYN/FINパケットに基づいて推定する方法を模式的に表現した図である。
TCPセッションは複数(N個)のTCPコネクションにより構成され、各TCPコネクションはアクセスパスサーバAPSから送信されるSYNパケットに対してエンドサーバESjがSYN-ACKを返信し、さらにアクセスパスサーバAPSからエンドサーバESjへACKパケットが送信されることにより確立される。そして、このようにして確立されたTCPコネクションは、アクセスパスサーバAPSおよびエンドサーバESjの双方がFIN-ACKを交換することで切断される。
そこで、本実施形態ではエンドサーバESjから送信された最初のSYN-ACKがアクセスパスサーバAPSで受信された時刻をサービス開始時刻とし、さらに、N回目のFIN-ACK交換においてアクセスパスサーバAPSからFIN-ACKが送信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
なお、前記TCPコネクション数(N個)はサービス内容に依存するので、アクセスパスサーバAPSは事前に各エンドサーバESjから各サービスのTCPコネクション数(N個)を取得しておくことが望ましい。
また、各TCPコネクションが同一のTCPセッションに係るものであるか否かは、例えば送信元IPアドレスおよびport番号が同一、かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断できる。あるいは、送信元端末固有のIDが同一かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断しても良い。
図12は、実績処理レートCrealをHTTP METHODに基づいて推定する方法を模式的に表現した図である。この方法では、アクセスパスサーバAPSからHTTP METHOD(例えば、GET,POSTなど)が送信された時点でアクセスパスサーバAPSとエンドサーバESjとの間にTCPコネクションが確立されたものと判断し、当該時刻がサービス開始時刻とされる。
そして、N回目のFIN-ACK交換においてアクセスパスサーバAPSからFIN-ACKが送信された時刻がサービス終了時刻とされ、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
図13は、実績処理レートCrealをHTTPメッセージボディに基づいて推定する方法を模式的に表現した図である。この方法では、セッション開始を意味する識別コード(たとえば、「start」などの文字列)の登録されているHTTPメッセージボディがアクセスパスサーバAPSから送信された時刻がサービス開始時刻とされる。
そして、セッション終了を意味する識別コード(たとえば、「finish」などの文字列)の登録されているHTTPメッセージボディがアクセスパスサーバAPSから送信された時刻がサービス終了時刻とされ、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
図8へ戻り、ステップS51では、前記ステップS50で計測された現在の実績処理レートCrealが標準処理レートC1とされる。ステップS52では、アクセスパスサーバAPSがエンドサーバESjの実績処理レートCrealを監視する周期Uに標準周期U1が設定される。ステップS53では、監視周期Uの監視タイミングであるか否かが判定され、監視タイミングであればステップS54へ進む。
ステップS54では監視対象のエンドサーバESjに対して、前記サービス要求試行部16によりダミーのサービス要求が試行され、その応答が受信される。ステップS55では、前記試行されたサービス要求およびその応答に基づいて、前記と同様にエンドサーバESjの現在の実績処理レートCrealが計測される。本実施形態では、前記サービス要求の試行がエンドサーバESjにとって負荷とならないように前記標準周期U1が設定されている。
ステップS56では、現在の実績処理レートCrealと標準処理レートC1との乖離が閾値Crefと比較される。エンドサーバESjの処理負荷が未だ低くければ乖離が閾値Cref以下となるので、現在の処理レートCjが適正と判定されてステップS53へ戻り、現在の監視周期U(=Uref)での監視が繰り返される。
これに対して、エンドサーバESjの処理負荷が上昇し、乖離が閾値Crefを上回るようになるとステップS57へ進み、エンドサーバESjの監視周期Uが見直されて現在の標準監視周期U1よりも短い周期U2に変更される。図14は、監視周期Uが変更される様子を模式的に示した図であり、時刻t1において乖離が大きいと判定されると、それ以降、監視周期UがU1からU2に短縮されている。
ステップS58では、見直し後の短い監視周期U(=U2)の監視タイミングであるか否かが判定され、監視タイミングであればステップS59へ進む。ステップS59では、監視対象のエンドサーバESjに対してダミーのサービス要求が試行され、その応答が受信される。ステップS60では、前記試行されたサービス要求およびその応答に基づいて、前記と同様に現在の実績処理レートCrealが計測される。ステップS61ではサービス要求の試行回数が判定され、n回の試行が繰り返されるまでステップS58へ戻る。本実施形態では、前記監視周期U2もサービス要求の試行がエンドサーバESjにとって負荷とならない時間に設定されている。
その後、周期Uでのn回の試行が完了するとステップS62へ進み、n回のサービス要求の試行で得られた実績処理レートCrealの平均値Cave(平均処理レート)が算出される。ステップS63では、標準処理レートC1と前記平均処理レートCaveとが比較され、C1≒Cave であれば、現在の処理レートCjが適正と判定されてステップS52へ戻り、監視周期Uを初期値1に戻して上記の処理が繰り返される。
これに対して、C1≒CaveでなければステップS64へ進み、C1とCaveとの差分(C1−Cave)が相対的な乖離度として算出され、これを現在の処理レートCjから減じた値が新たな処理レートCjとされる。ステップS65では、標準処理レートC1が平均処理レートCaveに更新され、その後、ステップS52へ戻って上記の各処理が繰り返される。
なお、上記した実施形態では、ユーザ端末MNがコンテンツ配信用のアクセスパスを予め取得し、このアクセスパスによって許可されたアクセスタイミングでエンドサーバESjへコンテンツ要求を送信してコンテンツをダウンロードする場合を例にして説明したが、本発明はこれのみに限定されるものではなく、ユーザ端末がデータやコンテンツをエンドサーバESjへアップロードするためのアクセスパスを予め取得し、許可されたアクセスタイミングでアップロードを実行する場合にも同様に適用できる。
1…リクエスト応答部,2…リクエスト受付部,11…リクエスト受信部,12…サーバ処理管理部,13…アクセスタイミング決定部,14…アクセスパス応答生成部,15…アクセスパス応答返信部,16…サービス要求試行部,17…サーバ能力計測部
Claims (5)
- ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
ユーザ端末からアクセスパス要求を受信するアクセスパス要求受信手段と、
受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、
前記アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、
前記アクセスパス応答を要求元にユーザ端末へ返信するアクセスパス応答返信手段と、
エンドサーバへのサービス要求を試行するサービス要求試行手段と、
前記試行したサービス要求の実績処理レートを計測するサーバ能力計測手段と、
前記計測結果に基づいてエンドサーバの能力を見直す見直手段とを具備したことを特徴とするリクエスト受付システム。 - 前記サービス要求試行手段は、第1の周期でサービス要求を試行した際の実績処理レートに基づいてサーバ能力を見直すか否かを決定し、エンドサーバの能力を見直す際は前記第1の周期よりも短い第2の周期でサービス要求を繰り返し試行し、
前記見直手段は、前記第2の周期でサービス要求を繰り返し試行して得られた複数回の処理レートに基づいてエンドサーバの能力を見直すことを特徴とする請求項1に記載のリクエスト受付システム。 - 前記サーバ能力計測手段は、サービスの開始時刻から終了時刻までのサービス時間に基づいてエンドサーバの処理レートを計測することを特徴とする請求項1または2に記載のリクエスト受付システム。
- 前記ユーザ端末が
アクセスパス要求をアクセスパスサーバへ送信する手段と、
アクセスパス応答を受信する手段と、
前記アクセスパス応答からアクセスタイミングを抽出する手段と、
前記アクセスタイミングを待ってサービス要求をエンドサーバへ送信する手段とを含むことを特徴とする請求項1ないし3のいずれかに記載のリクエスト受付システム。 - ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付方法において、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
ユーザ端末からアクセスパス要求を受信する手順と、
受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定する手順と、
前記アクセスタイミングを含むアクセスパス応答を生成する手順と、
前記アクセスパス応答を要求元にユーザ端末へ返信する手順と、
エンドサーバへのサービス要求を試行する手順と、
前記試行したサービス要求の実績処理レートを計測する手順と、
前記計測結果に基づいてエンドサーバの能力を見直す手順とを具備したことを特徴とするリクエスト受付方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009070795A JP2010224821A (ja) | 2009-03-23 | 2009-03-23 | リクエスト受付方法およびシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009070795A JP2010224821A (ja) | 2009-03-23 | 2009-03-23 | リクエスト受付方法およびシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2010224821A true JP2010224821A (ja) | 2010-10-07 |
Family
ID=43041949
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009070795A Pending JP2010224821A (ja) | 2009-03-23 | 2009-03-23 | リクエスト受付方法およびシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2010224821A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012046689A1 (ja) | 2010-10-04 | 2012-04-12 | 株式会社エヌ・ティ・ティ・ドコモ | フィードバック方法及び移動端末装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003203031A (ja) * | 2002-01-08 | 2003-07-18 | Hitachi Information Systems Ltd | ウェブサイトにおける手続完了目安時間の検出方法及びその表示方法 |
JP2007026303A (ja) * | 2005-07-20 | 2007-02-01 | Fujitsu Ltd | システム性能監視プログラム及びシステム性能監視方法 |
-
2009
- 2009-03-23 JP JP2009070795A patent/JP2010224821A/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003203031A (ja) * | 2002-01-08 | 2003-07-18 | Hitachi Information Systems Ltd | ウェブサイトにおける手続完了目安時間の検出方法及びその表示方法 |
JP2007026303A (ja) * | 2005-07-20 | 2007-02-01 | Fujitsu Ltd | システム性能監視プログラム及びシステム性能監視方法 |
Non-Patent Citations (2)
Title |
---|
CSNJ200910065098; 稗圃 泰彦: '整理券発行機能によるアクセス制御システムにおけるサーバ負荷推定法' 電子情報通信学会2008年通信ソサイエティ大会講演論文集2 , 20080902, 98, 社団法人電子情報通信学会 * |
JPN6013041950; 稗圃 泰彦: '整理券発行機能によるアクセス制御システムにおけるサーバ負荷推定法' 電子情報通信学会2008年通信ソサイエティ大会講演論文集2 , 20080902, 98, 社団法人電子情報通信学会 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012046689A1 (ja) | 2010-10-04 | 2012-04-12 | 株式会社エヌ・ティ・ティ・ドコモ | フィードバック方法及び移動端末装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105493449B (zh) | 用于速率控制的方法和设备 | |
US8599695B2 (en) | Selective internet priority service | |
CN108141443A (zh) | 用户设备和媒体流传输网络辅助节点 | |
CN106612284B (zh) | 一种流数据的传输方法和装置 | |
JP2015511409A5 (ja) | ||
CN107070990A (zh) | 数据资源传输的方法和设备 | |
Huang et al. | Reliable realtime streaming in vehicular cloud-fog computing networks | |
CN106936730A (zh) | 一种报文发送方法、tcp代理以及tcp客户端 | |
JP4915622B2 (ja) | サーバ輻輳制御方法およびシステム | |
US8055782B2 (en) | System and method for generating exception delay messages when messages are delayed | |
EP2769575B1 (en) | Method and apparatus for controlling data transmission in a communication system | |
JP2010224821A (ja) | リクエスト受付方法およびシステム | |
CN106453119A (zh) | 一种认证控制方法及装置 | |
JP4646931B2 (ja) | サーバ装置およびリクエスト整理方法 | |
CN106470421A (zh) | 一种防止恶意终端非法占用核心网资源的方法和设备 | |
JP2010231353A (ja) | 自立型アクセス集中緩和システム | |
EP3412047B1 (en) | Method and network entity for control of charging for value added service (vas) | |
CN106330495A (zh) | 一种核心网网元处理终端注册拥塞的方法及装置 | |
JP4958225B2 (ja) | リクエスト受付方法およびシステム | |
EP3989506A1 (en) | Server communication method, broadband access server, and system | |
JP5702232B2 (ja) | サーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラム | |
JP2010224822A (ja) | リクエスト受付方法およびシステム | |
JP4897644B2 (ja) | 端末に対するアクセス数制御方法、端末、制御サーバ及びプログラム | |
TWI795274B (zh) | 基於傳輸控制協定封包標頭的雜湊值決定用戶平面功能服務模組的方法及系統 | |
CN110572465B (zh) | 一种报文传输方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110822 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130819 |
|
A131 | Notification of reasons for refusal |
Effective date: 20130828 Free format text: JAPANESE INTERMEDIATE CODE: A131 |
|
A02 | Decision of refusal |
Effective date: 20131218 Free format text: JAPANESE INTERMEDIATE CODE: A02 |