JP6081847B2 - Ｗｅｂコンテンツの配信装置 - Google Patents

Description

本発明は、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配信部

Claims (4)

1. クライアントからのマルチドメイン構成のWebページのリクエストに応答して当該Webページの各コンテンツをドメインの異なる複数のWebサーバから取得し、前記クライアントへ配信するWebコンテンツの配信装置において、
   WebページのリクエストURLに基づいてメインコンテンツを取得するメインコンテンツ取得手段と、
   前記メインコンテンツをクライアントへ中継する際に、当該メインコンテンツに記述されている各サブコンテンツのリンクURLを前記リクエストURLのドメインに書き換えるリンクURL書換手段と、
   クライアントから受信した、サブコンテンツを要求するリクエストURLに基づいて当該サブコンテンツのオリジナルURLを判定するオリジナルURL判定手段と、
   前記オリジナルURLの判定結果に基づいて各サブコンテンツを取得するサブコンテンツ取得手段とを具備し、
   前記リンクURL書換手段は、前記リンクURLのスキームとリクエストURLのスキームとの同異にかかわらず前記オリジナルURL判定手段がサブコンテンツのオリジナルURLを、そのスキームを含めて判定可能に書き換えることを特徴とするWebコンテンツの配信装置。
2. 前記オリジナルURL判定手段は、前記リンクURLのPath部が絶対パスであると、当該Path部をオリジナルURLと判定することを特徴とする請求項１に記載のWebコンテンツの配信装置。
3. 前記オリジナルURL判定手段は、前記リンクURLのPath部が相対パスであると、当該リンクURLをオリジナルURLと判定することを特徴とする請求項１に記載のWebコンテンツの配信装置。
4. 前記オリジナルURL判定手段は、前記リンクURLのPath部の先頭が共通パスであると、当該Path部から前記共通パスを削除したものをオリジナルURLと判定することを特徴とする請求項１に記載のWebコンテンツの配信装置。