JP3857228B2 - Web情報優先転送システム - Google Patents
Web情報優先転送システム Download PDFInfo
- Publication number
- JP3857228B2 JP3857228B2 JP2002513169A JP2002513169A JP3857228B2 JP 3857228 B2 JP3857228 B2 JP 3857228B2 JP 2002513169 A JP2002513169 A JP 2002513169A JP 2002513169 A JP2002513169 A JP 2002513169A JP 3857228 B2 JP3857228 B2 JP 3857228B2
- Authority
- JP
- Japan
- Prior art keywords
- web
- priority
- user
- proxy server
- site
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2458—Modification of priorities while in transit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/748—Negotiation of resources, e.g. modification of a request
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
本発明は、Web情報優先転送システムに係り、TCP/IPを利用したWebサービスを提供する通信網で、Webサービスを受ける際に利用者、サイトの通信の優先度を設定可能にし、しかも、既存のインターネット網をそのまま利用できるようなWeb情報優先転送システムに関する。
背景技術
近年、Webを利用したサービスやアプリケーションの増加により、Web情報の送受信が増大している。このようなWebに関する通信トラフィックが増加すると、ネットワークの回線容量が不足し、サービスのレスポンスが低下すると言う事態を生じる。また、一般にインターネットの通信は、Web情報の重要度と関係なくできるだけ公平にトラフィックを配送しようとするので、重要なトラフィックとそうでないトラフィック共に一様に影響を受けることになる。そこで、重要度の高いネットワークサービスに対して、レスポンス時間を確保するため、トラフィックの重要度を識別した優先制御をおこなう必要がある。
これに対しWebを含めた従来のトラフィックの識別、優先制御方式には、主に次の四つの方式がある。
第一は、TCP/UDPのポート番号をルータが識別し、ルータの配送で優先制御する方式である。この方式では、ルータが、IPパケットのヘッダに含まれるポート番号、送信元IP、送信先IPを用いてトラフィックを識別して優先制御する。一般的に、クライアントサーバ型のネットワークアプリケーションでは、特定のポート番号を利用して通信するので、この方式では、ルータが、アプリケーションの種類、クライアント、サーバを識別し優先制御できる。
第二は、IPパケットのType of ServiceのPrecedenceフィールドでパケットを識別し、ルータが優先制御する方式である。この方式では、クライアントサーバ型のネットワークアプリケーションにおいて、クライアントとサーバが、通信する際にパケットのType of Serviceに優先情報を付加し、アプリケーションがデータフローごとに優先度を指定できる。
第三は、RSVP(Resource Reservation Protocol)を利用する方式である。この方式は、送信前に、経路を構成する機器に対して通信帯域の確保を要求するパケットを送信し、経路上の各機器の通信帯域を確保した後、通信する。この方式では、アプリケーションが、データフローごとに送信前に通信帯域を確保できるので、データフローごとにレスポンス時間を保証できる。
第四は、パケットシェイピングと呼ばれる方式である。これは、クライアントサーバ型のネットワークアプリケーションのデータフローを、クライアントとサーバ間の経路上において、ポート番号、送信元IP、送信先IPで識別する。そして、データフローのリクエスト間隔、ネットワークウィンドウサイズを制御し、データフローごとに優先制御する。この方式では、パケットシェイパが、アプリケーションの種類、クライアント、サーバを識別し優先制御できる。
上記、第一、第二の優先制御方式は、Douglas Comer著「TCP/IPネットワーク構築Vol1」に、第三の方式はRFC(Request for Comments)の2205に詳述されている。
上記従来技術の第一の方式のデータフローをポート番号で識別する方式では、アプリケーションの種類でしかデータフローを識別できない。
Webサービスは、一般に同一のポート番号を利用するので、Webリクエストごとに識別することができず、Webごとの優先制御や帯域保証をすることができない。
それゆえ、Webを利用した配信サービスやストリームサービス、Web化した業務アプリケーションといった、トラフィック量、要求するレスポンス時間、優先度などの性質が異なるサービスへのWebリクエストが同一に扱われるので、重要なWebリクエストのトラフィックが圧迫され、レスポンスが低下するという問題点があった。
さらに、Webアプリケーションのトラフィック量は、クライアントからサーバへ向かう量よりも、サーバからクライアントへ向かう量の方が多いので、サーバからクライアントへ向かうトラフィックに対して優先制御する方が効果がある。しかし、Webアプリケーションは、不特定のサーバを利用するので、サーバまたは経路全体で制御が必要な優先制御方式は、実現が困難である。例えば、上記第三の方式では、経路の全て装置がRSVPのプロトコルを理解できる必要がある。
一般に、インタネット網で通信帯域が小さくなるのは、LANなどの企業網から、公衆回線を介してプロバイダのインターネットにアクセスするところであり、これがインターネットを利用する際のボトルネックとなる。このボトルネックとなる通信経路の下り回線の優先制御をできれば効果的である。
また、上記第一ないし第四の全ての従来技術で、Webリクエストごとに優先制御や帯域保証をするという発想がないので、プロバイダ等のインターネット接続サービスや、企業等のサイト接続サービスでは、利用者のWebリクエストはすべて同一の優先度である。利用者が早いレスポンスでWebサービスを利用したい場合でも、他の利用者が回線の通信帯域を使い切っている場合には、遅いレスポンスでしかWebサービスを利用できない。さらに、Webサービスの利用量が多い利用者と、利用量が少ない利用者に対しても、同一課金で同一品質のサービスしか提供できないという一種の不公平が生じる。
本発明は、上記問題点を解決するためになされたもので、その目的は、利用者や企業などのサイトがインターネットを利用して、Webサービスを受けるに際し、品質や課金に応じて優先度をつけてサービスを受けることが可能であり、しかも、利用者の利用するクライアント、Webサーバ、経路など既存のインターネット網を利用可能なWeb情報優先転送システムを提供することにある。
発明の開示
Web情報優先転送システムにおいて、利用者のサイトで個人優先度と、サイト優先度の二段階の優先度を設定できるようにする。利用者のサイトでは、LAN側プロキシサーバにより設定できるサイト優先度が、リクエストを出すときの優先度である。プロバイダ側に置かれるWAN側プロキシサーバは、そのリクエストのサイト優先度を取りだし、通信状況や設定に応じて最終優先度に変換する。そして、Webリクエストに対して返答されるWebオブジェクトのIPパケットの優先制御パラメタに変換して、LAN側プロキシサーバに中継するようにする。また、WAN側プロキシサーバ内で最終優先度に基づき、優先制御をするようにしても良い。
プロバイダでの課金は、利用した通信内容と要求した優先度に基づいておこなうようにする。
発明を実施するための最良の形態
以下、第1図ないし第28図を用いて本発明に係る各実施形態を説明する。
〔実施形態1〕
以下、第1図ないし第24図を用いて本発明に係る第一の実施形態を説明する。
(I)システム概要
先ず、第1図を用いて本発明の第一の実施形態に係るWeb情報優先転送システムのシステム概要を説明する。
第1図は、本発明の第一の実施形態に係るWeb情報優先転送システムのシステム概要を説明するための図である。
本発明は、利用者がWebサーバ130にアクセスするときに、その通信を制御するものである。特に、第1図にも示されているように、利用者がWebサーバ130にリクエストを出し、Webオブジェクトを受け取るときには、Webサーバ130から利用者の方向、いわゆる「下り」の方がトラフィックが大きくなる傾向があるので、そこの通信を制御することを主眼としている。
先ず、利用者104が自分の利用している利用者計算機103から、ブラウザを利用して、あるホームページを見たいときには、自分の属するサイトのLAN側プロキシサーバ110を対してWebリクエストを出す。LAN側プロキシサーバ110は、公衆網に接続されているプロバイダ網のWAN側プロキシサーバ120にWebリクエストを出し、さらに、WAN側プロキシサーバ120は、Webサーバ120にWebリクエストを伝えることになる。そして、下りは、この逆の方向に、Webサーバ130から、WAN側プロキシサーバ120、LAN側プロキシサーバ110を経由して、利用者計算機103にWebオブジェクトが伝えられることになる。
このとき、利用者104は、自分のWebリクエストに対して優先度を設定することができる。すなわち、重要で緊急を要するようなWebリクエストは、高い優先度を設定することになる。これが、個人優先度である。
また、利用者の属するサイトのサイト管理者105は、自分のサイトの管理上の観点と、個人優先度を考慮して、サイトでの通信制御の方針であるサイトポリシを予め定めておく。そして、このサイトポリシに基づき、サイト優先度を設定して、WAN側プロキシサーバ120にWebリクエストをするのに際して、サイト優先度を送る。
WAN側プロキシサーバ120は、Webサーバ130から送られたデータを転送するときに、そのサイト優先度に基づいて、通信パケットを優先転送したり、通信帯域を保証するなどの処理をする。
これが、本実施形態の基本的な仕組みである。
(II)システム構成
次に、第2図を用いて本発明の第一の実施形態に係るWeb情報優先転送システムのシステム構成を説明する。
第2図は、本発明の第一の実施形態に係るWeb情報優先転送システムのシステム構成図である。
本システムは、以下の三つの装置から構成される。すなわち、インターネット接続サービスを提供するプロバイダ102内のWAN側プロキシサーバ120と、サイト101内のLAN側プロキシサーバ110と、利用者104が利用する利用者計算機103がそれである。
サイト101内には、利用者計算機103、LAN側プロキシサーバ110がある。利用者104は、実際にインターネットによりWebを利用する者である。一方、サイト104を管理する者として、サイト管理者105を想定している。
データとしては、利用者の個人情報を管理する個人情報管理表106が置かれている。
利用者計算機103は、利用者がWeb情報を見るときのブラウザ150を起動するようなパーソナルコンピュータを想定している。LAN側プロキシサーバ110は、利用者計算機103とローカルエリアネットワークで接続されていて、外部のインターネット網と接続するサーバであり、利用者104からWebリクエストにサイト優先度を付加する役割を担っている。
利用者計算機103内には、ブラウザ150とソフトウェアプロキシ140の二つのアプリケーションが実行されている。
ブラウザ150は、Webサーバから送られてきたcookieを保存するcookie管理表151を持ち、ソフトウェアプロキシ140に現在表示しているWebアプリケーションのURL(Uniform Resource Locator)を通知する機能を持つ。ここで、cookieとは、Webサーバがユーザを識別するための情報であり、Webサーバは、このcookieを用いてユーザを管理する。
ソフトウェアプロキシ140は、利用者計算機103内で実行されるソフトウェアであり、利用者の定める優先度の方針である個人ポリシにより個人優先度を設定して、WebリクエストをLAN側プロキシサーバ110に中継する機能を有する。このソフトウェアプロキシ140は、個人ポリシ設定手段143、個人ポリシ管理表144、個人優先度決定手段141、中継処理手段142を持っている。個人ポリシ設定手段143は、利用者が個人ポリシを設定するためのインタフェースを提供し、その入力を個人ポリシ管理表144に反映して保管する。中継処理手段142は、WAN側プロキシサーバ120とLAN側プロキシサーバを介し、110Webサーバ130から返送されてくるWebオブジェクトを受け取って中継する機能を有している。
なお、個人ポリシは、優先制御の対象にするWebページのURLと、それに対する個人優先度の対として表現されるものであり、詳細については後に説明することになる。
LAN側プロキシサーバ110は、利用者計算機103からのWebリクエストを外部のインターネット網に中継するために置かれるサーバであり、Webリクエストに対して、サイト優先度を設定し付加する機能を有している。このLAN側プロキシサーバ110は、サイトポリシ管理表114、優先度決定手段111、転送先切替え手段112、中継処理手段113、利用統計管理表115、通信記録を格納する通信記録管理表116を持っている。
サイトポリシ管理表114には、サイト管理者105が決定したサイトポリシが格納されている。優先度決定手段111は、利用者のWebリクエストを解析しサイト優先度を決定する。
転送先切替え手段112は、優先度が定められているときに、WAN側プロキシサーバ120にWebリクエストを送信する機能を有している。
中継処理手段113は、WAN側プロキシサーバ120を介してWebサーバ130から送られてくるWebオブジェクトを受信して、次の利用者計算機103に中継する部分である。
また、利用統計管理表115には、利用者の通信の利用料が格納され、通信記録管理表116には、利用者の通信記録が格納されて管理できるようになっている。
一方、プロバイダ102内のサイトは、利用者から送られてくるWebリクエストをWebサーバ130に中継するためのWAN側プロキシサーバ120が置かれている。
LAN側プロキシサーバ110から送られてくるWebリクエストには、サイト優先度が付加されているので、それに基づき、そのWebリクエストに対する応答として返送されるWebオブジェクトの通信の制御をおこなう。また、プロバイダ網には、WAN側プロキシサーバ120を管理するために、プロバイダ管理者が置かれる。
WAN側プロキシサーバ120は、中継処理手段121、要求解析手段122、トラフィック制御手段123、トラフィック量管理表126、IP優先度設定手段124、IP優先度マップ表125、フロー管理表128がある。
中継処理手段121は、サイト101からのWebリクエストをWebサーバに中継する部分である。
要求解析手段122は、サイト101からのWebリクエスト内に優先度情報が含まれるかを解析する。トラフィック制御手段123は、Webリクエストに付加されているサイト優先度の情報と現在のトラフィック量に基づいてWebオブジェクトのトラフィックを制御するように動作する。具体的には、Webリクエストに付加されてくるサイト優先度を、現実のトラフィック量に基づいて、最終的な優先度(以下、「最終優先度」と言う)を定める処理をおこなう。
トラフィック量管理表126は、Webオブジェクトの現在のトラフィックを管理するためのデータが格納されている。
プロバイダのサイトは、Webリクエストをフローと言う概念で管理し、各々にフロー番号が付されている。フロー管理表128は、各々のフローのトラフィックを制御するためのデータを格納するものである。
本実施形態の優先制御の仕組みは、サイト101で設定されてWebリクエストに付加された優先度を、そのリクエストの返答として送られくるWebオブジェクトのパケットのパラメタに反映させてトラフィックを制御しようといるものである。すなわち、サイト101で設定される個人優先度やサイト優先度や、それに基づいてトラフィック制御手段123により定められる最終優先度は、通信モデルで言う所のアプリケーション層で設定されるものであるが、その優先度をIP層にあたるTCP/IPのパケットのパラメタに反映させようとするものである。
IP優先度設定手段124は、Webリクエストのフローに対して、上記の仕組みに基づいてトラフィック制御手段123により定められる最終優先度を、対応するWebオブジェクトのパケットのパラメタ(以下、「優先制御パラメタ」と言う。)に反映させる部分である。
IP優先度マップ表125は、IP優先度設定手段124が最終優先度から優先制御パラメタに変換する際のルールを規定するためのデータが格納されている。
(III)システムに用いられるデータ構造
次に、第5図ないし第14図を用いて本発明の第一の実施形態に係るWeb情報優先転送システムのシステムに用いられるデータ構造について説明する。
第5図は、個人ポリシ管理表144の例を示す模式図である。
第6図は、個人情報管理表106の例を示す模式図である。
第7図は、サイトポリシ管理表114の例を示す模式図である。
第8図は、利用統計管理表115の例を示す模式図である。
第9図は、トラフィック量管理表126の例を示す模式図である。
第10図は、フロー管理表128の例を示す模式図である。
第11図は、IP優先度マップ表125の例を示す模式図である。
第12図は、優先度をWebリクエストへ付加するときに利用するhttpリクエストヘッダの構造の例を示す模式図である。
第13図は、本実施形態に係るIPパケットの例を示す模式図である。
第14図は、通信記録表116の例を示す模式図である。
第5図に示される個人ポリシ管理表144は、個人ポリシを、対象となるWebリクエストの条件とそれに対する個人優先結果の対として表現する表である。
対象とするWebリクエストの条件として、リクエスト先URL620、対象オブジェクト621、指定範囲属性622、時刻623の項目を持ち、個人優先結果として個人優先度624、保証帯域625の項目を持っている。また、レコードの意味は、リクエスト先URL620、対象オブジェクト621、指定範囲属性622、時刻623が全て満たされたWebリクエストの個人優先度結果は、そのレコードの個人優先度624、保証帯域625とすると言う意味である。
リクエスト先URLは、対象なるリクエストのURLを指定するフィールドである。この欄には、URLを直接記述できる外、「全て」や「アクティブブラウザ」などのキーワードも指定できる。「全て」と記述した場合には、全てのURLが対象となり、「アクティブブラウザ」と記述した場合には、ウィンドウがアクティブになっているブラウザのURLが対象となる。対象オブジェクト種別621は、Webリクエストで対象となるオブジェクトの種別を指定するフィールドであり、例えば、図の様に、ファイル種別の拡張子や「全て」などのキーワードを指定する。指定範囲属性622は、指定したURLの範囲をさらに細かく設定するフィールドであり、図の様なキーワードを指定できるものとする。
個人優先度623は、図の例では、高いものから順に「優先」、「通常」、「低優先」の三種類指定できることにした。また、個人優先結果としては、保証帯域624のフィールドでも、その通信に係る保証帯域を記述することによっても指定できる。
第6図に示される個人情報管理表106は、システムが、個人を認証し管理するためのデータを記録する表であり、ユーザ名630、ユーザID631、パスワード632の項目を持つ。ユーザ名630は、通常の個人の名前である。ユーザID631は、システムが個人を識別するための一意的なキーである。パスワード632は、その個人の認証のために使われる。
第7図に示されるサイトポリシ管理表114は、サイト101でのサイトポリシを定めるルールを記述する表であり、対象となるWebリクエストの条件とそれに対するサイト優先結果の対として表現される。
対象となるWebリクエストの条件は、リクエスト先URL640、対象オブジェクト種別641、指定範囲属性642、ユーザID643、個人優先度644、利用量645、時刻646の項目であり、サイト優先結果としては、サイト優先度647、保証帯域648の項目である。このサイトポリシ管理表114も、全ての対象となるWebリクエストの条件を満たすWebリクエストに対して、サイト優先度結果を定めると言う意味である。また、特に注意するのは、個人優先度644が条件の中に含まれており、個人優先度がサイト優先度に反映される点である。
リクエスト先URL640、対象オブジェクト種別641、指定範囲属性642の意義は、第5図の個人ポリシ管理表のときと同様である。ユーザID643は、このポリシの対象とするユーザのIDであり、第6図の個人情報管理表106のユーザID631のフィールドで定義されたものである。個人優先度644は、個人ポリシ管理表144の個人優先度623のフィールドにより定義される優先度である。利用量645は、回線をどれだけ使っているかを表すトラフィック量である。時刻646は、このサイトポリシを適用する通信時刻を表す。
サイト優先度647は、以上の対象となるWebリクエストの条件を満たしたときに、定められるサイトの優先度であり、第7図の例では、4段階になっている。ここでは、数値が少ないものほど優先度が高いものとする。保証帯域648は、Webリクエストの条件を満たしたときに、サイトとして保証する帯域量である。
第8図に示される利用統計管理表115は、利用者の過去のWebサービス利用量を示す表であり、利用者毎に、これまでのサイトでの通信のトラフィック量の累積量が示される。利用統計管理表115は、ユーザID650、個人優先度の別のトラフィック量651、652、653を持っている。
第9図に示されるトラフィック管理表126は、WAN側プロキシサーバ120においてトラフィック制御をする際に用いられる表であり、優先度ごとに現状のトラフィック量と割り当て可能な上限値を示すものである。優先度660は、WAN側プロキシサーバ120でトラフィック制御に用いる最終優先度である。トラフィック量661は、現状その優先度で通信しているトラフィック量であり、マップ可能トラフィック量662は、その優先度で割り当てることのできるトラフィック量の上限値である。
第10図に示されるフロー管理表128は、WAN側プロキシサーバ120内のWebリクエストと、その返答として送られるWebオブジェクトを、フローとして管理する表である。Webリクエストと、その返答として送られるWebオブジェクトに関する通信は、WAN側プロキシサーバ120内でフロー番号を付して管理される。
フロー管理表128は、フロー番号670、サイト優先度671、最終優先度672、トラフィック量673、保証帯域674の項目を持つ。フロー番号670は、Webリクエストと、その返答として送られるWebオブジェクトに関するデータフローに対して一意的に付される番号である。サイト優先度671は、LAN側プロキシサーバ110でWebリクエストに付加されるサイト優先度である。最終優先度672は、WAN側プロキシサーバ120内で、サイト優先度やその他の通信状況を参照して最終的に決定される最終優先度である。保証帯域674は、Webリクエストで要求された保証帯域である。
第11図に示されるIP優先度マップ表125は、最終優先度とIP層での優先制御パラメータの対応規則を示す表である。最終優先度680は、WAN側プロキシサーバ120内で決定されたフローの最終優先度であり、優先制御パラメタ681には、IPパケットの優先度を示すPrecedence値が入る。
第12図に示されるhttpリクエストヘッダは、優先度をWebリクエストへ付加するときに利用されるhttpリクエストヘッダの構造を示している。
装置間で優先度の伝達するために、RFCで規定されているhttp Ver1.1と言う規格が定められている。それと比較し、ヘッダ拡張項目として、個人優先度690、サイト優先度691、保証帯域692の項目が追加されていて、個人ポリシで定めた個人優先度、サイト優先度で定めたサイト優先度は、このエリアに書き込まれる。
第13図に示される本実施形態に係るIPパケットは、IP層で利用する優先制御パラメタの例がヘッダ部分に付加されている。具体的には、IP層でパケット単位の優先制御するために、IPヘッダ内のType of serviceのPrecedenceフィールド700に優先度情報を付加されている。
第14図に示されている通信記録表116は、WAN側プロキシサーバ120内での通信の記録データを格納する表である。通信記録表116は、利用時刻710、クライアントIPアドレス711、利用URL712、利用サイズ713、優先度714、使用帯域715の項目を持っていて、それぞれの通信があるたびに記録され、プロバイダが利用者に課金するときに使われる。
(IV)システムの通信動作の詳細
次に、第2図、第3図ないし第4図、第15図ないし第23図を用いて本発明の第一の実施形態に係るWeb情報優先転送システムの通信動作の詳細について説明する。
第3図は、本発明の第一の実施形態に係るWeb情報優先転送システムの通信シーケンス図である。
第4図は、本発明の第一の実施形態に係るWeb情報優先転送システムの通信の流れの概略を示す図である。
第15図は、ログイン画面を示す模式図である。
第16図は、個人ポリシ設定画面を示す模式図である。
第17図は、個人ポリシ設定の手順を示すフローチャートである。
第18図は、ソフトウェアプロキシ140がWebリクエストの受け付けるときの手順を示すフローチャートである。
第19図は、LAN側プロキシサーバ110がWebリクエストを受け付けるときの手順を示すフローチャートである。
第20図は、Webリクエストの転送先を決定する手順を示すフローチャートである。
第21図は、WAN側プロキシサーバ120がWebリクエストを受け付けるときの手順を示すフローチャートである。
第22図は、トラフィック制御をする手順を示すフローチャートである。
第23図は、優先制御パラメタを設定する手順を示すフローチャートである。
なお、本発明のWeb情報優先転送システムの通信の流れの大要は、第4図に示す通りなので、この図を押さえて各処理の流れを見ていけば理解しやすい。
(IV−1)ユーザ登録
先ず、利用者104が、優先制御付きでWebサービスを利用したい場合には、最初にサイト101内にある個人情報管理表106に、ユーザID、パスワードを利用者情報として登録する。個人情報管理表106には、第6図に示したように格納される。
(IV−2)個人ポリシの設定と個人ポリシの登録
次に、利用者104は、優先的に利用したいWebサービスのURLと優先度を個人ポリシとして、第6図の個人ポリシ設定画面530を用いて、ソフトウェアプロキシ140に登録する。
第6図に示されるように個人ポリシ設定画面530には、個人優先度を指定する優先ボタン531、通常ボタン532、低優先ボタン533がある。また、全リクエストボタン535、最前列ブラウザボタン536、指定URLボタン537と、URLを指定するためのURL入力欄534、URL追加ボタン538、URL削除ボタン539によって、対象とするWebリクエストを指定することができる。
優先度の指定の仕方は、先ず、対象とするWebリクエストを指定し、その後に望みの優先度のボタンをクリックすることになる。
Webリクエストは、実際には、以下の三種類の方法で指定することができる。
一つ目は、全リクエストボタン535の選択して、以後のWebリクエストすべての優先度を設定する方法である。
二つ目は、アクティブブラウザボタン536の選択して、ウィンドウがアクティブになっているのブラウザが表示しているWebサービスを指定する方法である。
これは、マルチウィンドウを持つOSでは、ブラウザを複数立ち上げる場合がある。そのとき、最前列にあってアクティブになっているブラウザの表示しているURLに対して優先度を設定しようとするものである。
三つ目は、指定URLボタン537の選択で、特定のURLに対して優先度を設定する方法である。優先したいURLの登録は、URL入力欄534にURLを入力後、URL追加ボタン538を押し登録できる。URLの登録を抹消する場合には、URL入力欄534にURLを入力後、URL削除ボタン539を押すことで登録を抹消できる。
上記の方法で対象とするWebサービスのURLを指定した後、個人優先度を指定する。個人優先度は、優先ボタン531、通常ボタン532、低優先ボタン533により、それぞれ優先、通常、低優先に設定できる。個人優先度は、優先、通常、低優先の順に高くなっていて、優先度が高い場合には、優先度の低いWebリクエストのトラフィックよりも、レスポンスが低下されないことが保証されている。
上記の入力作業がおこなわれると、ソフトウェアプロキシ140の個人ポリシ設定手段143は、第17図のフロチャートに基づき個人ポリシ管理表144に登録する。
先ず、URL、優先度が上記の方法で、利用者から入力される(S540)。
次に、ブラウザが表示しているURLの優先度を変更するか否かを判定し(S541)、必要なら場合には、指定方法がブラウザが表示しているページのURLを取得して(S542)、入力された個人ポリシを個人ポリシ管理表に登録する。個人ポリシ管理表144には、第5図のようなフォーマットで格納される。
(IV−3)ログイン
利用者104がWebサービスを利用する場合には、ログインによりユーザ認証を受けることが必要である。
実際に、利用者がWebサービスを要求すると、Webサーバ130へのWebリクエストは、個人ポリシ決定手段141を経由して、LAN側プロキシサーバ110に送られる。この際、Webリクエストに、利用者を認証するcookieが付加されていない場合には、LAN側プロキシサーバ110は、利用者104にログイン画面を返送し、ログイン処理を要求する。
ユーザ認証に利用するログイン画面は、第6図に示されるような画面であり、Webページとして利用者104に提供され、利用者104はブラウザ150によりアクセスすることができる。ログイン画面520には、ユーザID入力欄521とパスワード入力欄522があり、ここに利用者104は、自分のユーザIDとパスワードを入力する。ブラウザ150は、入力されたユーザIDとパスワードをログイン要求としてLAN側プロキシサーバ110に送信する(第3図のSQ501)。
上記のログイン処理を終了した利用者104は、個人優先度付きでWebサービスを利用できることになる。
(IV−4)ソフトウェアプロキシ140のWebリクエストの受付け
次に、第18図のフローチャートを追いながらソフトウェアプロキシ140のWebリクエストの受け付けるときの手順を説明する。
ブラウザ150からのWebリクエストは、ソフトウェアプロキシ140へ送られる(第3図のSQ503)。
ブラウザ150からのWebリクエストを受信し(S550)、次に、読み出すべき個人ポリシが、存在するか否かを判定する(S551)。
個人ポリシがある場合は、第5図に示される個人ポリシ管理表144から個人ポリシを一つ読み出して(S552)、読み出した個人ポリシのレコードと受信したWebリクエストの条件が一致するか否かを判定する(S553)。これを読み出すべき個人ポリシがなくなるまで繰り返す。
具体的には、先ず、個人ポリシ管理表144のURL620と、WebリクエストのURLが一致するか判定する。この際、指定範囲属性622が下位ディレクトリの場合には、URL620以下のディレクトリも一致するとし、「サイト内」と記述されたいる場合には、同一サイトも一致とする。次に、WebリクエストのWebオブジェクトの種類と、対象オブジェクト種別621を比較する。
このように判定していき受信したWebリクエストの条件が、個人ポリシと一致した場合には、個人ポリシに登録されている個人優先度623をWebリクエストに付加する(S554)。具体的には、第12図に示すhttpリクエストヘッダの個人優先度690の項目に個人ポリシ管理表144の個人優先度623の値を書き込む。そして、最後に、Webリクエストを送信する(S555)。
なお、本実施形態では、個人ポリシを、個人ポリシ管理表144の−レコードとして表現したが他の方法で表現しても良い。
(IV−5)LAN側プロキシサーバ110のWebリクエストの受付け
次に、第9図のフローチャートを追いながらLAN側プロキシサーバ110のWebリクエストの受付けるときの処理について説明する。
Webリクエストは、ソフトウェアプロキシ140からLAN側プロキシサーバ110に送信されてくる(第3図のSQ505)。
先ず、LAN側プロキシサーバ110は、Webリクエストを受信し(S560)、ログイン要求かを判定する(S561)。
ログイン要求の場合には、個人情報管理表106を用いて、第3図のSQ501により送信されてくるユーザIDとパスワードを比較して、有効か否かを判定する。
有効の場合には、cookie発行フェーズ562でcookieを発行する(S562、第3図のSQ502)。
ログイン要求でない場合には、Webリクエストのhttpヘッダに有効なcookieが含まれるかを判定する(S563)。
cookieを含まない場合には、ログイン画面を利用者に送信して(S564)、利用者104にログインを促す。なお、cookieを発行後、一定時間リクエストがない場合には、利用を終了したと判断し、そのcookieを破棄することにする。ここでは、個人認証については、ユーザID、パスワードとcookieの併用する方式を取ったが、他の方式、例えば、特定の暗号アルゴリズムを用いる方法、指紋などによる方法などを利用しても良い。
Webリクエストのhttpヘッダに有効なcookieが含まれていて、個人の認証ができるときには、次に、個人認証チェックの後、認証された利用者104の利用量を第8図に示される利用統計管理表115から得る(S565)。
次に、読み出すべきサイトポリシの存在の有無を判定し(S566)、サイトポリシがある場合には、第7図に示されるサイトポリシ管理表114からサイトポリシを一つ読み出す(S567)。
続いて、受信したWebリクエストの条件と読み出したサイトポリシが一致するか否かを判定する(S568)。そして、この処理を全てのサイトポリシがなくなるまで繰り返す。
具体的には、WebリクエストのURL、Webオブジェクトの種類を第18図のS553と同様の方法で比較する。次に、Webリクエストの利用者と個人優先度を、それぞれ、ユーザID643、個人優先度644と比較する。次に、利用者の利用量が、利用量645に記録された条件と一致するか判定する。例えば、ある利用者の利用量が、全体の利用量の平均を越えた場合にはサイト優先度を下げるなどのポリシを設定することができる。
なお、本実施形態では、サイトポリシを、サイトポリシ管理表114の−レコードとして表現したが他の方法で表現しても良い。
受信したWebリクエストの条件が、サイトポリシに一致した場合には、サイトポリシ管理表114に登録されているサイト優先度647をWebリクエストに付加する(S647)。具体的には、第12図に示すhttpリクエストヘッダのサイト優先度691の項目にサイトポリシ管理表114のサイト優先度647の値を書き込む。
そして、次の(IV−6)のフェーズで転送先を決めた後に、Webリクエストを外部のインターネット網に送信する(S570、第3図のSQ505)。
(IV−6)Webリクエストの転送先の決定
次に、第20図のフローチャートを追いながらLAN側プロキシサーバ110で、Webリクエストの転送先を決定する手順について説明する。
サイト優先度が決定されたWebリクエストは、LAN側プロキシサーバ110の転送先切替え手段112に送られてくる(S580)。
ここで受け付けられたWebリクエストは、サイト優先度の有無が判定され(S581)、サイト優先度が付加されている場合には、予め設定した適当なWAN側プロキシサーバ120に送信される(S582)。例えば、WAN側プロキシサーバが複数用意されている場合には、Webリクエストで要求されたURLから適当なWAN側プロキシサーバを選択する。
サイト優先度が付加されていない場合には、WAN側プロキシサーバ120には送られず、本発明の優先制御はおこなわれない。
(IV−7)WAN側プロキシサーバ120のWebリクエストの受付け
上記のようにサイト優先度が付加されたWebリクエストは、WAN側プロキシサーバ120に送信される。
次に、第21図のフローチャートを追いながら、WAN側プロキシサーバ120のWebリクエストの受け付けるときの手順について説明する。
WAN側プロキシサーバ120に送信されたWebリクエストは、中継処理手段121を経由し、要求解析手段122に送信される。
最初に、要求解析手段122でWebリクエストを受付け(S590)、Webリクエストの中のhttpヘッダにサイト優先度が定義されているか否かを判定し(S591)、付加されていれば、トラフィック制御手段123に通知する(S592)。
その後、Webリクエストで要求されている要求先のWebサーバ130に、Webリクエストを送信する(S593、第3図のSQ506)。
(IV−8)WAN側プロキシサーバ120のトラフィック制御
WAN側プロキシサーバ120から、Webサーバ130にWebリクエストが送信され、その返答としてWebオブジェクトを、WAN側プロキシサーバ120のトラフィック制御手段123が受信する(第3図のSQ507)。
以下では、第22図のフローチャートを追いながらWAN側プロキシサーバ120でのWebオブジェクトに対するトラフィック制御の手順について説明する。
先ず、トラフィック制御手段123は、Webサーバ130からのWebオブジェクトを受信する(S600)。
そして、受信したパケットのトラフィック量を測定して、現在のWAN側プロキシサーバを通過するトラフィック量を、優先度ごとに、第9図に示したトラフィック量管理表126のトラフィック量661に記録する。
同様に、第14図に示した通信記録表127に対して、Webリクエストを受信した時刻、要求されたURL、Webオブジェクトのサイズ、優先度、受信に使用した帯域を、それぞれ利用時刻683、利用URL684、サイズ685、優先度686、利用帯域687に記録する。
次に、(IV−7)のフェーズで優先度があった場合には、要求解析手段122からそれが通知されているので、その優先度が通知されたか否かを判定する(S602)。
優先すべきトラフィックの場合には、トラフィック量管理表126から、WAN側プロキシサーバ120を通過する優先度別のトラフィック量と割当て可能なトラフィック量を取得する。続いて、受信したWebオブジェクトのトラフィック量が、割当て可能なトラフィック量を越えるかを判定し(S603)、越える場合には、優先度を一つ下げ(S604)、最終優先度とする(S605)。
もし、トラフィック量が、割当て可能なトラフィック量を越えない場合には、指定されたサイト優先度を最終優先度とする(S605)。
その後、Webオブジェクトに最終優先度を付加して、IP優先度設定手段124へ送る(S606)。なお、トラフィック制御手段123は、第10図に示したフロー管理表128によりトラフィックを管理している。
(IV−9)優先制御パラメタを設定
前の(IV−8)のフェーズでは、最終優先度が決定されたが、この最終優先度は、トラフィック制御手段がアプリケーション層で決定したものである。これをIP層で認識する優先制御パラメタに変更して、パケットのレベルで優先制御をさせようにするというのが本発明の考え方である。
以下、この手順を第23図のフローチャートを追いながら説明する。
最初に、IP優先度設定手段124は、トラフィック制御手段123からWebオブジェクトを受取る(S610)。
次に、そのWebオブジェクトに最終優先度が付加されているかをで判定する(S611)。そして、最終優先度が付加されている場合には、第11図に示されたIP優先度マップ表125から、その最終優先度に対応するIP層での優先制御パラメタとしてPrecedenceの値を得る(S612)。次に、第13図に示した送信するIPパケットのType of serviceのPrecedenceフィールド700に、最終優先度から変換したPrecedenceの値を付加し(S613)、IPパケットをインターネット網に送信する(S614)。
(IV−10)その後のパケットの流れ
第4図に示されるように、優先制御パラメタを設定されたIPパケットは、ルータに送られて、インターネット網に中継される。WAN側プロキシサーバ120とLAN側プロキシサーバ110のインターネット網には、ルータ131bとルータ131aが接続されていて、それらのルータは、優先制御パラメータにより、IPパケットを優先処理して制御する機能を有している。
WAN側プロキシサーバ120から送信されたWebオブジェクトは、LAN側プロキシサーバ110の中継処理手段113が受信する。中継処理手段113では、受信したWebオブジェクトのトラフィック量を、利用統計管理表115と通信記録表116に記録し、利用者計算機103に送信する(第3図の508)。
LAN側プロキシサーバ110から送信されたWebオブジェクトは、利用者計算機103のソフトウェアプロキシ140の中継処理手段142に送られる(第3図の509)。中継処理手段142は、トラフィックの要求時刻、利用者計算機のIPアドレス、要求URL、Webオブジェクトのサイズ、個人優先度、使用した帯域を通信記録表116に記録する。そして、中継処理手段142は、ブラウザ150に送信し(第3図の509)、最終的に利用者104に提供される。
(V)その他の通信制御方法
これまでの例では、IPバケットのType of serviceのPrecedenceを利用し、その優先制御パラメタを解釈できるようなルータによりパケットの優先制御をおこなうようにした。
この優先制御の外に他の優先制御方法を利用しても良い。また、WAN側プロキシサーバ120が、優先制御をしつつ配送する方法も考えられる。例えば、WAN側プロキシサーバ120が、優先度ごとにパケットをバッファリングして配送する方法が考えられる。
(VI)本発明のシステムの通信の特徴
上記のように、本発明は、アプリケーションで設定される通信の優先度を、IP層のパケットの各Precedenceの値に変換するものである。本発明では、第9図に示されるように、優先度ごとにマップ可能なトラフィック量を持っている。したがって、優先度を各Precedenceの値に変換すると、結果として、IP層の各Precedenceの値ごとのパケットのトラフィック量が規定されることになり、そのトラフィック量を越えないよう優先度を制御することで、ルータ等のIP層での中継装置において、優先度が高いパケットキューが溢れず、IP層でのパケット通信が支障なく動作することが期待できる。
また、帯域保証要求のWebリクエストに対しては、最優先のPrecedenceを帯域保証専用として割当て、マップ可能なトラフィック量を設定し、サイトポリシでそのトラフィック量だけ帯域保証要求付きのWebリクエストを受付けることで実現できる。このとき、マップ可能なトラフィック量を越える帯域保証要求のWebリクエストがあるときには、最終優先度を下げることにより対応することになる。
さらに、上記実施形態では取り上げなかったが利用者がWebリクエスト以外の通信をおこなう場合もある。そのような場合のhttp以外のアプリケーション(例えば、FTP、メールなど)のトラフィックの制御は、利用する各中継装置の優先制御機能を利用し、例えば、TCPのポートなどを利用して、アプリケーションごとに帯域の設定をおこなう。
このように、第一の実施形態では、利用者やサイト管理者の優先制御ポリシに従い、利用者ごとの利用量や利用するWebページなどのアプリケーション層の情報を利用して、IP層でパケット単位での優先制御や帯域保証ができる。
さらに、WAN側プロキシサーバ120を利用して、優先制御や帯域制御に対応していないWebサーバ130からのWebオブジェクトに対しても、WAN側プロキシサーバ120が利用者から要求されたポリシでトラフィック制御し、Webオブジェクトに対して優先制御や帯域保証をおこなうことができる。
すなわち、WAN側プロキシサーバ120は、本発明を実施するために、優先度を見て、それを優先制御パラメタに変換する機構をもっているが、Webオブジェクトを提供するWebサーバ130は、これまでのWebサーバとなんら変わることなく、通信のインターフェースも全く変わることがなく、Webサービスが提供できると言うことである。
(VII)本システムにより期待されるサービス
次に、第24図を用いて本発明の第一の実施形態に係るWeb情報優先転送システムにより期待されるサービスについて説明する。
第24図は、プロバイダ102が、利用者104に対して発行する請求書の一例を示す模式図である。
請求書720は、利用明細表721、請求内訳表722、請求額723の欄からなっている。
利用明細表721は、利用時刻724、利用URL725、サイズ726、優先度727、使用帯域728の項目を持ち、請求内訳表722は、優先度729、利用量730、利用帯域731、小計732を持っている。
すなわち、利用明細表721は、利用者が過去にどれだけサービスを提供されたかの記録であり、請求内訳表722は、それに基づいて料金を計算する根拠を示している。
さて、プロバイダが、サイトや利用者に対して提供できるサービスを第23図によりサービスの内容を参照しつつ示すと以下の如くである。
一つ目は利用者が、動的に品質や価格を選択して利用できるWebサービスである。このサービスにより、利用者は、レスポンス時間が重要でない配信サービスは、利用できる帯域が少ないが、低価格に設定されたサービスとして利用できる。逆に、レスポンス時間が重要な場合には、価格が高くても他の利用者より優先してWebサービスを利用すれば良い。
具体的には、プロバイダは、例えば、第24図の請求書720のように、利用者が要求した優先度ごとに追加や割引して課金する形態の契約を結べるようにする。請求書720では、利用明細表721に、利用した時刻、利用したWebサービスのURL、受信したWebオブジェクトのサイズ、利用者が要求した優先度、要求に基づいてプロバイダが提供した帯域が、それぞれ利用時刻724、利用URL725、サイズ726、優先度727、利用帯域728に記載される。そして、利用明細722から、優先度ごとに、受信したWebオブジェクトのサイズの合計、提供した帯域の平均から課金額を算出し、それぞれ優先度729、利用量739、利用帯域731、小計732に記載し、請求内訳722を作成する。請求内訳表722の優先度ごとの課金額の小計732の合計を、最終的な課金額として請求額723に印刷する。
このように通信の優先度、すなわち、通信の質に応じたサービスをプロバイダが提供することができ、利用者の立場からすると、自分の受けたいサービスの内容にそった合理的な価格でサービスを受けることができる。
二つ目は、利用者が重要とするトラフィックの、契約した帯域に占める量をサイト管理者に通知するサービスである。このサービスにより、サイト管理者は、利用者が重要とするトラフィック量を把握することができるので、より利用者の要求に応じたネットワーク回線の増設計画を立案できる。
三つ目は、トラフィック量の急増からの、既存のWebサービスの保護である。このサービスにより、新規にWebアプリケーションを導入する場合など、Webアプリケーションのトラフィック量が急増する場合に、WebアプリケーションをURLやWebオブジェクトの種類等で識別し、利用する帯域を設定することで、既存のWebサービスの品質を保護することができる。また逆に、特定の帯域を必要とするWebアプリケーションを、既存のWebサービスのトラフィックから保護し導入できる。
四つ目は、Webサービスの種類ごとのバランス制御である。このサービスにより、Webを利用したストリーム配信や、配信サービスなどを、特定のURLやWebオブジェクトの種別によって識別することで、サイト管理者がサイト全体でWebサービスの種類ごとに利用量のバランスを制御でき、段階的な導入や、過剰な利用の制限ができる。
五つ目は、サイト内の利用者に対する、利用量に基づいた均一なWebサービスである。従来、Webリクエストは、その利用量に依存せず平等に処理されてきた。したがって、Webサービスの質をレスポンス時間とすると、多くリクエストした利用者が、他の利用者と同質のサービスを多く利用できる上、ネットワーク回線を圧迫するので、全体的なサービスの質を低下させる。
そこで、本発明では、Webサービスの質を、利用量とWebのレスポンス時間の二面から捉えている。これにより、利用したWebトラフィック量に応じ、利用量が多い利用者よりも、利用量が少ない利用者のWebリクエストを優先することができるので、利用者全員が、利用量に基づいた均一な質のWebサービスを利用できる。さらに、利用者にトラフィック量を意識させることで、必要性が低いWebの利用を自粛することが期待できる。
六つ目は、契約した帯域の空き帯域を利用するサービスである。Webのレスポンスの向上のために先読み技術がある。しかし、この技術はトラフィック量が一般的なWebサービスよりも多く、ネットワーク回線を圧迫しWebサービスのレスポンスを低下させるので、Webサービス中は同一のネットワーク回線を利用にくかった。そこで、このサービスにより、Webサービス中でも、先読み技術を優先度を下げることで、Webサービスのレスポンスを低下させることなく利用できる。また、Web情報のミラーリングや、Webの情報検索サービスなども、同様の問題を持つので、本サービスの適応が期待できる。
〔実施形態2〕
以下、第25図ないし第26図を用いて本発明に係る第二の実施形態を説明する。
第25図は、本発明の第二の実施形態に係るWeb情報優先転送システムのシステム概要を説明するための図である。
第26図は、本発明の第二の実施形態に係るWeb情報優先転送システムのシステム構成図である。
本実施形態のWeb情報優先転送システムの通信モデルでは、第25図に示されているように利用者104が個人優先度を設定せず、サイト管理者105がサイト優先度のみを設定する。その他の機能や各機能の動作は、第一の実施形態と同様である。
構成的には、第26図に示されているように利用者計算機103の中にソフトウェアプロキシを中継せず、ブラウザ150がLAN側プロキシサーバ110に直接アクセスするようになる。
この第二の実施形態の構成によれば、利用者が優先度を指定できないが、利用者計算機103にソフトウェアプロキシ140をインストールせずに済み、LAN側プロキシサーバ110だけでサービスできるので、導入や管理の手間を削減することができる。
〔実施形態3〕
以下、第27図ないし第28図を用いて本発明に係る第三の実施形態を説明する。
第27図は、本発明の第三の実施形態に係るWeb情報優先転送システムのシステム概要を説明するための図である。
第28図は、本発明の第三の実施形態に係るWeb情報優先転送システムのシステム構成図である。
本実施形態のWeb情報優先転送システムの通信モデルでは、第27図に示されているようにサイト優先度は設定されず、利用者104が個人優先度のみを設定して、WAN側プロキシサーバ120にWebリクエストを送る。その他の機能や各機能の動作は、第一の実施形態と同様である。
構成的には、第28図に示されているようにサイト優先度を設定していたLAN側プロキシサーバ110が必要なくなり、利用者計算機103が直接、インタネット網のWAN側プロキシサーバ120にアクセスするようになる。
このように、第三の実施形態では、プロバイダ102がサイト101ではなく、直接利用者104に対して、利用者の優先度に基づき優先制御や帯域確保のサービスを提供できる。本実施形態では、サイトと言う概念は存在せず、個人や家庭でインターネットを利用する者向けの通信モデルであると言うことができる。
産業上の利用可能性
以上のように本発明のWeb情報優先転送システムは、既存のインターネット網で、プロバイダを介してWebサーバからWeb情報の提供を受けるときに、利用負担に応じたサービスを受けるのに好適な通信システムを提供できる。
【図面の簡単な説明】
第1図は、本発明の第一の実施形態に係るWeb情報優先転送システムのシステム概要を説明するための図である。
第2図は、本発明の第一の実施形態に係るWeb情報優先転送システムのシステム構成図である。
第3図は、本発明の第一の実施形態に係るWeb情報優先転送システムの通信シーケンス図である。
第4図は、本発明の第一の実施形態に係るWeb情報優先転送システムの通信の流れの概略を示す図である。
第5図は、個人ポリシ管理表144の例を示す模式図である。
第6図は、個人情報管理表106の例を示す模式図である。
第7図は、サイトポリシ管理表114の例を示す模式図である。
第8図は、利用統計管理表115の例を示す模式図である。
第9図は、トラフィック量管理表126の例を示す模式図である。
第10図は、フロー管理表128の例を示す模式図である。
第11図は、IP優先度マップ表125の例を示す模式図である。
第12図は、優先度をWebリクエストへ付加するときに利用するhttpリクエストヘッダの構造の例を示す模式図である。
第13図は、本実施形態に係るIPパケットの例を示す模式図である。
第14図は、通信記録表116の例を示す模式図である。
第15図は、ログイン画面を示す模式図である。
第16図は、個人ポリシ設定画面を示す模式図である。
第17図は、個人ポリシ設定の手順を示すフローチャートである。
第18図は、ソフトウェアプロキシ140がWebリクエストの受け付けるときの手順を示すフローチャートである。
第19図は、LAN側プロキシサーバ110がWebリクエストを受け付けるときの手順を示すフローチャートである。
第20図は、Webリクエストの転送先を決定する手順を示すフローチャートである。
第21図は、WAN側プロキシサーバ120がWebリクエストを受け付けるときの手順を示すフローチャートである。
第22図は、トラフィック制御をする手順を示すフローチャートである。
第23図は、優先制御パラメタを設定する手順を示すフローチャートである。
第24図は、プロバイダ102が、利用者104に対して発行する請求書の一例を示す模式図である。
第25図は、本発明の第二の実施形態に係るWeb情報優先転送システムのシステム概要を説明するための図である。
第26図は、本発明の第二の実施形態に係るWeb情報優先転送システムのシステム構成図である。
第27図は、本発明の第三の実施形態に係るWeb情報優先転送システムのシステム概要を説明するための図である。
第28図は、本発明の第三の実施形態に係るWeb情報優先転送システムのシステム構成図である。
Claims (4)
- 利用者からWebリクエストを出して、プロバイダを介してWebサーバからWebオブジェクトを受信するWebサービスを利用するためのWeb情報優先転送システムにおいて、
このシステムは、
利用者のサイトにおけるLAN側プロキシサーバと、
前記プロバイダのサイトにおけるWAN側プロキシサーバとを有し、
前記LAN側プロキシサーバは、
Webリクエストを識別し、予め設定した条件によりサイト優先度を付加する手段と、
そのWebリクエストを、前記WAN側プロキシサーバに送信する手段とを備え、
前記WAN側プロキシサーバは、
Webリクエストに付加されたサイト優先度を取得する手段と、
取得したサイト優先度を、通信状況や設定に基づき最終優先度に変換する手段と、
前記WebリクエストをWebサーバに中継し、Webサーバからその返答として送られてくるWebオブジョクトを受信する手段とを備え、
前記WAN側プロキシサーバは、
前記Webリクエストから取得した優先度を最終優先度に変換し、また、それをIPパケットの優先制御パラメタに変換して、その返答となるWebオブジェクトのIPパケットに前記優先制御パラメタを付加して前記LAN側プロキシサーバに中継するか、
または、前記Webリクエストから取得した優先度を最終優先度に変換し、また、その最終優先度に基づいて、その返答となるWebオブジェクトのIPパケットの優先制御をおこなうことを特徴とするWeb情報優先転送システム。 - さらに、このシステムは、
前記利用者のサイトに、利用者が利用する利用者計算機を有し、
その利用者計算機は、Webリクエストごとに個人優先度を設定できる手段を備え、
前記LAN側プロキシサーバは、
さらに、利用者ごとのWebサービスの通信記録を集計する手段を備え、
前記LAN側プロキシサーバにより設定されるサイト優先度は、
前記予め設定した条件に加えて、前記個人優先度と、前記利用者ごとのWebサービスの通信記録とに基づいて設定されることを特徴とする請求項1記載のWeb情報優先転送システム。 - 前記Webサーバから受信するWebオブジェクトのトラフィック量、または、前記LAN側プロキシサーバと前記WAN側プロキシサーバの通信状況に応じて、
前記最終優先度からIPパケットの優先制御パラメタへの変換を、動的におこなうことを特徴とする請求項1記載のWeb情報優先転送システム。 - 前記WAN側プロキシサーバは、
さらに、利用者ごとのWebサービスの通信記録を集計する手段を備え、
利用者の利用した通信内容と、利用者の要求した優先度に基づき、利用者ごとに課金する手段を有することを特徴とする請求項1記載のWeb情報優先転送システム。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2000/004848 WO2002007395A1 (fr) | 2000-07-19 | 2000-07-19 | Systeme de transfert preferentiel d'informations sur le web |
Publications (1)
Publication Number | Publication Date |
---|---|
JP3857228B2 true JP3857228B2 (ja) | 2006-12-13 |
Family
ID=11736275
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002513169A Expired - Fee Related JP3857228B2 (ja) | 2000-07-19 | 2000-07-19 | Web情報優先転送システム |
Country Status (3)
Country | Link |
---|---|
US (1) | US7401118B1 (ja) |
JP (1) | JP3857228B2 (ja) |
WO (1) | WO2002007395A1 (ja) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19952527C2 (de) * | 1999-10-30 | 2002-01-17 | Ibrixx Ag Fuer Etransaction Ma | Verfahren und Transaktionsinterface zum gesicherten Datenaustausch zwischen unterscheidbaren Netzen |
JP2003283545A (ja) * | 2002-03-22 | 2003-10-03 | Toshiba Corp | 通信システム及び通信システムのコネクション制御方法 |
JP3828444B2 (ja) * | 2002-03-26 | 2006-10-04 | 株式会社日立製作所 | データ通信中継装置及びシステム |
EP1650931B1 (en) * | 2002-04-05 | 2008-11-05 | Telefonaktiebolaget LM Ericsson (publ) | Object transfer priorities in a communications network |
US20050071494A1 (en) * | 2003-09-30 | 2005-03-31 | Rundquist William A. | Method and apparatus for providing fixed bandwidth communications over a local area network |
US7788369B2 (en) * | 2003-12-01 | 2010-08-31 | Carefusion 303, Inc. | System and method for network discovery and connection management |
JP3925542B2 (ja) * | 2005-04-28 | 2007-06-06 | 日本電気株式会社 | ネットワークシステム、キャッシュサーバ、キャッシュサーバの制御方法、プログラムを記録した記録媒体 |
JP3931910B2 (ja) * | 2005-04-28 | 2007-06-20 | 日本電気株式会社 | ネットワークシステム、キャッシュサーバ、キャッシュサーバ制御方法及び記録媒体 |
JP4679453B2 (ja) * | 2006-07-12 | 2011-04-27 | Kddi株式会社 | Lanに接続された情報機器を、wanを介して制御するためのゲートウェイ及びプログラム |
JP4758362B2 (ja) * | 2007-01-30 | 2011-08-24 | 株式会社日立製作所 | 中継装置、プログラム及び中継方法 |
US8885634B2 (en) * | 2007-11-30 | 2014-11-11 | Ciena Corporation | Systems and methods for carrier ethernet using referential tables for forwarding decisions |
US20090316707A1 (en) * | 2008-06-18 | 2009-12-24 | Telect, Inc. | Services Switch Form Factor |
US9083772B2 (en) * | 2010-04-30 | 2015-07-14 | Qualcomm Incorporated | Exchanging data associated with a communication session within a communications system |
US9442687B2 (en) * | 2012-07-23 | 2016-09-13 | Korea Advanced Institute Of Science And Technology | Method and apparatus for moving web object based on intent |
WO2015037684A1 (ja) | 2013-09-11 | 2015-03-19 | フリービット株式会社 | アプリケーション状態変化通知プログラム及びその方法 |
WO2015122194A1 (ja) * | 2014-02-14 | 2015-08-20 | Necソリューションイノベータ株式会社 | リアルタイム通信システム、リアルタイム通信装置、リアルタイム通信方法および記録媒体 |
US10015283B2 (en) * | 2015-07-29 | 2018-07-03 | Netapp Inc. | Remote procedure call management |
DE102016204195A1 (de) * | 2016-03-15 | 2017-09-21 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zum Datenaustausch |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6968379B2 (en) * | 1997-05-30 | 2005-11-22 | Sun Microsystems, Inc. | Latency-reducing bandwidth-prioritization for network servers and clients |
JPH11275141A (ja) * | 1998-03-19 | 1999-10-08 | Ntt Data Corp | 通信品質制御装置、ネットワークシステム、通信品質制御方法及び記録媒体 |
JP3292138B2 (ja) * | 1998-05-25 | 2002-06-17 | 日本電気株式会社 | データ伝送装置およびデータ伝送方法 |
JP3225924B2 (ja) * | 1998-07-09 | 2001-11-05 | 日本電気株式会社 | 通信品質制御装置 |
US6314465B1 (en) * | 1999-03-11 | 2001-11-06 | Lucent Technologies Inc. | Method and apparatus for load sharing on a wide area network |
US6701316B1 (en) * | 2000-04-07 | 2004-03-02 | Nec Corporation | Method and apparatus for intelligent network bandwidth and system resource utilization for web content fetch and refresh |
-
2000
- 2000-07-19 JP JP2002513169A patent/JP3857228B2/ja not_active Expired - Fee Related
- 2000-07-19 WO PCT/JP2000/004848 patent/WO2002007395A1/ja active Application Filing
- 2000-07-19 US US10/276,981 patent/US7401118B1/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US7401118B1 (en) | 2008-07-15 |
WO2002007395A1 (fr) | 2002-01-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3857228B2 (ja) | Web情報優先転送システム | |
US10305859B2 (en) | Applying security policy to an application session | |
US9954899B2 (en) | Applying a network traffic policy to an application session | |
US9954868B2 (en) | System and method to associate a private user identity with a public user identity | |
US7120662B2 (en) | Conductor gateway prioritization parameters | |
CN109309907A (zh) | 用于流量计费的方法、装置及其相关设备 | |
US7526528B2 (en) | Network access arrangement | |
JP2002278858A (ja) | 課金方法およびサーバ | |
JP2003087433A (ja) | インターネット接続方法及びシステム、並びにコンピュータプログラム | |
JP2002108814A (ja) | 不特定多数のユーザがアクセスするシステム | |
KR100726418B1 (ko) | 로그인없는 하이퍼 텍스트 전달 프로토콜 서비스 방법 | |
JP2003283545A (ja) | 通信システム及び通信システムのコネクション制御方法 | |
JP2010273255A (ja) | ネットワークシステム | |
Class | THE INTERNET PROTOCOL 427 | |
van der Waaij et al. | Internet Next Generation Management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050411 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060829 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060913 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090922 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100922 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100922 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110922 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120922 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120922 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130922 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |