(57)【要約】【課題】クライアントからマルチドメイン構成のWebページをリクエストされた際に、そのメインコンテンツに記述されているサブコンテンツのリンクURLをメインコンテンツのドメインに書き換えてからクライアントへ中継するWebコンテンツの配信装置において、ドメインの書き換えられたリンクURLによるリクエストからオリジナルのWebサーバを判定する。【解決手段】受信されたリクエストのPath部が絶対パス(https://)であれば、絶対パス部がオリジナルURLと判断される。相対パスの場合は、受信されたリクエストがオリジナルのリクエストと判断される。リクエストのPath部の先頭が共通パスの場合はリクエストURLのhttpsがhttpに変更され、Path部から共通パスを削除することでオリジナルリクエストのURLが再現される。それ以外は、受信リクエストのURLがそのままオリジナルURLとされる。【選択図】図２２
2014199564.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからのマルチドメイン構成のWebページのリクエストに応答して当該Webページの各コンテンツをドメインの異なる複数のWebサーバから取得し、前記クライアントへ配信するWebコンテンツの配信装置において、
WebページのリクエストURLに基づいてメインコンテンツを取得するメインコンテンツ取得手段と、
前記メインコンテンツをクライアントへ中継する際に、当該メインコンテンツに記述されている各サブコンテンツのリンクURLを前記リクエストURLのドメインに書き換えるリンクURL書換手段と、
前記ドメインの書き換えられたリンクURLによる各サブコンテンツのリクエストに基づいて当該サブコンテンツのオリジナルURLを判定するオリジナルURL判定手段と、
前記オリジナルURLの判定結果に基づいて各サブコンテンツを取得するサブコンテンツ取得手段とを具備したことを特徴とするWebコンテンツの配信装置。
【請求項２】
前記オリジナルURL判定手段は、前記リンクURLのPath部が絶対パスであると、当該Path部をオリジナルURLと判定することを特徴とする請求項１に記載のWebコンテンツの配信装置。
【請求項３】
前記オリジナルURL判定手段は、前記リンクURLのPath部が相対パスであると、当該リンクURLをオリジナルURLと判定することを特徴とする請求項１に記載のWebコンテンツの配信装置。
【請求項４】
前記オリジナルURL判定手段は、前記リンクURLのPath部の先頭が共通パスであると、当該Path部から前記共通パスを削除したものをオリジナルURLと判定することを特徴とする請求項１に記載の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コンテンツ配信の高速化が実現される。
【０００５】
一方、配信対象のWebページがマルチドメイン構成であって、そのインデックスファイル（htmlファイル）と少なくとも一つのコンテンツデータとが、ドメインの異なる複数のWebサーバに分散配置されていると、クライアントは、始めにWebサーバからインデックスファイルを取得する。このインデックスファイルには、Webページに出力される各コンテンツデータが分散配置されているWebサーバのドメインがリンク先として記述されている。クライアントは、このインデックスファイルの取得後、各ドメインへアクセスして各コンテンツデータを取得し、これらを結合することでWebページを再現する。したがって、クライアントはインデックスファイルの取得が完了しなければ、次の処理に進むことができない。
【０００６】
ここで、既存のTCPではドメインの異なる複数のWebサーバと同時に接続できるものの、同時に確立されるセッション数が制限されているので、Webページを構成するコンテンツデータ数が多い場合には、これらを同時に取得することができない。また、非特許文献１，３は、サーバが主導的にクライアントへコンテンツを配信する、いわゆるサーバPush配信に対応していないので、クライアントは全てのWebサーバに自らアクセスしてコンテンツ配信をリクエストしなければならなかった。
【０００７】
一方、非特許文献２のSPDYによれば、サーバとの間に同時に確立されるセッション数が制限されておらず、またクライアントがリクエストしたインデックスファイルと同一のWebサーバ上に蓄積されているコンテンツについてはサーバPush配信が可能である。
【０００８】
しかしながら、ドメインの異なる他のWebサーバに蓄積されているコンテンツについてはクライアントからのリクエストが必要となる。したがって、図２６に模式的に示したように、配信対象がマルチドメイン構成のWebページであると、クライアントはWebサーバWS1に自らアクセスしてインデックスファイルを取得するのみならず、他のコンテンツデータについても、WebサーバWS1，WS2，WS3…にそれぞれ自らアクセスして取得しなければならなかった。
【０００９】
このような技術課題に対して、本発明の発明者等は、マルチドメイン構成のWebページがリクエストされると、当該Webページのインデックスファイルおよび関連するコンテンツデータを各Webサーバから取得してキャッシュサーバ上に記憶し、同一ドメインで管理することにより、クライアントは当該キャッシュサーバへアクセスするだけで、インデックスファイルのみならずそのコンテンツデータも、SPDYによるサーバPush配信により簡単に取得できるようにする技術を発明し、特許出願した（特許文献３）。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特願２０１２−１４６８５９号
【非特許文献】
【００１１】
【非特許文献１】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サーバから取得したメインコンテンツ（インデックスファイル）およびサブコンテンツをアクセラレーションサーバからクライアントへSPDYプロトコルにより多重化してPush配信できるようにするために、メインコンテンツに記述されている各サブコンテンツのリンクURLのドメインがアクセラレーションサーバにおいてメインコンテンツのドメインに書き換えられてクライアントへ中継される。
【００１３】
したがって、メインコンテンツを受信したクライアントが、当該メインコンテンツに記述されているサブコンテンツのリンク先にアクセスしてサブコンテンツを取得する際のリクエストURLは、当該サブコンテンツを有するWebサーバのURL（オリジナルURL）とは異なることになる。したがって、当該リクエストURLを受信したアクセラレーションサーバはサブコンテンツのオリジナルURLを認識できず、サブコンテンツを取得できなくなってしまう。
【００１４】
本発明の目的は、上記した従来技術の課題を解決し、クライアントからマルチドメイン構成のWebページをリクエストされた際に、そのメインコンテンツに記述されているサブコンテンツのリンクURLをメインコンテンツのドメインに書き換えてからクライアントへ中継するWebコンテンツの配信装置において、その後、ドメインの書き換えられたリンクURLによるリクエストからオリジナルのWebサーバを判定してサブコンテンツを取得、配信できるWebコンテンツの配信装置を提供することにある。
【課題を解決するための手段】
【００１５】
上記の目的を達成するために、本発明は、クライアントからのマルチドメイン構成のWebページのリクエストに応答して当該Webページの各コンテンツをドメインの異なる複数のWebサーバから取得し、前記クライアントへ配信するWebコンテンツの配信装置において、WebページのリクエストURLに基づいてメインコンテンツを取得するメインコンテンツ取得手段と、前記メインコンテンツをクライアントへ中継する際に、当該メインコンテンツに記述されている各サブコンテンツのリンクURLを前記リクエストURLのドメインに書き換えるリンクURL書換手段と、ドメインの書き換えられたリンクURLによる各サブコンテンツのリクエストに基づいて当該サブコンテンツのオリジナルURLを判定するオリジナルURL判定手段と、オリジナルURLの判定結果に基づいて各サブコンテンツを取得するサブコンテンツ取得手段とを具備した。
【発明の効果】
【００１６】
本発明によれば、クライアントからマルチドメイン構成のWebページをリクエストされた際に、そのメインコンテンツに記述されているサブコンテンツのリンクURLをメインコンテンツのドメインに書き換えてからクライアントへ中継するWebコンテンツの配信装置において、ドメインの書き換えられたリンクURLによるリクエストからオリジナルのWebサーバを判定できるようになる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係るWebコンテンツ配信システムのネットワーク構成を示したブロック図である。
【図２】マルチドメイン構成のWebページの一例を示した図である。
【図３】SPDYアクセラレータの主要部の構成を示した機能ブロック図である。
【図４】本発明の一実施形態の動作を示したシーケンスフロー（その１）である。
【図５】本発明の一実施形態の動作を示したシーケンスフロー（その２）である。
【図６】リンクURLの代表的な書き換え例を示した図である。
【図７】HTMLコンテンツに記述されたリンクURLの分類方法を示した図である。
【図８】Type1に分類されたリンクURLの書き換え手順を示したフローチャートである。
【図９】省略URLの補完方法を示した図である。
【図１０】相対URLの補完方法を示した図である。
【図１１】Type2に分類されたリンクURLの書き換え条件を示した図である。
【図１２】Type2に分類されたリンクURLの書き換え手順を示したフローチャートである。
【図１３】リンクURLをType2書換規則で書き換える方法を示した図である。
【図１４】Type2書換規則による書き換え例を示した図である。
【図１５】Type3の基本的な書換規則を示した図である。
【図１６】Type4の基本的な書換規則を示した図である。
【図１７】CSSコンテンツにおけるリンクURLの書き換え例を示した図である。
【図１８】リンクURLの相対パスから絶対パスへの書き換え規則を示した図である。
【図１９】リンクURLの相対パスから絶対パスへの書き換え規則を示した図である。
【図２０】コンテンツ配信元のサーバがHTTPであり、オリジナルのhttpリクエストに対してHTTPSでのリダイレクトが求められた場合のWebページコンテンツの取得手順を示したシーケンスフローである。
【図２１】コンテンツ配信元のサーバがHTTPSである場合のオリジナルのhttpsリクエストによるWebページコンテンツの取得手順を示したシーケンスフローである。
【図２２】サブコンテンツのオリジナルURLを判定する方法を説明するための図である。
【図２３】cookieの具体的な書き換え例を示した図である。
【図２４】cookieの書き換え方法を模式的に示した機能ブロック図である。
【図２５】クライアントからのhttpsリクエストに対して、コンテンツと共に書き換えられたcookieが応答される手順を示したシーケンスフローである。
【図２６】SPDYによるWebページの配信方法を模式的に表現した図である。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の一実施形態に係るWebコンテンツ配信システムのネットワーク構成を示したブロック図であり、マルチドメイン構成のWebページについて、そのインデックスファイル（メインコンテンツ）や当該インデックスファイルに貼り付けられる画像ファイル（サブコンテンツ）が分散配置された複数のWebサーバと、クライアント１からのSPDY接続によるWebページコンテンツのリクエストを検知してオリジナルのWebサーバを判断し、当該Webサーバからコンテンツを取得するSPDYアクセラレータ(SPDA)２と、前記各WebサーバとSPDYアクセラレータ２との間に接続されてプロキシ機能を発揮するProxyサーバ３とを主要な構成とする。
【００１９】
前記各Webサーバには、それぞれ異なるドメインが割り当てられ、本実施形態では、WebサーバWS1にメインドメイン（クライアントが要求するindex.htmlファイルが存在するドメイン）"site-a.com" が割り当てられ、WebサーバWS2にサブドメイン "site-b.com"が割り当てられている。配信対象のWebページはマルチドメイン構成であり、図２に一例を示したように、メインコンテンツとしてのインデックスファイルと、当該インデックスファイルのページに貼り付けられるサブコンテンツとしての２つの画像ファイルA，Bとから構成されている。
【００２０】
図３は、前記SPDYアクセラレータ２の主要部の構成を示した機能ブロック図であり、ここでは本発明の説明に不要な構成は図示が省略されている。
【００２１】
リクエスト受付部２０１は、クライアントからhttpリクエストやhttpsリクエストを受け付ける。リダイレクト制御部２０２において、ユーザエージェント識別部２０２ａは、クライアント１の機能や能力を識別する。ホスト識別部２０２ｂは、要求されたWebページを管理するWebサーバを識別する。リダイレクト用URL生成部２０２ｃは、クライアント１から受信したWebページのHTTPリクエストを書き換えてリダイレクト用のHTTPSリクエストを生成する。本実施形態では、HTTPリクエストのスキームが"http"から"https"に書き換えら、さらに必要に応じて、共通パス追加部２０２ｄによりURLに共通パスが追加される。ダイレクト要求部２０２ｅは、クライアント１へ前記HTTPSリクエストによるリダイレクトを要求する。
【００２２】
多重化セッション確立部２０３は、前記HTTPSリクエストによるリダイレクトに応答して、複数のHTTPセッションが多重化されたHTTPSセッションをクライアントとの間に確立する。コンテンツ記憶部２０４は、前記HTTPSリクエストに基づいて、サブコンテンツのリンク先のドメインが記述されたメインコンテンツを取得するメインコンテンツ取得部２０４ａおよび前記リンク先の各ドメインにアクセスして各サブコンテンツを取得するサブコンテンツ取得部２０４ｂを含む。
【００２３】
リンクURL書換部２０５は、クライアント１とSPDYアクセラレータ２との間でのリンクアグリケーションを、クロスドメイン問題を発生させることなく実現すべく、前記Webページのリクエストに対して応答されたインデックスファイルに記述されているサブコンテンツのリンクURLを書き換える。
【００２４】
前記リンクURL書換部２０５は、後に詳述するように、各サブコンテンツのリンクURLを、リクエストURLおよび当該サブコンテンツのオリジナルのリンクURLに基づいて、リクエストURLのドメインに書き換える。リンクURLの書換要否は、コンテンツの種類、HTMLタグおよびリンクURLの記述形式の少なくとも一つに基づいて決定される。サブコンテンツのリンクURLの書き換えは、リクエストURLのアドレス部に当該サブコンテンツのオリジナルのリンクURLを結合することを基本的な書き換え規則とするが、サブコンテンツのリンクURLが省略URLであると、省略されているスキームがリクエストURLで補完される。また、サブコンテンツのリンクURLが相対パスであると、当該相対パスがリクエストURLで補完される。
【００２５】
cookie書換部２０６は、リンクアグリケーションにより生じうるcookieの齟齬を解消すべく、クライアント１へ付与するcookieのdomainおよびpathを書き換える。Push配信部２０７は、前記メインおよびサブの各コンテンツを、前記多重化されたHTTPSセッションでクライアントへPush配信する。
【００２６】
図４，５は、本発明の一実施形態の動作を示したシーケンスフローであり、ここでは、前記図２に示したマルチドメイン構成のWebページを取得する際の手順を、そのインデックスファイルがWebサーバWS1に配置され、２つの画像ファイルA，Bが、それぞれWebサーバWS1 (site-a.com)，WS2 (site-b.com)に分散配置されている場合を例にして説明する。
【００２７】
初めに図４を参照し、時刻t1では、クライアント１から第１DNSに対して、Webページのインデックスファイルを管理するドメイン"site-a.com"のアドレス解決が要求される。本実施形態では、第１DNSが当該システムの管理下にあるので、前記メインドメイン"site-a.com"とSPDYアクセラレータ２とが予め対応付けられている。したがって、時刻t2では、第１DNSからクライアント１に対して、SPDYアクセラレータ２のIPアドレス（ここでは、"10.10.10.10"）が応答される。
【００２８】
時刻t3では、クライアント１がSPDYアクセラレータ２のIPアドレスへアクセスすることでTCPコネクションが確立される。時刻t4では、クライアント１がインデックスファイルを前記ドメイン"site-a.com"から取得するためのhttpリクエスト "http://site-a.com/index.html" が送信される。
【００２９】
時刻t5では、SPDYアクセラレータ２において、前記リクエストメッセージのスキーム、クライアント１の機能およびアクセス先のドメインが管理下にあるか否かが判定される。ここでは、リクエストメッセージのスキームが "http" と判定され、クライアント１がSPDY接続機能を備え、かつドメイン"site-a.com"が管理下にあると判断されるので、クライアント１に対してhttpsによるリダイレクトを要求するために、前記リダイレクト用URL生成部２０２ｃによりhttpsリダイレクト用URLが生成される。
【００３０】
本実施形態では、前記httpリクエストのスキームが"https"に書き替えられ、かつドメイン部分の後に、前記共通パス追加部２０２ｄにより共通パスが追加されてリダイレクト用URL "https://site-a.com/共通パス/index.html" とされる。これは、クライアント１が前記書き換えられたURLで再要求（HTTPSリクエスト）する際に、クライアントのブラウザのアドレス表示部に前記書き換えられたURLが表示され、これがフィッシングによる書き換えと誤認されるおそれがあるため、本実施形態では、このような悪意による書き換えと区別するために共通パスが追加される。時刻t6では、前記リダイレクト用URLが、前記リダイレクト要求部２０２ｅによりクライアント１へ通知される。なお、当該時刻t5，t6の各処理は、時刻t4においてクライアントから送信されたメッセージがhttpsリクエストであれば省略される。
【００３１】
時刻t7では、クライアント１とSPDYアクセラレータ２との間に、前記多重化セッション確立部２０３によりSSLセッションが確立される。時刻t8では、クライアント１から前記リダイレクトURLへhttpsリクエストが送信される。時刻t9では、SPDYアクセラレータ２において、前記リダイレクトURLに基づいてコンテンツサーバ（ここでは、WebサーバWS1）のオリジナルURLが判別される。本実施形態では、前記リダイレクトURLから共通パスを削除することでオリジナルURLが再現され、当該再現されたオリジナルURLに基づいてWebサーバWS1が判別される。
【００３２】
時刻t10では、SPDYアクセラレータ２から前記オリジナルURLへhttp(s)リクエストが送信され、これがProxyサーバ３により受信される。本実施形態では、前記リダイレクトが発生していなければhttpsリクエストが送信され、前記リダイレクトが発生していればhttpリクエストが送信される。Proxyサーバ３は、リクエストされたコンテンツ（ここでは、インデックスファイル）をキャッシュしていれば当該コンテンツを代理応答する一方、キャッシュしていなければ、時刻t11において第２DNSへアドレス解決を要求する。時刻t12では、第２DNSからProxyサーバ３へ、前記WebサーバWS1のIPアドレス"203.178.143.xx"が応答される。時刻t13では、Proxyサーバ３からWebサーバWS1へ、インデックスファイルのリクエストメッセージが送信される。時刻t14では、WebサーバWS1からProxyサーバ３へ前記インデックスファイルが応答される。
【００３３】
時刻t15では、Proxyサーバ３からSPDYアクセラレータ２へ、前記インデックスファイルが応答される。時刻t16では、SPDYアクセラレータ２において、前記インデックスファイルに各サブコンテンツ（画像A，B）の登録先として記述されているリンクURLが、クロスドメイン問題を発生させることなく、クライアント１とProxyサーバ３との間でのリンクアグリケーションを実現するために、前記proxyサーバ経由のリンクURLに書き換えられる。
【００３４】
図６は、リンクURLの代表的な書き換え例を示した図であり、本実施形態では、リクエストURL "https://site-a.com/index.html" のアドレス部 "https://site-a.com" とリンクURL "https://site-b.com/b.jpg" とが結合されて書き換え後URL "https://site-a.com/https://site-b.com/b.jpg" とされる。以下、応答されたインデックスファイルに記述されているリンクURLの書き換え方法について詳細に説明する。
【００３５】
本実施形態では、WebサーバWS1からの取得したインデックスファイルがHTMLコンテンツまたはCSS（スタイルシート）コンテンツであると、当該インデックスファイルに記述されているリンクURLが、同一ホスト(本実施形態では、SPDYアクセラレータ２)経由に書き換えられる。インデックスファイルがHTMLコンテンツおよびCSSコンテンツのいずれでもない場合、例えばJavaScript（登録商標）ファイルなどの場合には、書き換えが行われない。
【００３６】
ここでは、初めに(1)HTMLコンテンツにおけるリンクURLの書き換えについて説明し、次いで(2)CSSコンテンツにおけるリンクURLの書き換えについて説明する。さらに、リンクURLの書き換え処理中に、相対パスから絶対パスへの書き換えを行う場合があるため、(3)相対パスから絶対パスへの書き換え規則（相対→絶対パス変換規則）についても説明する。
【００３７】
(1)HTMLコンテンツにおけるリンクURLの書き換え
図７は、HTMLコンテンツに記述されたリンクURLの分類方法を示した図であり、本実施形態では各リンクURLが、そのタグおよび属性に基づいて、図示の通りType1からType4のいずれかに分類され、Typeごとに固有の書換規則が適用される。
【００３８】
図８は、Type1に分類されたリンクURLの書き換え手順を示したフローチャートであり、ステップＳ１１では、リンクURLの先頭文字が参照され、"#"（フラグメント）であれば「書き換えなし」と判定され、"#"でなければステップＳ１２へ進む。ステップＳ１２では、リンクURLが絶対URLであるか否かが判定され、絶対URLであれば「書き換えなし」と判定され、絶対URLでなければステップＳ１３へ進む。
【００３９】
ステップＳ１３では、リンクURLが省略URLであるか否かが判定され、省略URLであれば、図９(a)，(b)に一例を示したように、省略されているスキームをオリジナルURLで補完する書き換えが行われる。これに対して、省略URLでなければステップＳ１４へ進み、リクエストURLのスキームがhttpsであれば「書き換えなし」と判定され、httpsでなければステップＳ１５へ進む。
【００４０】
ステップＳ１５では、リンクURLが相対パスであるか否かが判定される。相対パスでなければステップＳ１７へ進み、図１０(a)，(b)に示したように、相対URLをオリジナルURLのアドレスで補完する書き換えが行われる。これに対して、リンクURLが相対パスであればステップＳ１６へ進み、相対パスを絶対パスに変更した後に前記ステップＳ１７へ進む。
【００４１】
図１１は、Type2に分類されたリンクURLの書き換え条件を示した図であり、図１２は、Type2に分類されたリンクURLの書き換え手順を示したフローチャートである。
【００４２】
ここでは、リンクURLが相対URLであるか絶対URLであるかに応じて書換規則が異なり、基本的に、絶対URLの場合は全て書き換えが行われ、相対URLの場合は、リクエストURLのスキームがhttpの場合のみ書き換えが行われる。なお、オプション機能として、動的コンテンツに関する書き換え有無選択機能、ホストチェック有無判定機能および書き換え対象ホストチェック機能を使用することも可能とする。
【００４３】
ここで、URLホストチェックの書き換え対象とは、SPDYアクセラレータ２を使用するよう管理されたサイト（ホスト）のことであり、動的リソースの書き換えは、オプション機能でONとした場合のみ有効で、URLのパス部に"?"を含むURLも書き換えを行うことが可能である。
【００４４】
図１２において、ステップＳ２１では、リンクURLが省略URLであるか否かが判定される。省略URLであれば、ステップＳ２２へ進んで絶対URLに書き換えられる。ステップＳ２３では、リンクURLが絶対URLおよび相対URLのいずれであるかが判定される。相対URLであればステップＳ２４へ進み、リクエストURLのスキームがhttpであるか否かが判定される。httpでなければ「書き換えなし」と判定され、httpであればステップＳ２５へ進む。
【００４５】
ステップＳ２５では、リンクURLが動的リソースであるか否かが判定される。動的リソースであればステップ２６へ進み、動的リソース書き換えのオプションを使用するか否かが判定される。使用しないと判定されれば、ステップＳ２７へ進んで前記Type1の書換規則が適用される。これに対して、オプションを使用する場合は、ステップＳ２８へ進んでリンクURLがType2書換規則で書き換えられる。
【００４６】
図１３は、前記ステップＳ２８における書き換え方法の一例を示した図であり、リクエストURLからスキーム(https)およびFQDNが取得され、取得された項目がアグリゲートホストとされる。次いで、リンクURLが相対パスの場合、相対→絶対パス変換規則に従って絶対パスへ変換される。そして、リンクURLの前に前記アグリゲートホストを付加する書き換えが行われる。
【００４７】
一方、前記ステップＳ２３において、リンクURLが絶対URLと判断されるとステップＳ２９へ進み、URLスキームがhttpおよびhttpsのいずれかであるかが判定される。httpおよびhttpsのいずれでもなければ「書き換えなし」とされ、httpおよびhttpsのいずれかであればステップＳ３０へ進む。ステップＳ３０では、URLホストチェックを使用するか否かが判定され、使用するのであればステップＳ３１へ進む。ステップＳ３１では、書き換え対象であるか否かが判定され、書き換え対象でなければ書き換えが行われず、書き換え対象であればステップＳ３２へ進む。
【００４８】
ステップＳ３２では、リンクURLが動的リソースであるか否かが判定される。動的リソースであればステップ３３へ進み、動的リソース書換のオプションを使用するか否かが判定される。使用しないと判定されれば「書き換えなし」とされる。これに対して、オプションを使用する場合はステップＳ３４へ進み、前記ステップＳ２８と同様の書き換えが行われる。
【００４９】
図１４は、Type2書換規則による書き換え例を示した図であり、同図(a)は、インデックスファイル（htmlコンテンツ）に記述されているリンクURLの一覧を示しており、同図(b)は、リクエストURLが "https://site-a.com/index.html" であって、オリジナルのWebサーバ(site-a.com)からhttpsでコンテンツを取得した場合の各リンクURLの書き換え例を示しており、同図(c)は、リクエストURLが共通パス"spda"を含む "https://site-a.com/spda/index.html" であって、オリジナルのWebサーバ(site-a.com)からhttpでコンテンツを取得した場合の各リンクURLの書き換え例を示している。
【００５０】
図１５は、Type3の基本的な書換規則を示した図であり、タグが図示の通りであると、前記TYPE2書換規則に従ってリンクURLが書き換えられる。図１６は、Type4の基本的な書換規則を示した図であり、HTML内のタグがMETAタグであって、かつhttp-equiv属性の属性値がrefreshであると、content属性の属性値がType1書換規則に従って書き換えられる。
【００５１】
(2)CSSコンテンツにおけるリンクURLの書き換え
図１７は、CSSコンテンツにおけるリンクURLの書き換え例を示した図であり、各要素に対して、前記TYPE2書換規則と同一規則で書き換えが行われる。
【００５２】
(3)相対パスから絶対パスへの書き換え規則（相対→絶対パス変換規則）
図１８，１９は、リンクURLの相対パスから絶対パスへの書き換え規則を示した図であり、HTMLファイル内のbaseタグの有無で処理が異なる。
【００５３】
図１８は、baseタグがない場合の書き換え方法を示した図であり、初めに、リクエストURLからオリジナルURLが取得され、オリジナルURLのPath部のベースディレクトリが取得される[同図(a)]。次いで、リンクURLの相対パスをベースディレクトリで補完することで絶対パスが作成される[同図(b)]。最後に、作成された絶対パス、オリジナルURLのスキームおよびFQDNに基づいて絶対URLが作成される。
【００５４】
図１９は、baseタグがある場合の書き換え方法を示した図であり、baseタグのhref属性値が取得されると、取得属性値の形式ごとにベースディレクトリが取得される。絶対URL形式の場合は、同図(a)に示したように、ベースディレクトリは取得URLのPath部のディレクトリとなる。また、絶対パス（先頭文字が"/"で始まる）の場合は、同図(b)に示したように、ベースディレクトリは属性値のディレクトリとなる。さらに、属性値が相対パス（先頭文字が"/"で始まらない）の場合は、同図(c)に示したように、ベースディレクトリはオリジナルURLのPath部のディレクトリ＋属性値となる。
【００５５】
次いで、同図(d)に示したように、リンクURLの相対パスをベースディレクトリで補完することにより絶対パスが作成される。最後に、同図(e)に示したように、作成された絶対パスおよびリクエストURLに基づいて絶対URLが作成される。
【００５６】
図２０は、コンテンツ配信元のWebサーバがHTTPであり、オリジナルのhttpリクエストに対してHTTPSでのリダイレクトが求められた場合のWebページコンテンツの取得手順を、特にリンクURLの書き換えに着目して示したシーケンスフローである。
【００５７】
時刻t51において、共通パス"spda"の付されたリダイレクトURL "https://site-a.com/spda/index.html"でアクセスされたSPDYアクセラレータ２は、時刻t52において、当該リダイレクトURLから共通パス"spda" を削除し、かつスキームを"https"から"http"へ書き換えることでオリジナルURL "http://site-a.com/index.html"を再現して、時刻t53においてsite-a.comへアクセスする。
【００５８】
このhttpリクエストに対して、時刻t54において応答されたhtmlファイル（メインコンテンツ）に、図示のとおり９個のリンクURL（オリジナル）が記述されていれば、各リンクURLがSPDYアクセラレータ２において図示の通りにtype分類され、各リンクURLに適用される書換規則が決定される。SPDYアクセラレータ２は、時刻t55において、各リンクURLを前記書換規則にしたがって書き換え、書き換え済みのインデックスhtmlファイルを、時刻t56においてクライアント１へ応答する。
【００５９】
図２１は、コンテンツ配信元のWebサーバがHTTPSである場合のオリジナルのhttpsリクエストによるWebページコンテンツの取得手順を、特にリンクURLの書き換えに着目して示したシーケンスフローである。
【００６０】
図５へ戻り、時刻t17では、前記リンクURLの書き換えられたインデックスファイルがSPDYアクセラレータ２からクライアント１へ応答される。時刻t18-t30では、前記メインコンテンツに記述されているリンクURLが解釈されて各サブコンテンツの先読みが実施される。なお、当該先読みは選択機能であり、先読み機能が無効化されている場合には、後述する時刻t26，t27でのサブコンテンツのリクエストを待って実施される。
【００６１】
時刻t18，t19では、SPDYアクセラレータ２において各サブコンテンツ（画像A，B）の先読みが実行され、前記インデックスファイルに記述されている各サブコンテンツのリンクURLへリクエストメッセージが送信される。Proxyサーバ３では、各リンクURLのサブコンテンツをキャッシュ済みであるか否かが判定される。ここでは、全てのサブコンテンツがキャッシュ済みではなく、したがって、オリジナルの各WebサーバWSから取得する必要があるものとして説明を続ける。
【００６２】
時刻t20では、Proxyサーバ３からWebサーバWS1へ、画像Aのリクエストメッセージが送信される。本実施形態では、Proxyサーバ３にとってWebサーバWS1のアドレスは既知なので、WebサーバWS1に対してリクエストメッセージを直ちに送信できる。
【００６３】
これに対してして、Proxyサーバ３にとってWebサーバWS2のアドレスは未知なので、時刻t21では、Proxyサーバ３から第２DNSへ、WebサーバWS2のアドレス解決が要求される。時刻t22では、第２DNSからProxyサーバ３へ、WebサーバWS2のIPアドレス "203.178,128.XX" が応答される。時刻t23では、Proxyサーバ３からWebサーバWS2へ、画像Bのリクエストメッセージが送信される。時刻t24では、WebサーバWS1からProxyサーバ３へ画像Aが応答される。時刻t25では、WebサーバWS2からProxyサーバ３へ画像Bが応答される。
【００６４】
これと平行して、時刻t26では、クライアント１からSPDYアクセラレータ２へ、前記画像Aを要求するhttpsリクエストが送信される。時刻t27では、クライアント１からSPDYアクセラレータ２へ、前記画像Bを要求するhttpsリクエストが送信される。時刻t28では、前記httpsリクエストを受信したSPDYアクセラレータ２において各サブコンテンツの取得先サーバが判別される。
【００６５】
図２２は、サブコンテンツのオリジナルURLを判定する方法を説明するための図であり、本実施形態では、受信されたリクエストのPath部が絶対パス(https://)であれば、当該絶対パス部がオリジナルURLと判断される。相対パスの場合は、受信されたリクエストがオリジナルのリクエストと判断される。リクエストのPath部の先頭が共通パスの場合はリクエストURLのhttpsがhttpに変更され、Path部から共通パスを削除することでオリジナルリクエストのURLが再現される。それ以外は、受信リクエストのURLがそのままオリジナルURLとされる。
【００６６】
時刻t29では、Proxyサーバ３からSPDYアクセラレータ２へ前記画像Aが応答される。時刻t30では、Proxyサーバ３からSPDYアクセラレータ２へ前記画像Bが応答される。時刻t31では、SPDYアクセラレータ２のcookie書換部２０６においてcookieの書き換えが行われる。
【００６７】
すなわち、アグリゲーション機能により書き換えられたURLのリソースにcookieが付加されている場合、そのままではクライアント１が取得しているサーバと実際のサーバとが一致しておらず、それに付随するcookieも一致しない。そこでSPDYアクセラレータ２は、アグリゲーションされたURLのリソース受信時にレスポンスヘッダ内のSet-Cookie情報のDomainおよびPathを書き換える。
【００６８】
図２３は、cookieの具体的な書き換え例を示した図であり、DomainがリクエストURLのFQDNに書き換えられ、PathがリクエストのPath情報に書き換えられる。SPDYアクセラレータ２でリンクアグリゲーションを行った場合、クライアント１からSPDYアクセラレータ２へのリクエストURLは、メインドメイン名およびオリジナルURLで構成されている。SPDYアクセラレータ２は、Webサーバから受信したcookieおよびリクエストURLより、cookieのdomainをメインドメイン名に、pathをオリジナルURLに書き換える。
【００６９】
図２４は、cookieの書き換え方法を模式的に示した機能ブロック図であり、クライアント１からのリクエストに対して、WebサーバWS1がコンテンツと共に応答するcookieには、domain[site-a]，path[path1]およびvalue値[v1]が記述されている。同様に、WebサーバWS2がコンテンツと共に応答するcookieには、domain[site-b]，path[path2]およびvalue値[v2]が記述されている。
【００７０】
SPDYアクセラレータ２のcookie書換部２０６は、各WebサーバWSから受け取ったcookieのdomainを[メインドメイン]に書き換え、pathを[オリジナルURL＋path]に書き換える。すなわち、WebサーバWS1から受け取ったcookieは、pathが[path1]から[site-a+path1]に書き換えられる。また、WebサーバWS2から受け取ったcookieは、domainが[site-b]から[site-a]に書き換えられ、pathが[path2]から[site-b+path2]に書き換えられる。なお、いずれのcookieでもvalue値は書き換えられない。
【００７１】
図２５は、クライアント１からのhttpsリクエストに対して、コンテンツと共に書き換えられたcookieが応答される手順を示したシーケンスフローであり、時刻t71では、クライアント１からSPDYアクセラレータ２へ、リンクアグリケーションしたURLでhttpsリクエストが送信される。
【００７２】
時刻t72では、SPDYアクセラレータ２からWebサーバWS2へコンテンツがリクエストされる。時刻t73では、WebサーバWS2が、domain，pathおよびvalue値の設定されたcookieを、前記要求されたコンテンツと共にSPDYアクセラレータ２へ応答する。時刻t74では、SPDYアクセラレータ２において、前記cookieが、domainがメインドメインに書き換えられ、pathがオリジナルURL＋pathに書き換えられる。時刻t75では、SPDYアクセラレータ２からクライアント１へ、前記コンテンツと共に前記domain，pathおよびvalue値の書き換えられたcookieが応答される。
【符号の説明】
【００７３】
１…クライアント，２…SPDYアクセラレータ，３…Proxyサーバ，２０１…リクエスト受付部，２０２…リダイレクト制御部，２０２ａ…ユーザエージェント識別部，２０２ｂ…ホスト識別部，２０２ｃ…リダイレクト用URL生成部，２０２ｄ…共通パス追加部，２０２ｅ…ダイレクト要求部，２０３…多重化セッション確立部，２０４…コンテンツ記憶部，２０４ａ…メインコンテンツ取得部，２０４ｂ…サブコンテンツ取得部，２０５…リンクURL書換部，２０６…cookie書換部，２０７…Push配信部
【図１】
2014199564.tif 000003
【図２】
2014199564.tif 000004
【図３】
2014199564.tif 000005
【図４】
2014199564.tif 000006
【図５】
2014199564.tif 000007
【図６】
2014199564.tif 000008
【図７】
2014199564.tif 000009
【図８】
2014199564.tif 000010
【図９】
2014199564.tif 000011
【図１０】
2014199564.tif 000012
【図１１】
2014199564.tif 000013
【図１２】
2014199564.tif 000014
【図１３】
2014199564.tif 000015
【図１４】
2014199564.tif 000016
【図１５】
2014199564.tif 000017
【図１６】
2014199564.tif 000018
【図１７】
2014199564.tif 000019
【図１８】
2014199564.tif 000020
【図１９】
2014199564.tif 000021
【図２０】
2014199564.tif 000022
【図２１】
2014199564.tif 000023
【図２２】
2014199564.tif 000024
【図２３】
2014199564.tif 000025
【図２４】
2014199564.tif 000026
【図２５】
2014199564.tif 000027
【図２６】
2014199564.tif 000028