(57)【要約】【課題】マルチドメイン構成のWebページをクライアントからのリクエストに応答して高速に配信できるWebコンテンツの配信装置を提供する。【解決手段】コンテンツ取得部１は、クライアントからリクエストされたWebページのhtmlファイルAおよび関連するサブコンテンツB，C，DをWebサーバから取得して記憶部２にキャッシュする。コンテンツ編集部３は、クライアントがWebページのhtmlファイルAおよび各コンテンツデータB，C，Dを同一ドメインから取得できるようにするために各コンテンツを編集する。コンテンツ配信部７において、メインコンテンツ配信部７０１は、記憶部２にキャッシュされているhtmlファイルAを読み出してクライアントへ配信する。Push判定部７０２は、クライアントがPush配信に対応できるか否かを判定する。サブコンテンツ配信部７０３は、クライアントがPush配信に対応していれば、各コンテンツデータB，C，DをクライアントへPush配信する。【選択図】図８
2014010622.tif 000002
【特許請求の範囲】
【請求項１】
所在するドメインの異なる複数のコンテンツへのリンクを含むマルチドメイン構成のWebページを予めキャッシュし、クライアントからの要求に応答して代替配信するWebコンテンツの配信装置において、
Webページに含まれる少なくとも一つのサブコンテンツのリンク先のドメインが記述されたメインコンテンツを取得するメインコンテンツ取得手段と、
前記リンク先の各ドメインにアクセスして各サブコンテンツを取得するサブコンテンツ取得手段と、
前記メインおよびサブの各コンテンツを対応付けてキャッシュする記憶手段と、
クライアントからリクエストされたWebページに関してキャッシュされているメインコンテンツおよび各サブコンテンツを配信する配信手段とを具備したことを特徴とするWebコンテンツの配信装置。
【請求項２】
前記メインコンテンツおよび各サブコンテンツを編集するコンテンツ編集手段を具備したことを特徴とする請求項１に記載のWebコンテンツの配信装置。
【請求項３】
前記コンテンツ編集手段は、メインコンテンツに記述されている各サブコンテンツへのリンク先のドメインを当該メインコンテンツと同一のドメインに書き替えることを特徴とする請求項２に記載のWebコンテンツの配信装置。
【請求項４】
前記コンテンツ編集手段は、ファイル名が重複するサブコンテンツのファイル名を、重複しない他のファイル名に書き替えることを特徴とする請求項２または３に記載のWebコンテンツの配信装置。
【請求項５】
クライアントから要求されたWebページに対応したメインおよびサブの各コンテンツが前記記憶手段にキャッシュされていないと、当該メインおよびサブの各コンテンツを各ドメインから取得して前記記憶手段にキャッシュした後、前記クライアントへ配信することを特徴とする請求項１ないし４のいずれかに記載のWebコンテンツの配信装置。
【請求項６】
前記メインコンテンツがhtmlファイルであり、前記各サブコンテンツが、当該htmlファイルのページに出力されるコンテンツデータであることを特徴とする請求項１ないし５のいずれかに記載のWebコンテンツの配信装置。
【請求項７】
前記クライアントとSPDYで通信し、前記サブコンテンツがサーバPushによりクライアントへ配信されることを特徴とする請求項１ないし６のいずれかに記載のWebコンテンツの配信装置。
【請求項８】
前記各サブコンテンツに優先度が設定され、前記サーバPushによる配信対象または配信順序が、当該優先度に応じて選択されることを特徴とする請求項７に記載のWebコンテンツの配信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Webコンテンツの配信装置に係り、特に、Webページを構成するコンテンツデータが、そのhtmlファイルと共に複数のWebサーバに分散して配置されているマルチドメイン構成のWebページの配信に好適な配信装置に関する。
【背景技術】
【０００２】
Webコンテンツの配信を高速化する技術が非特許文献１，２，３に開示されている。非特許文献１には、サーバがクライアントとのTCPコネクションを一定期間保持することで、一度確立されたTCPコネクション上で複数のWebコンテンツ配信を行う技術が開示されている。これにより、コンテンツデータ毎にTCPコネクションを確立・切断する必要が無くなるので、Webコンテンツ配信の高速化が実現される。
【０００３】
非特許文献２には、TCPコネクションの統合、サーバからのPush配信、リクエストの多重送信化、冗長なヘッダの削除、および通信データの圧縮を必須化することで、既存のHTTPにおけるWebコンテンツ配信速度を向上させるSPDYが開示されている。このとき、HTTPを操作するセッション層にSPDYを実装することで、既存のTCP、SSL、HTTPに手を加えることなく、Webコンテンツ配信の高速化が実現される。
【０００４】
非特許文献３には、エッジサーバと呼ばれるリバースプロキシをネットワーク上に設けて、Webコンテンツ等の配信に必要なコンテンツデータをキャッシュとして保持し、オリジナルのコンテンツデータを保持するサーバの代わりに、エッジサーバがクライアントと通信を行う技術が開示されている。これにより、オリジナルサーバ・クライアントで通信を行う場合に比べてRTTが短縮され、Webコンテンツ配信の高速化が実現される。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】R. Fielding, J. Gettys, J. Mogul,  H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,  " Hypertext Transfer Protocol -- HTTP/1.1", RFC2616, Jun 1999.
【非特許文献２】M. Belshe, R. Peon, "SPDY Protocol", InternetDraft mbelshe-spdy-00, Feb 2012.
【非特許文献３】Erik Nygren, Ramesh K. Sitaraman, Jennifer Sun, "The Akamai Network:A Platform for High-Performance Internet Applications", ACM SIGOPS Operating Systems Review, Vol. 44, No.3, Jul 2010.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
配信対象のWebページがマルチドメイン構成であって、そのhtmlファイルと少なくとも一つのコンテンツデータとが、ドメインの異なる複数のWebサーバに分散配置されていると、クライアントは、始めにWebサーバからhtmlファイルを取得する。このhtmlファイルには、Webページに出力される各コンテンツデータが分散配置されているWebサーバのドメインがリンク先として記述されている。クライアントは、このhtmlファイルの取得後、各ドメインへアクセスして各コンテンツデータを取得し、これらを結合することでWebページを再現する。したがって、クライアントはhtmlファイルの取得が完了しなければ、次の処理に進むことができない。
【０００７】
ここで、既存のTCPではドメインの異なる複数のWebサーバと同時に接続できるものの、同時に確立されるセッション数が制限されているので、Webページを構成するコンテンツデータ数が多い場合には、これらを同時に取得することができない。また、非特許文献１，３は、サーバが主導的にクライアントへコンテンツを配信する、いわゆるサーバPush配信に対応していないので、クライアントは全てのWebサーバに自らアクセスしてコンテンツ配信をリクエストしなければならなかった。
【０００８】
一方、非特許文献２のSPDYによれば、サーバとの間に同時に確立されるセッション数が制限されておらず、またクライアントがリクエストしたhtmlファイルと同一のWebサーバ上に蓄積されているコンテンツについてはサーバPush配信が可能である。
【０００９】
しかしながら、ドメインの異なる他のWebサーバに蓄積されているコンテンツについてはクライアントからのリクエストが必要となる。したがって、図９に模式的に示したように、配信対象がマルチドメイン構成のWebページであると、クライアントはWebサーバWS1に自らアクセスしてhtmlファイルを取得するのみならず、他のコンテンツデータについても、WebサーバWS1，WS2，WS3…にそれぞれ自らアクセスして取得しなければならなかった。
【００１０】
本発明の目的は、上記した従来技術の課題を解決し、マルチドメイン構成のWebページをクライアントからのリクエストに応答して高速に配信できるWebコンテンツの配信装置を提供することにある。
【課題を解決するための手段】
【００１１】
上記の目的を達成するために、本発明は、所在するドメインの異なる複数のコンテンツへのリンクを含むマルチドメイン構成のWebページを予めキャッシュし、クライアントからの要求に応答して代替配信するWebコンテンツの配信装置において、以下のような構成を具備した点に特徴がある。
【００１２】
(1)Webページに含まれる少なくとも一つのサブコンテンツのリンク先のドメインが記述されたメインコンテンツを取得するメインコンテンツ取得手段と、リンク先のドメインにアクセスして各サブコンテンツを取得するサブコンテンツ取得手段と、メインおよびサブの各コンテンツを対応付けてキャッシュする記憶手段と、クライアントからリクエストされたWebページに関してキャッシュされているメインコンテンツおよび各サブコンテンツを配信する配信手段とを具備した。
【００１３】
(2)メインコンテンツに記述されているサブコンテンツのリンク先ドメインや各サブコンテンツのファイル名を編集するコンテンツ編集手段を具備した。
【発明の効果】
【００１４】
(1)本発明によれば、マルチドメイン構成のWebページのhtmlファイルおよび関連するコンテンツデータが、複数のWebサーバから取得されてキャッシュサーバ上に予めキャッシュされ、同一ドメインで管理されているので、クライアントは、当該サーバにアクセスするだけで、htmlファイルのみならず、そのコンテンツデータもサーバPush配信により簡単に取得できるようになる。
【００１５】
(2)キャッシュされたメインコンテンツに記述されている各サブコンテンツのリンク先ドメインが当該メインコンテンツと同一のドメインに書き替えられ、さらにファイル名の重複するサブコンテンツのファイル名も重複しない他のファイル名に書き替えられるので、クライアントでは、配信されたhtmlファイルおよび関連するコンテンツデータに基づいて、マルチドメイン構成のWebページを簡単かつ確実に再現できるようになる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係るWebコンテンツ配信システムのネットワーク構成を示したブロック図である。
【図２】マルチドメイン構成のWebページの一例を示した図である。
【図３】本発明の一実施形態に係るコンテンツの配信方法を示した図である。
【図４】アクセラレションサーバによるWebページコンテンツのキャッシュ方法を示したフローチャートである。
【図５】アクセラレションサーバによるWebページの配信方法を示したフローチャートである。
【図６】アクセラレションサーバによるWebページの配信方法を示したシーケンスフローである。
【図７】アクセラレションサーバによるWebページの他の配信方法を示したシーケンスフローである。
【図８】アクセラレションサーバの機能ブロック図である。
【図９】SPDYによるWebページの配信方法を模式的に表現した図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の一実施形態に係るWebコンテンツ配信システムのネットワーク構成を示したブロック図であり、マルチドメイン構成のWebページについて、そのhtmlファイル（メインコンテンツ）やコンテンツデータ（サブコンテンツ）が分散配置された複数のWebサーバWSと、各WebサーバWSとクライアントとの間でプロキシサーバ（代替配信）機能を発揮するアクセラレションサーバASと、アクセラレションサーバASからhtmlファイルおよび各コンテンツデータを取得して所望のWebページを再現するクライアントとを主要な構成としている。前記各WebサーバWSには、それぞれ異なるドメインが割り当てられている。
【００１８】
本実施形態では、配信対象となるWebページが、図２に一例を示したように、htmlファイルAと当該htmlファイルAのページに出力される３つのコンテンツデータB，C，Dから構成されている。また、図３に示したように、本実施形態ではアクセラレションサーバASと各WebサーバWSとがHTTPコネクションやSPDYコネクション等の適宜のコネクションで接続され、クライアントとアクセラレションサーバASとは、サーバPush配信の可能なSPDYコネクションで接続される。
前記htmlファイルAおよびコンテンツデータBは、ドメインDN1のWebサーバWS1に保持され、コンテンツデータC，Dは、ドメインDN2のWebサーバWS2に保持されている。アクセラレションサーバASにはドメインDN3が割り当てられている。
【００１９】
ここでは始めに、アクセラレションサーバASが各WebサーバWSからWebページの各データをキャッシュする手順について説明し、次いで、クライアントがアクセラレションサーバASにアクセスして前記キャッシュされている各データを取得する手順について説明する。
【００２０】
図４は、前記アクセラレションサーバASが各WebサーバWSからWebページの各データをキャッシュする動作を示したフローチャートであり、ステップＳ１１では、WebサーバWS1のドメインDN1にアクセスしてコンテンツA（htmlファイルA）が取得される。ステップＳ１２では、前記htmlファイルに記述されている各コンテンツデータB，C，Dのリンク先ドメインに基づいて各コンテンツデータB，C，Dのドメインが判別される。ここでは、コンテンツデータBのドメインがDN1と判別され、コンテンツデータC，DのドメインがDN2と判別される。
【００２１】
ステップＳ１３では、各ドメインDN1，DN2にそれぞれアクセスすることでWebサーバWS1，WS2からコンテンツデータB，C，Dが取得される。ステップＳ１４では、必要に応じてhtmlファイルAおよび各コンテンツデータB，C，Dが編集される。
【００２２】
本実施形態では、htmlファイルAへのリクエストメッセージがDN1に送信された場合、htmlファイルAに記述されている各コンテンツデータB，C，Dのリンク先ドメインが、全てリクエストメッセージが送信されたドメインDN１に書き替えられる。また、各コンテンツデータB，C，Dのファイル名が重複している場合には、重複しないように異なるファイル名に書き替えられる。ステップＳ１５では、前記取得されたhtmlファイルAおよびコンテンツデータB，C，Dが相互に関連付けられてキャッシュされる。
【００２３】
図５は、アクセラレションサーバASがクライアントからの要求に応答してWebページを配信する動作を示したフローチャートであり、図６は、そのシーケンスフローである。
【００２４】
時刻t1において、クライアントからアクセラレションサーバASへWebページ（htmlファイルA）のリクエストメッセージが送信されると、アクセラレションサーバASでは、このリクエストメッセージがステップＳ３１で受信され、時刻t2において、そのレスポンスメッセージが応答される。ステップＳ３２では、前記要求されたhtmlファイルAがキャッシュ情報として保持されているか否かが判定される。保持されていればステップＳ３３へ進んで当該htmlファイルAが読み出され、時刻t3においてクライアントへ配信される。
【００２５】
ステップＳ３４では、前記htmlファイルAに関連するコンテンツデータが存在するか否かが判定され、ここでは３つのコンテンツデータB，C，Dが存在すると判定されるのでステップＳ３５へ進む。ステップＳ３５では、前記コンテンツデータB，C，DのサーバPush配信が可能であるか否かが判定される。本実施形態では、時刻t4において、アクセラレションサーバASからクライアントへ、３つのコンテンツデータB，C，Dに関する多重Pushedリクエストメッセージが送信される。これに対して、時刻t5のように、クライアントから多重Pushedレスポンスメッセージが応答されれば、サーバPush配信が可能であると判定されてステップＳ３６へ進む。
【００２６】
ステップＳ３６では、キャッシュされている３つのコンテンツデータB，C，Dが読み出され、時刻t6でクライアントへの配信が開始される。ステップＳ３７では、全てのコンテンツデータの配信が完了したか否かが判定され、完了するまではステップＳ３４へ戻って関連するコンテンツ配信が継続される。その後、全てのコンテンツデータの配信が完了すると当該処理を終了する。
【００２７】
一方、前記ステップＳ３２において、要求されたWebページがキャッシュされていないと判定されると、前記図４を参照して説明したキャッシュ処理が実行され、キャッシュされたhtmlファイルAおよび各コンテンツデータB，C，Dがクライアントへ配信される。
【００２８】
なお、上記の例では、アクセラレションサーバASからクライアントへ３つのコンテンツデータB，C，Dが同時に配信されるものとして説明したが、本発明はこれのみに限定されるものではなく、例えばWebサーバWS1に保持されていたコンテンツデータBの優先度や重要度が、WebサーバWS2に保持されていたコンテンツデータC，Dの優先度や重要度よりも高いことが既知ならば、図７に示したように、時刻t6でおいてクライアントへの配信が開始されると、始めにコンテンツデータBを優先的に配信し、次いで、残りのコンテンツデータC，Dを配信するといったように、各コンテンツデータを、その優先度に応じた順序で配信するようにしても良い。あるいは、ネットワークの輻輳状況等に応じて、輻輳時には優先度の高いコンテンツデータBのみを配信し、優先度の低いコンテンツデータC，Dは配信しないようにしても良い。
【００２９】
図８は、前記アクセラレションサーバASの機能ブロック図であり、ここでは本発明の説明に不要な構成は図示が省略されている。
【００３０】
コンテンツ取得部１において、メインコンテンツ取得部１０１は、WebページのhtmlファイルAをネットワーク上のWebサーバから取得する。当該Webサーバのドメインは別途に与えられる。ドメイン解析部１０２は、前記htmlファイルに記述されている各サブコンテンツB，C，Dのリンク先ドメインに基づいて当該各サブコンテンツのドメインを判別する。サブコンテンツ取得部１０３は、前記各ドメインにアクセスして各WebサーバからコンテンツデータB，C，Dを取得する。前記取得されたhtmlファイルAおよび各コンテンツデータB，C，Dは、前記Webページを構成するコンテンツ群として相互に関連付けられて記憶部２にキャッシュされる。
【００３１】
コンテンツ編集部３は、クライアントがWebページのhtmlファイルAおよび各コンテンツデータB，C，Dを同一ドメインから取得できるようにするために各コンテンツのリンク先を編集する。すなわち、ドメイン編集部３０１は、前記メインコンテンツ取得部１０１により取得されたhtmlファイルAにリンク先が記述されている各サブコンテンツに関して、そのリンク先のドメインに関する記述を、元のドメインから全てリクエストメッセージが送信されたドメインDN1に書き替える。
ファイル名編集部３０２は、前記サブコンテンツ取得部１０３により取得されたコンテンツデータB，C，Dのファイル名を参照し、ファイル名が重複するサブコンテンツのファイル名を、重複しない他のファイル名に書き替える。前記記憶部２には、リンク先のドメインやファイル名が編集済みのhtmlファイルAおよびコンテンツデータB，C，Dがキャッシュされる。
【００３２】
リクエスト受付部４は、クライアントからWebページの配信要求を受け付ける。リクエスト分析部５は、前記Webページの配信に必要なhtmlファイルAおよび各サブコンテンツB，C，Dを識別する。キャッシュ判定部６は、前記htmlファイルAおよび各サブコンテンツB，C，Dが前記記憶部２にキャッシュされているか否かを判定し、キャッシュされていない場合には、前記htmlファイルAおよび各サブコンテンツB，C，Dのキャッシュをコンテンツ取得部１に対して要求する。コンテンツ取得部１は、当該要求に応答して前記キャッシュ処理を実行する。
【００３３】
コンテンツ配信部７において、メインコンテンツ配信部７０１は、前記記憶部２にキャッシュされているhtmlファイルAを読み出してクライアントへ配信する。Push判定部７０２は、クライアントがサーバPush配信に対応できるか否かを判定する。サブコンテンツ配信部７０３は、クライアントがサーバPush配信に対応していれば、前記各コンテンツデータB，C，DをクライアントへサーバPush配信し、対応していなければクライアントからのリクエストに応答して配信する。
【００３４】
本実施形態によれば、マルチドメイン構成のWebページについて、そのhtmlファイルおよび各コンテンツデータが同一ドメインのアクセラレションサーバASに予めキャッシュされるので、クライアントとアクセラレションサーバASとの間にSPDYコネクションを確立すれば、クライアントはアクセラレションサーバASに対してhtmlファイルのリクエストメッセージを送信するだけで、当該htmlファイルのみならず、残りのコンテンツデータもサーバPush配信により自動的に取得できるようになる。したがって、従来技術のように、クライアントが始めにhtmlファイルのみを取得して各コンテンツデータのドメインを識別後、各ドメインにそれぞれアクセスして残りのコンテンツデータを取得する場合に比べて、Webページの高速配信が可能になる。
【符号の説明】
【００３５】
１…コンテンツ取得部，２…記憶部，３…コンテンツ編集部，４…リクエスト受付部，５…リクエスト分析部，６…キャッシュ判定部，７…コンテンツ配信部，１０１…メインコンテンツ取得部，１０２…ドメイン解析部，１０３…サブコンテンツ取得部，３０１…ドメイン編集部，３０２…ファイル名編集部，７０１…メインコンテンツ配信部，７０２…Push判定部，７０３…サブコンテンツ配信部
【図１】
2014010622.tif 000003
【図２】
2014010622.tif 000004
【図３】
2014010622.tif 000005
【図４】
2014010622.tif 000006
【図５】
2014010622.tif 000007
【図６】
2014010622.tif 000008
【図７】
2014010622.tif 000009
【図８】
2014010622.tif 000010
【図９】
2014010622.tif 000011