"コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されており、前記オリジンサーバは、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、前記ドメイン解決サーバは、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、データ転送システム。請求項1に記載のデータ転送システムであって、前記オリジンサーバが有する前記コンテンツ処理手段は、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、データ転送システム。請求項1又は2に記載のデータ転送システムであって、前記オリジンサーバが有する前記コンテンツ処理手段は、前記サブストリームの総数を含む前記識別子を、前記ブロックに付与する、データ転送システム。請求項1乃至3のいずれかに記載のデータ転送システムであって、前記クライアントがアクセスしたエッジサイトにおいて、前記クライアントと前記プロキシサーバとの間に、前記コンテンツを転送する中継サーバを備え、前記ドメイン解決サーバの割り当て手段は、前記クライアントのドメイン解決要求に対して、前記クライアントが設定可能なコネクション数の上限以内の中継サーバを割当てる、データ転送システム。コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバであって、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、オリジンサーバ。請求項5に記載のオリジンサーバであって、前記コンテンツ処理手段は、サブストリームの総数を含む前記識別子を、前記ブロックに付与する、オリジンサーバ。コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバに組み込まれるプログラムであって、前記オリジンサーバに、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を実現させると共に、前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、プログラム。コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバであって、前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、ドメイン解決サーバ。コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバに組み込まれるプログラムであって、前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、前記ドメイン解決サーバに、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を実現すると共に、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、プログラム。コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、前記オリジンサーバが、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与し、前記ドメイン解決サーバが、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定し、前記ドメイン解決サーバによるプロキシサーバの割り当て時に、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、データ転送方法。請求項10に記載のデータ転送方法であって、前記オリジンサーバが前記ブロックに識別子を付与するときに、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、データ転送方法。しかしながら、上述した文献に開示された技術では、以下のような問題がある。まず、上記特許文献1には、まだオリジンサイトとエッジサイトの間のスループットを増大させる余地がのこっている。なぜなら、中継サイトになる候補のサイトからのみRTTを測定するので、片方向しかみておらず、ルートの非対称性が大きいサイト間がある場合は、適切な制御ができないからである。また、エッジサーバからオリジンサーバまで最大2ホップまでしか考慮されておらず、よりホップ数が許さればサイト間のRTTが押さえられてスループットが増大する可能性があるからである。また、非特許文献2では、上記特許文献1における2ホップという制限を越えて配信経路を最適化するが、動的な最適化の具体的方法が示されていない。また、非特許文献3は、動的にポイントツーポイントのオーバレイパスの設定を行うが、複数のサイトへの分配には対応していない。また、動的再構成のための性能測定と、その統計値の取得は別々の手順で実行する必要がある。さらに、上記特許文献1では、動的にエッジサーバとオリジンサーバとのポイントツーポイントの経路設定できても、オリジンサーバから複数のエッジサーバに効率的に分配する経路を設定することができない。なぜならオリジンサイトへの直通パスと中継サイトを含む2つの経路候補の中から一つを選ぶ際に、中継サイトに欲しいデータがキャッシュされているかどうかを判断指標にいれないからである。また、非特許文献4は、並列分割転送する分、スループットを増大できるが、サイトに複数のサーバを設置して収容能力を増大させるような状況には対応していない。なぜならいわゆるピアツーピア形式でファウルをクライアント同士で分配することを前提としているからである。また、非特許文献1は、まだスループットを増大させる余地がある。なぜなら、分割したブロック毎に中継サーバを割り当てるが、それは2ホップ目におけるものだけだからである。また、非特許文献1では、ブロック数が増えると処理負荷や必要資源が増加するという問題がある。なぜなら、ブロックを転送する毎にHTTPコネクションを設定する必要があり、また、ドメイン解決のためのメッセージ処理数が増えるからである。さらに、非特許文献4の問題点としてすでに記述しているが、上記特許文献1以外の技術では、サイト内でのサーバクラスタ化による収容能力の増大を考慮することができない。このため、本発明の目的は、上述した課題である、ネットワーク上に分散配置された複数のサーバ装置間におけるデータ転送のスループットを改善する、ことにある。上記目的を達成すべく、本発明の一形態であるデータ転送システムは、コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されており、前記オリジンサーバは、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、前記ドメイン解決サーバは、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、という構成を採る。また、本発明の他の形態であるオリジンサーバは、コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバであって、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、という構成を採る。また、本発明の他の形態であるプログラムは、コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバに組み込まれるプログラムであって、前記オリジンサーバに、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を実現させると共に、前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、という構成を採る。また、本発明の他の形態であるドメイン解決サーバは、コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバであって、前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、という構成を採る。また、本発明の他の形態であるプログラムは、コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバに組み込まれるプログラムであって、前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、前記ドメイン解決サーバに、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を実現すると共に、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、という構成を採る。また、本発明の他の形態であるデータ転送方法は、コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、前記オリジンサーバが、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与し、前記ドメイン解決サーバが、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定し、前記ドメイン解決サーバによるプロキシサーバの割り当て時に、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、という構成を採る。本発明は、以上のように構成されるため、これによると、ネットワーク上に分散配置された複数のサーバコンピュータ間におけるデータ転送のスループットの向上を図ることができる。<実施形態1>本発明の第1の実施形態を、図1乃至図11を参照して説明する。図1乃至図5は、データ転送システムの構成を示す図であり、図6乃至図11は、データ転送システムの動作を示す図である。[システム全体構成]図1に示すように、本発明におけるデータ転送システムは、クライアント41~44と、分配システム22と、からなる。そして、分配システム22は、クライアント41~44に対して、コンテンツの投稿や配信のサービスを行なうもので、複数のサイト101~104と、それらをつなぐサブネットワーク18と、により構成されている。上記クライアント41~44は、所定のユーザが操作するパーソナルコンピュータなどの情報処理端末であり、適切なサイトに誘導されて、HTTPを用いてコンテンツをアップロードしたり、ダウンロードしたりする機能を有する。また、クライアント41~44は、サブネットワーク18とは同じもしくは独立のネットワークを通じて、サイト101~104とコンテンツをやり取りする。図2に示すように、サイト102は、オリジンサーバOGS202と、ドメイン解決サーバ302DRS、プロキシサーバPS503~505と、マルチレイヤスイッチMLS19と、エッジルータ20と、を備えている。オリジンサーバOGS202は、コンテンツのアップロードを受け付ける。ドメイン解決サーバDRS302は、他のサイトのDRSからの要求に基づいて、コンテンツデータ要求HTTPリクエストを転送する先のプロキシサーバPSのアドレスの解決を行う。エッジルータ20は、サイト内の各装置とサブネットワークとの接続をIPレベルで行うものである。MLS19は、OGS202、PS503~505、DRS302、エッジルータ20を接続する。なお、全てのサイト101~104はほぼ同一の構成を採っているため、ここでは、符号102に示すサイトのみを説明する。以下、各構成について詳述する。[オリジンサーバOGS]まず、オリジンサーバ202OGSは、ドメイン毎に転送先のPSのドメイン解決を要求する既存のクライアントやプロキシサーバPSを前提に、異なるURI毎に次ホップのサイト内に複数あるPSの一つを割当てるため、特許文献2にあるようなURIの変換を行う。なお、URI単位でドメイン解決要求をすることができる場合は、このURIの変換は不要になる。すなわちOGS202では、コンテンツ発行者から新たにアップロードされたコンテンツのデータを、HDD等の記憶装置に格納した後、そのファイルに以下のようなOURIを付与する。OURIhttpwwwsite1songnetvideocastchannel3item2ここでOURIの構成の仕方について説明しておく。songnetは、この配信サービスを提供する主体を示し、site1は、このコンテンツが発行者からアップロードされた先であるオリジンサイトを示し、wwwは、オリジンサーバとしてのホスト名を示している。配信サービス提供主体がN個のサイトを運営している場合、例えば各サイトをsite1...siteNと示す。次にOURIのパスの部分において、videocastはコンテンツ提供サービスの名称を、channel3は、個別のチャンネルを、item2は、個別の配信プログラムをそれぞれ示している。次に、OURIをハッシュしてこの値をここでは1578とする、それにfをつけて得られるf1578というドメインをwwwと入れ替えて、次のようにFURIを得る。FURIhttpf1578site1songnetvideocastchannel3item2ここで説明を簡単にするため、以下のようにドメインの呼び方をつける。Oドメイン:site1songnetオリジンサイトに対応するサブドメイン。詳細は後述するが、オリジンサイトを示すドメインを含ませることで、オリジンサイト毎にそれをルートにもつ有向分配木を作成してドメイン解決要求をその分配木上の経路にそって転送することができるようになる。Fドメイン:f1578site1songnet異なるOURIに対応するように変換されたのちのドメイン名。OURIは、ポータルサイトでデータを取得するためのリンクとして使われ、それをクリックすると、OURIを含むHTTPリクエストがオリジンサイトに送られ、そこから番組ファイルを取得するために使われるメタデータがHTTPレスポンスとしてクライアントにダウンロードされる。下記はそのメタデータに含まれる情報である。OURIhttpwwwsite1songnetvideocastchannel3item2エッジサイトDRSのアドレス:29147234122914723413FURIhttpf1578site1songnetvideocastchannel3item2ここで、エッジサイトに設置されたDRSのアドレスは、クライアントがメタデータの要求をしてきたタイミングで、そのクライアントのIPアドレスに基づいて、クライアントを誘導すべき最寄りのエッジサイトのDRSのアドレスとしてオリジンサーバが決定する。ここではDRSの障害を考慮して、2つのDRSアドレスが2つ記載されている。上記のメタデータはXML形式で記述してもよい。こうして、URIが指定されたリソースの状態をXML形式で提供するWebサービスは、RESTfulと呼ばれる非特許文献7参照。なお、特許文献1でも、上記の同じように、異なるURIのコンテンツ毎にキャッシュサーバを割当てるため、オリジナルのURIに対してハッシングを行って仮想サーバを割当て、オリジナルのURIをパスの部分にもっていって、その前にAkamaiの仮想サーバのドメインをつけることで、新たなURIを作る。一方、本発明では、上記とは異なり、配信用のサイトのみならずオリジンサイトもサービス運用者が同時に運用するので、オリジナルのURI全体を変換後のURIのパス部分に埋め込む必要はない。[プロキシサーバPS]本発明で用いるプロキシサーバ503~505以下PSと略すでは、非特許文献8にあるような既存のものへの機能追加機能は最低限にしている。以下にPSの構成及び動作について説明する。プロキシサーバ503~505は、親となるサイトのPSからもらったブロックを、キャッシュもしくは記憶しておき、次に別のサイトから要求があったときに備える。ここで分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトを親サイト、ルートからより遠い側のサイト、つまり下流側のサイトを子サイトと、それぞれ呼ぶ。PSは、HTTPリクエストを受信すると、そこに含まれるURIのデータを格納している場合は、それをHTTPレスポンスとして返す。格納していない場合は、DRSにFドメインに対して割当てられるPSのアドレスを得るために、ドメイン解決要求をし、戻ってきたら、そのPSのアドレスに向けて、HTTPリクエストを転送する。HTTPリクエストに対して、HTTPレスポンスが戻ってきたら、そのURIに対して要求していたサーバにHTTPレスポンスを返送する。PSでのデータ転送と蓄積は、HTTPコンテンツのデータは入出力が速いメモリ上で扱うことを前提とする。これは特にオリジンサイトにおいては、OGSにおいてメモリよりも読み出しが遅いHDDにあるデータを、PSにキャッシュさせてから転送に使うことで、性能向上を図っている。[ドメイン解決サーバDRS]図3に示すように、ドメイン解決サーバDRS302は、送信装置14と、受信装置15と、データ処理装置8と、記憶装置9と、を備えている。送信装置14および受信装置15は、他のサイトのDRSとドメイン解決要求応答メッセージおよびRTT統計値要求応答メッセージをそれぞれやりとりしている。データ処理装置8は、プログラムが組み込まれることで構築された、PS割当て部81と、親DRS決定部82と、を備えている。ここで、親DRSとは、ドメイン解決要求を次に転送すべき親サイトのDRSを指す。また、親サイトとは、後述するように生成された有向分配木の転送経路上で隣接する2サイトの中で、ルートにより近い側のサイト、つまり、上流側のサイトを指す。親DRS決定部82計測手段、経路設定手段は、ドメイン解決要求を送るべき親サイトのDRSのアドレスを決定する。PS割り当て部81割り当て手段は、子サイトのDRSからの要求に基づいて、各サブストリームに対して自サイトで割り当てるべきPSのアドレスを決定する。受信装置15は、ドメイン解決応答はPS割り当て部81に、RTT統計値応答は親DRS決定部82にそれぞれ渡す。また、記憶装置9は、ローカルPS記憶部91と、親PSキャッシュ部92と、親DRS記憶部93と、RTT統計行列記憶部94と、RTT統計処理記憶部95と、分配木記憶部96と、からなる。上記ローカルPS記憶部91は、自サイトにあるPSのアドレスと、タイムアウト回数と、状態の組合せからなるエントリを格納している。親PSキャッシュ部92は、親DRSから解決応答として受取ったFドメインと親PSアドレスとの組合せを含むエントリをテーブルとして持つ。親DRS記憶部93は、親DRS決定部82が算出した、オリジンサイトをルートとする有向分配木において、自分に対する親サイトのDRSのアドレスとその状態を記憶する。また、この親DRS記憶部93内のTTLは、この情報が有効である残り時間を示し、この値は時間経過とともに小さくなる。このテーブルの特徴は、HTTPリクエストの転送先ではなく、ドメイン解決のための転送先が書いてあることである。また、通常のシステムでは、URIによらず共通の親PSを割当てていたが、本発明で割当てる親DRSは、オリジンサイト毎に異なる。ローカルPS記憶部93は、ローカルサイト内に設置されている各PSのアドレスと、その状態が格納されている。RTT行列記憶部94は、サイトiからサイトjへのRTTを所定の回数の測定した結果から得られる統計値が行列状に格納されている。ここで、他のサイトから自サイトへのRTT統計値は、RTT統計値応答に対して受信したRTT統計値応答内に記載された値を、また自サイトから他サイトへ測定した値は自サイトのRTT統計記憶部95内のテーブルにあるRTTの最小値図5参照を、それぞれRTT行列記憶部94の対応するエントリにコピーしたものである。ここで、図4は、親DRS記憶部93のテーブル構成を示す図である。このテーブルは、Oドメインと、オリジンサイトのDRSのアドレスと、親サイトのDRSのアドレスと、親サイトのDRSの状態と、からなる。また、図5は、DRSiにおけるRTT統計記憶部94のテーブル構成を示す図である。自分以外の他の全てのサイトに関するN-1個のエントリをもつ。DRSjに対するエントリは、DRSjのアドレスと、過去M回分のRTTの測定値TjMTj1と、それらの最小値minと、DRSの状態の組合せとなっている。新たな測定値を得たら、M個あるRTTの過去の測定値を左側にシフトさせて、TjMは削除し、一番右の空いたTi1のところに最新の測定値を書くとともに、過去M回分のRTTの最小値を更新する。この処理自体は、親DRS決定部82が行う。[親DRS決定部の動作]次に、上述したシステムの動作を説明する。はじめに、図6a、図6bを参照して、親DRS決定部82の動作について説明する。図6aは、他サイトのDRSへのRTT統計値要求の送信に対するRTT統計値応答の受信により、自サイトからその他サイトへのRTTの測定を同時に行いつつ、RTT統計値が変動した場合は分配木を再構成する動作を示している。なお、非特許文献1にもあるように、分配木は各サイト間のスループットを全て最大化させるためのものである。まず、ステップS61で、各サイト101等の親DRS決定部82は、RTT統計値要求を定期的に他の全てのサイト102等のDRS302等へ送信する。この間隔は、予め設定された任意の間隔であるが、例えば、15-30分である。このときタイムアウト回数Nは0にしておく。ここで、RTT統計値要求は、下記のURIをもつHTTPリクエストとする。httpRTTstatistics続いて、ステップS62で、RTT統計値要求を送った他のサイト102等のDRSjから、RTT統計値のベクトル...ただし、TkはDRSjからDRSkに対して測ったRTTの統計値を含むRTT統計値応答がタイムアウトせずに戻ってきたら、RTTの測定値要求を送ってから応答が届くまでの時間をRTT統計記憶部95に書き込んで、統計値を更新し、その更新値でさらにRTT行列記憶部94を更新する。なお、RTT統計値応答は、上記RTT統計値のベクトルをXMLで記述したものを用いてもよい。タイムアウトした場合は、Nをインクリメントし、もう一度要求を送る。これを繰り返して、Nが所定値例えば3を超えた場合は、使用不可という状態をRTT統計記憶部95の状態のところに書き込む。また、RTT行列記憶部94では、使用不可を書き込む。そして、RTT統計値応答メッセージ内にある、応答のあったサイトから他の全てのサイトに対して得られたRTT統計値を、RTT行列記憶部94に書き込む。この動作はRTT統計値要求を出した他のすべてのサイトに関して行う。次に、ステップ63で、RTT行列記憶部94を参照して、各サイトがオリジンサイトとなる最適分配木を算出する。そして、分配木記憶部96を参照して分配木に変更があるOドメインがある場合は、そのOドメインに対する親サイトのDRSを抽出して、親DRS記憶部93を更新し、親PSキャッシュ部92において、変更のあった分配木に対応する部分Oドメインで識別をクリアし、更にローカルPSのアドレスキャッシュにおいて、該当Oドメインを含む全てのBURIのエントリを管理手順で強制的にクリアして、ステップ61に飛ぶ。これらのクリアを行うのは、分配木の再構成があった場合に、上記各テーブルの更新をTTLに頼るのではなく、直ちに再構成が反映されるようにするためである。なお、上述したように親DRS親ドメイン解決サーバを特定する方法は、例えば、構成された有向分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトのDRSを、親DRSとして特定する。ステップ63においては、各サイトのDRSは、予め他の全てのサイトのDRSのアドレスを知っているものとする。これは、例えばシステム全体をつかさどる管理システムが、サイトの追加もしくは離脱の度に稼動する全てのサイトにDRSのアドレスを通知することで実現する。また、ステップ63において最適な有向分配木を算出する一つの方法として、非特許文献9にあるようなボトルネック帯域が最小のリンクを最大化する方法がある。この方法の目的は各サイト間の転送スループットを最大化することである。ここで、隣接サイト間のRTTと最大ウィンドサイズWが与えられれば、パケットロスがないとした場合の隣接サイト間のリンクeでのスループットはWTeで与えられるので、あるサイト間のパスhでのスループットは、hに含まれるリンクeの集合Ehとすると、そのパス上のボトルネックであるmine∈EhWTeで与えられる。よって各リンクでWは一定であるとすれば、Teをコストとして、最小全域木を作る手順の一つであるプリム法を応用すれば、各サイト間のスループットを最大化できる。証明は、非特許文献10に記述されている方法を参考にすれば導かれるがここでは省略する。この手順では部分木に対してノードを追加していくのに、部分木に付加することが可能なリンクのなかでRTT統計行列記憶部の中に格納されているRTT統計値が最小のリンクの先にあるノードを追加していく。なお、ここで仮想リンクとは、サイトAからサイトBへのリンクが物理的なものではなく、インターネットもしくは専用網の転送機能によって実現されているようなものをさす。ここでの分配木を作る手順は、ノード数N、有向リンク数NN-1のフルメッシュな有向グラフから、最適な有向分配木を抽出することであるともいえる。また、ステップ63において、最適な有向分配木を算出するもう一つの方法として、ダイクストラのアルゴリズムがある。ただし、サイトiからサイトjへのエッジのコストにはRTT統計値を付与する。なぜなら各エッジサイトからオリジンサイトでのリンク上でのRTTの総和を最小にする最短パスツリーを算出したいからである。これは、サイト内でのドメイン解決の時間を無視すれば、クライアントがエッジサイトに取得したいファイルに関して最初にHTTPリクエストを出してから、エッジサイトが初めてHTTPレスポンスを受信するまでの時間を概算するものである。このいわゆるスタートアップ時間は、各エッジサイトからオリジンサイトまでの方向のパス上の各サイト間の仮想リンクでのRTT統計値の総和の2倍で与えられる。例えば、後述する図10においては、S5,S6,S8、S10,S11,S13,S15,S16,S18,S23,S24,S25で関る仮想リンクのRTT統計値の総和を取ったものに相当する。また、図6bは、他のサイトのDRSからRTT統計値要求を受けた場合の処理である。ステップS65でRTT統計値要求を他サイトのDRSより受信したら、ステップS66でRTT統計記憶部95に記憶されている各リモートDRSに関するRTT統計値を、RTT統計値応答に載せて要求してきたDRSに送信して終了する。[PS割当て部の動作]次に、図7a、図7bを参照して、DRS302のPS割当て部81の動作について説明する。図7aは、PS割り当て部81におけるドメイン解決の動作を示すものである。ドメイン解決に関するメッセージは、1クライアントもしくは子サイトのDRS、2ローカルPS、および、3親サイトのDRS、とやり取りするが、それぞれに対して手順が以下のようになる。まず、ステップS71で、クライアントもしくは自サイトプロキシからFドメインに対する親PSのドメイン解決要求があると、ステップS72で、1Fドメインに自分と同じOドメインを含む場合は、ドメイン解決応答でOGSのアドレスを返す。2Fドメインに自分と同じOドメインを含まない場合であり、対応エントリが親PSキャッシュ部92にある場合は、そのドメイン解決応答する。3対応エントリが無い場合は、親DRS記憶部93を参照して当該Oドメインに対応する親DRSに対してFドメインの親PSアドレスの解決を要求する。また、ステップS73で、親サイトのDRSからドメイン解決応答があったら、ステップS74で、Fドメインに対して割当てられたPSのアドレスを親PSキャッシュ部92にキャッシュし、解決要求していたローカルPSに対して割当てられたアドレスで応答する。また、ステップS75で、子サイトのDRSからFドメインに対するドメイン解決要求があったら、ステップS76で、ローカルPS記憶部91を参照してロバストハッシングによりFドメインに対応するPSアドレスを決定し、解決要求してきた子DRSにそのアドレスを応答して終了する。図7bは、PS割当て部81におけるローカルPSの監視動作を示すものである。ステップS77で、前回の監視動作から一定時間経過後、タイムアウト回数Nを0にして、ローカルPS記憶部91にある各PSアドレスに向けてpingを送信する。ステップS78で、1タイムアウトせずに戻ってきた場合は、そのPSの状態を使用化とする。2タイムアウトした場合は、Nをインクリメントしてpingを再び送信する。そのタイムアウト回数が一定数以上になった場合は、そのPSの状態を使用不可とする。そしてステップB7に戻る。[ステップS76におけるPS割当てアルゴリズム]図7aのステップS76におけるロバストハッシングとしては、非特許文献11、もしくは、特許文献3にある方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているFドメインに別のPSが割当てられるような割合を最小にするためのものである。もし、あるサーバが使用不可になった場合は、そこに転送していた子PSがあらたに子DRSに解決要求をして、それがさらに親DRSに要求をしてくるので、そこに新たに割当てることになる。次に、上述した本発明の第1の実施形態における効果について説明する。本実施形態によると、各サイトをノードにもつ分配木はアプリケーションレベルでのホップ数を制限なしに最適に構成されるので、ホップ数に制限がある場合に比べて、アプリケーションレベルでのスループットをより向上させることができる。つまり、オリジンサイトが異なる毎に最適な分配木を構成するので、オリジンサイトに関らず固定的な分配木を用いる場合比べて、どのサイトからコンテンツを取得しようとしてもよりスループットを向上させることができる。また、分配木は、各サイト間で測ったRTTベースに、オリジンサイトをルートとしてもつ有向グラフとして作成されるので、サイト間の転送状態における非対称性が大きくても例えば、サイトAからBへのRTTとサイトBからAへのRTTの差が大きいこと、スループットをより最適化することができる。そして、自サイトから他サイトへのRTT測定と、他サイトからのRTT統計情報の取得を同時に行うので、非特許文献3にあるようにそれらを別々の手順で行う必要がなくなり、処理量が削減できる。[実施例]次に第1の実施形態におけるさらに具体的な実施例を、図8及び図9を参照して説明する。図8、図9は、親DRS決定部82の動作を示している。図8では、DRS1におけるRTT統計情報の取得、RTT測定とRTT行列の作成の例を示している。ここでは、DRS1が、DRS2DRS3DRS4にそれぞれRTT統計情報要求を送った後、RTT統計情報応答が戻ってくると同時にRTTを測定する。そして、RTT行列記憶部94において、各DRSから応答のあったRTT統計情報は、各DRSが要求側であるエントリに書き込まれる。また、RTTの測定値は、RTT統計記憶部95に書き込まれ、その結果新たに得られるRTT統計値は、自分DRS1が要求側のエントリに書き込まれる。つまり、RTT統計情報要求を送信してから応答があるまでの時間として計測されたRTTの値は、RSS統計記憶部95に格納され、統計値として処理された結果がRTT行列記憶部94に書き込まれる。図9は、RTT行列記憶部94の内容に基づいて、親DRS記憶部93のテーブルを作成する動作例を示している。ここでは、まず、各DRSがオリジンサイトになる有向分配木が4つ作成される。そして、各DRSにおける、オリジンサイト毎の親DRSの対応表は図9に示すようになり、これが親DRSアドレス記憶部93に組み込まれることになる。つまり、構成された有向分配木の転送経路上で隣接するサイトにおいて、ルートにより近い側のサイト、つまり、上流側のサイトのDRSが、親DRS親ドメイン解決サーバとして特定される。次に、図10は、PS割当て部81の動作により、クライアントが要求したデータをオリジンサイトまで取りに行くための連係動作の実施例を示している。まず、クライアントは、取得したいデータのFURIと、データを取得するPSの解決に使用すべき親サイト102のDRS302のアドレスとを、OGS204から取得したメタデータ内に持っており、HTTPリクエストを送信すべきPSのアドレスを得るために、FURIに含まれるFドメインに対するドメイン解決要求をDRS302に送信する。S1。これは、下記のURIを含むHTTPリクエストを用いてもよい。httpPSesf1578site1songtv続いて、DRS302は、それに対してサイト内で割当てるPSをPS502と決定したら、そのアドレスpqr1s1を持ってクライアントに応答するS2。この応答は、下記の情報をXML形式で記述したものを本文に含むHTTPレスポンスでもよい。f1578site1songtvpqr1s1次に、クラアント45は、PS502に対してHTTPリクエストを送信するS3。PS502は、HTTPリクエストを受取ったら、そのURIが示すデータをキャッシュしていないので、ローカルのDRS302に、Fドメインを、HTTPリクエストを転送すべき親PSのアドレスに解決する要求をだすS4。これはDNSプロトコルで行ってもよい。すると、DRS302は、該当するFドメインに対して親PSアドレスのキャッシュを持っていないので、親DRS記憶部93を参照して、Oドメインに対応する親DRSであるDRS301にFドメインの解決要求を出すS5。これは下記のURIを含むHTTPリクエストを用いてもよい。httpPSesf1578site1songtvするとDRS301は、PS505を割当てて、そのアドレスpqr2s2でDRS302に解決応答するS6。この応答は下記の情報をXML形式で記述したものを本文に含むHTTPレスポンスでもよい。f1578site1songtvpqr2s2このように指定したURIに対して、そのリソースの状態をXMLファイルで応答するWebサービスはRESTfulと呼ばれる非特許文献7。その応答を受取ったDRS302は、S4で解決要求をしていたPS502に解決応答するS7。S4での解決要求がDNSプロトコルで行われた場合は、S7の解決応答もDNSプロトコルで行われる。同様の手順をオリジンサイト104まで繰り返すと、HTTPリクエストはORG204まで転送されるS21。これに対してORG204は、FURIで指定されたデータをHTTPレスポンスで同一サイト内のPS512に返送するS22。これはさらに、PS507、PS505、PS502と転送されS23,S24,S25、最後にクライアント45に届くS26。図11は、特にアクセス頻度の高いデータをオリジンサイトから予め各サイトに配置しておくための一連の動作の実施例を示している。まず、オリジンサイト104のDRSは、その分配木上のリーフサイトであるサイト102のDRSに、配置したいコンテンツのURIにPSを割当てるようドメイン解決要求を出すT1。ここでリーフサイトとは、有向分配木において、さらに転送先のサイトがない一番先端のサイトを指す。そして、サイト102のDRSから解決応答が戻ってくるとT2、割当てられたPSに対して、そのコンテンツに対するURIに対してHTTPリクエストを出すように駆動するT3。これにより、サイト102内のPSは、HTTPリクエストを次に転送すべきサイト101内のPSに転送するT4。より詳細な手順は、図10と同じなので省略する。同様にして、HTTPリクエストは、T5,T6のように分配木上のサイト102からオリジンサイト104まで転送される。そして、これに基づいてオリジンサイト104から配置したいデータが、サイト103,101を経由してサイト102に届くT7,T8,T9。サイト103、101内のPSはデータを中継すると同時に本来のPSの機能としてこのデータをそれぞれ格納する。これにより、リーフサイトから要求を上げていくだけで、ノンリーフサイトにはオリジンサイトからデータが転送されるときにキャッシュされる。よって、オリジンサイトから他の全てのサイトにHTTPリクエストを出すように指令する必要がない。また、エッジサイトからHTTPリクエスト/レスポンスでデータを取ってくるのと同じ仕組みでデータ配置ができ、PSやDRSに新たにオリジンサイトから各サイトへのプッシュ型配信のための手段を組込むための付加的なコストがかからなくてすむ。また、上記システムによると、転送すべきコンテンツのデータのみならず、転送のためのオーバレイネットワークの制御に用いるデータもHTTPリクエストとXMLファイルを含むHTTPレスポンスを用いて転送することで、使用するプロトコルがHTTPに統一できるので、コンテンツ分配配信のためのオーバレイネットワークの運用が簡素化される。また制御に用いるHTTPレスポンスはXML形式で記述することができるので、機能拡張が柔軟にできるようになる。<実施形態2>次に、本発明の第2の実施の形態について、図12乃至図15を参照して説明する。ここでは、上述した第1の実施形態とは異なり、各DRSにおける親DRSの解決は、全てオリジンサイトのDRSが行う、という構成を採っている。図12は、DRSの構成を示すブロック図である。この図に示すように、本実施形態におけるDRSは、データ処理装置8のみが図5と異なり、PS割当て部81と、分配木算出部82と、を備えている。そして、分配木記憶部96には、分配木算出部83を用いて決定した、自サイトがルートとなる分配木に基づいて、自サイトを除いた各サイトとその親サイトとの組合せのエントリが記憶される。次に、第2の実施形態の動作について説明する。図13は、分配木算出部83で自分がルートの分配木を作成するための動作を示す流れ図である。ステップS61、S62は、実施形態1で説明した図6aと同じである。ステップS63’は、図6aのステップS63とは異なり、自サイトがオリジンサイトとなる有向分配木のみを算出する。そして、分配木記憶部96を参照して、あらたに算出された分配木の構成が変わった場合は、分配木記憶部96を更新し、そこから親DRSに変更のあった他のサイトを割り出して、変更がある全てのサイトのDRSに新しい親DRSを通知してステップS61に戻る。この通知は、HTTPPUTリクエストを用いて行ってもよい。なお、分配木算出部83が他のサイトからのRTT統計値要求に対して行う動作は、図6bと同じなので、その説明は省略する。図14は、PS割当て部81の自サイト内のドメイン解決に関する動作を示すフローチャートである。ここでは、図7aに追加する機能についてのみ説明する。ステップS79で、あるオリジンサイトのDRSから親DRSの変更があったら、ステップS80で、親DRS記憶部93を更新し、親PSキャッシュ部92で、オリジンサイトのDRSに対応するOドメイン親DRS記憶部を参照すればわかるを含む全Fドメインのエントリをクリアし、ローカルPSのアドレスキャッシュにおいて、当該Oドメインを含む全てのBURIのエントリを管理手順で強制クリアする。これらのクリアを行うのは、分配木の再構成があった場合に、上記各テーブルの更新をTTLに頼るのではなく、直ちに再構成が反映されるようにするためである。上記に加えて、図7bと同じローカルPSの監視動作を行う。以上説明した第2の実施形態の構成によると、各DRSは、自らがルートとなる分配木のみを算出して、その再構成後に更新のあった親DRSを他の全てのDRSに通知する。よって、各サイトのDRSが独立に親DRSテーブルを作成する分散型の第1の実施形態に比べて、次の効果がある。ひとつは、各DRSが持つ親DRSテーブルの内容が一致しないことでHTTP転送パスの最適性が失われる時間を削減することができる。最適性が失われたことの端的な例としては、分配木の再構成の前後でパスが変化したために、HTTPリクエストが再び同じPSに戻ってくることも起こりうる。これはPSが自分のアドレスをXForwardedForヘッダ内に記載されていることを見つければ、検出することができる。また、上述した第1の実施形態では、各サイトのDRSが各DRSのサイトがルートとなる分配木をすべて算出する必要があるのに対して、この第2の実施形態では、自分がルートとなる分配木だけ算出すればよいので、計算量が削減できる。次に、図15を参照して、第2の実施形態に関する実施例を説明する。ここでは、実施形態1で説明した図10の場合とは異なり、オリジンサイトのDRS304は、分配木が変更されたら親DRSの変わった各DRSに対して、Oドメインと親DRSの組合せを通知する。ここでは、U1,U2,U3で、DRS302,DRS301,DRS303に、親DRSを通知している。なお、他の動作は図10と同じであるため、その詳細な説明は省略する。<実施形態3>次に、本発明の第3の実施形態を説明する。ここでは、第1、2の実施形態で設定された最適分配木による経路上において、スループットをより向上させるために、予めORGでファイルを分割してできたブロックのデータを、サイト間で並列に転送する点に特徴を有する。ただし、ブロック毎ではなく、並列転送されるサブストリーム単位でドメイン解決をすることで、制御負荷を削減する。[オリジンサーバOGS]図16に示すように、本実施形態におけるオリジンサーバOGS2は、送信装置12、受信装置13、処理装置10、記憶装置7からなる。処理装置10コンテンツ配信手段は、プログラムが組み込まれることで構築された、発行処理部1001と、Webサーバ処理部1002と、クライアント処理部1003と、を備える。Webサーバ処理部1002は、クライアントから受信したHTTPリクエストに対して、コンテンツのデータを送信したり、格納してあるデータをHTMLデータに作り上げてそれをHTTPで送り出したりする機能を有する。特に、本実施形態では、後述するように、経路上の同一のサイトに設置された複数のPSに対して、コンテンツを分割したブロック群からなるサブストリームデータを、クライアントに対して並列配信する。発行処理部1001は、取得したデータに対してURIを付与変換する等の加工アプリケーションにより実現される。クライアント処理部1003は、Webサーバ処理部1002からクライアントからのメタデータ要求を受取ったら、対応するメタデータを取り出し、クライアントのIPアドレスに基づいて地理データ記憶部73を参照して、最寄りのエッジサイトのDRSを決定し、メタデータに書き加えて、Webサーバ処理部1002に渡す。記憶装置7は、ブロック記憶部71と、メタデータ記憶部72と、地理データ記憶部73と、からなる。ブロック記憶部71は、アップロードされたコンテンツのデータを記憶する。メタデータ記憶部72には、O-URIやパラメトリック表現したBURIや発行者が付与したメタデータが記憶される。地理データ記憶部73には、各サイトのDRSのアドレスと、それが対応するIPアドレスの範囲が格納されている。なお、記憶装置7は、例えば比較的容量の大きいストレージサーバ等で実現される。次に、図17aを用いてORGの発行処理部71における動作について詳しく説明する。まず、ステップS171で、Webサーバ処理部1002からアップリードされたデータを渡されたら、ステップS172でファイルを1つもしくは複数のブロックに分割して、それぞれにURIをつけ、ブロック記憶部71に格納する。その後、ステップS173で、メタデータを生成して、発行者からのメタデータと統合して、新たなメタデータを作り、URIを付与して対応したメタデータ記憶部72に格納する。次に、ステップS127でブロック毎につけるURIについて説明する。まず、各ブロックは必ずしも同じサイズである必要はない。そして、各ブロックを並列転送する際、同一PS間のHTTPコネクション上を転送されるブロックの集合をサブストリームデータと呼ぶことにする。すなわち、並列転送とは、それぞれがコンテンツを分割した複数のブロック分割データを含む各サブストリームを複数、同時に転送していることといえる。ただし、クライアントで受信後に直ちにビデオ再生できるようにするために、各ブロックは、巡回的に異なるサブストリームに属するようにする。すなわち、サブストリームの総数をZとすると、ブロックIDに対するサブストリームIDは、次で与える。1modZ1つまり、各ブロックに、コンテンツが再生される順番に対応した識別番号であるブロックIDが付与されている場合には、ブロックID実際には、ブロックID1をサブストリームの総数Zで割り、その余りの値実際には、余りの値1を、当該ブロックが配置されるサブストリームのIDとする。このとき、各サブストリームには、ブロックIDが小さい順に先頭から配置することで、コンテンツ上における再生順序が早い順に、各ブロックが各サブストリームの先頭側から分散して配置される。これにより、各サブストリームが並列転送されても、コンテンツの先頭から配信することができる。そして、サブストリーム単位でPSを割当てるようなドメイン解決をPSが行うことができるように、次に示すようなURIの変換を行う。なお、サブストリームの総数は、予めZ=3と与えられているものとする。また、ORGここではsite1で識別されるにおいて、アップロード直後番組ファイル毎に付与されるURIこれをOURIと呼ぶことにするは、次のような構造をもつものとする。OURI:httpwwwsite1songnetvideocastchannel3item2ここで、songnetはこの配信サービスを提供する主体を示し、site1はこのコンテンツが発行者からアップロードされた先であるオリジンサイトを示し、wwwはオリジンサーバとしてのホスト名を示している。配信サービス提供主体がN個のサイトを運営している場合、例えば各サイトをsite1...siteNと示す。また、パスの部分において、videocastはコンテンツ提供サービスの名称を、channel3は個別のチャンネルを、item2は個別の配信プログラムをそれぞれ示している。このファイルをセグメント化して得られるブロックに付与するURIは、OURIの再後尾にブロック番号を示すものを加えて、BURIと呼ぶことにする。BURI:httpwwwsite1songnetvideocastchannel3item2block6なお、背景技術のところでも記述したように、非特許文献1でも、BURI相当のものを含むHTTPリクエストを中継経路上のPSに転送するが、BURIを付与するのは本発明ではOGSであるのに対して、上記非特許文献ではOURI相当を含むHTTPリクエストをクライアントから最初に転送されたプロキシが行う。次にBURIは、PSが同一アイテム内のブロックから複数構成されるサブストリーム単位でプロキシサーバを割り当てることができるように、以下のように変換される。すなわち、1まずOURIをハッシュしてこの値をここでは1578とする、それにfをつけたf1578をもうけ、次にサブストリーム数3にzをつけたz3と一緒にしてz3f1578というドメインを作る。2次にブロックIDの6に対するサブストリームIDの2とサブストリーム総数3に対して、s2というドメイン作る。3最後に、上記を結合したs2z3f1578というドメインを、最初のBURIのwwwと入れ替える。すると変換後のBURIは次のようになる。https2z3f1578site1songnetvideocastchannel3item2block6ここで、z3f1578site1songnetのように同一ファイルに対応するドメインをFドメインと呼び、s2z3f1578site1songnetのように同一ファイルの異なるサブストリームに対応するドメインをSドメインと呼ぶことにする。なお、もしクライアントもしくはPSが既存のものとは違って、URI毎にドメイン解決を要求できる場合は、f1578の部分は不要になる。上記のように変換されたURIはユーザが目的のファイルを取得する際に用いるメタデータに書き込まれ、メタデータ記憶部72に格納される。なお、上記の変換でz3という記号を挿入したのは、転送先のPSに関するドメイン解決要求を親サイトのDRSに送る際に、同一Fドメインに対応する3つの全てのSドメインのそれぞれについて解決要求のメッセージを送るのではなく、最初にいずれかのSドメインに関するドメイン解決要求がローカルなPSからあったら、FドメインについてPS割当てのためのドメイン解決要求をする。これは、例えば次に示すURIをもつHTTPリクエストで行うことができる。httpPSesFdomainz3f1578site1songnetこれを受信した親DRSは、z3から直ちに3つのSドメインを再生して、それぞれにPSを割当てることができる。この3つの組合せは例えば次のように表現できる。s1z3f1578site1songtvvwxy1s2z3f1578site1songtvvwxy2s3z3f1578site1songtvvwxy3上記の情報はXML形式で記述して親DRSへのHTTPレスポンスに含めることができる。そしてこのような指定したURIに対して、そのリソースの状態をXMLファイルで応答するWebサービスはRESTfulと呼ばれる非特許文献7。ここで、逐次再生が必要でなく、単純にファイル全体を並列に転送したい場合は、例えばファイル全体を3つのブロックにわけ、変換されたBURIとしてはhttps1z3f1578site1songnetvideocastchannel3item2block1https2z3f1578site1songnetvideocastchannel3item2block2https3z3f1578site1songnetvideocastchannel3item2block3というように、サブストリームIDとブロックIDが1対1のBURIをサブストリーム総数だけ準備すれば十分である。次に、ステップS173でのメタデータについて説明する。OGSは、次のようなメタデータを作ってメタデータ記憶部72に格納する。これはクライアントからOURIを含むHTTPリクエストでアクセスされる。O-URIhttpwwwsite1songnetvideocastchannel3item2エッジサイトDRSのアドレス2914723412、2914723413サブストリーム1内のBURI群:https1z3f1578site1songnetvideocastchannel3item2blockn01000サブストリーム2内のBURI群:https2z3f1578site1songnetvideocastchannel3item2blockn0...1000サブストリーム3内のBURI群:https3z3f1578site1songnetvideocastchannel3item2blockn0...1000上記において、ここで番組ファイルを組み立てるために取得すべきブロックに関するBURIをそのまま全て書き下すとブロック総数が多い場合に情報量が肥大するので、それを防ぐために、サブストリーム毎にパラメトリックな表現を用いている。また、クライアントを誘導すべきエッジサイトのDRSのアドレスは、クライアントがメタデータを要求してきた時点そのクライアントのIPアドレス等に基づいて決定される。ここではDRSの障害を考慮して、決定された最適なエッジサイトにおけるDRSのアドレスが2つ記載されている。次に、図17bを用いてクライアント処理部1003の動作について説明する。ステップS175で、Webサーバ処理部1002からメタデータ要求メッセージを渡されたら、ステップS176で、地理データ記憶部73とクライアントIPアドレスを参照して、誘導先のエッジサイトのDRSアドレスを決定し、ステップS177で要求OURIに対応するBURI群や発行者が記述したメタデータをメタデータ記憶部から取り出して、DRSアドレスを更に書き加えて、Webサーバ処理部1002に渡して終了する。[ドメイン解決サーバDRS]DRSの構成は、第1の実施形態にあるように、分配木の再構成を分散的に行う場合は図5と同じであり、第2の実施形態にあるように分配木の再構成を集中的に行う場合は、図12と同じである。ここで、図18に、DRSが有する親PSキャッシュ部のテーブル構成を示す。第1、第2の実施形態では、Fドメインと親PSアドレスの組合せを含むエントリを持つのに対して、本実施形態では、同一Fドメインに対する各Sドメインと親PSアドレスの組合せを含むエントリをもつ。次にDRSの動作について説明する。第1の実施形態にあるように、分配木の再構成を分散的に行う場合は、親DRS決定部の動作は図6と同じである。また、第2の実施形態にあるように分配木の再構成を集中的に行う場合は、分配木算出部の動作も図13と同じである。具体的に、図19a,b,cを用いて、分配木の再構成を分散的に行う場合の、PS割当て部81の動作について説明する。図19aは、クライアントもしくはローカルPSからSドメインに対するドメイン解決要求があったときの動作を示すフローチャートである。ステップS191で、クライアントFドメインから親PSアドレスへの解決要求あったら、ステップS192で、各Sドメインに対して、1親PSキャッシュ部にあるアドレスを応答、2ない場合は全Sドメインに対してローカルPSを割当てて、応答する。ステップS193で、ローカルPSからSドメインに対する親PSアドレスの解決要求あったら、ステップS194で、1Sドメインに自分と同じOドメインを含む場合は、アドレス解決応答でOGSのアドレスを返す。2含まない場合は、親PSキャッシュ部にあるアドレスを応答し、3ない場合は親DRS記憶部を参照して、Oドメインに対応する親DRSに、Fドメインから親PSアドレスへの解決要求を送る。ここで、ローカルPSからのドメイン解決要求と応答は、既存のDNSプロトコルを用いて行われる。図19bは、PS割当て部81において、親サイトのDRSからのドメイン解決応答があった、もしくは子サイトのDRSから全てのSドメインに対するドメイン解決要求があった場合のときの動作を示すフローチャートである。ステップS195で、親サイトのDRSからドメイン解決応答があったら、ステップS196で、Sドメインに対して割当てられたPSのアドレスを親PSキャッシュ部にキャッシュし、解決要求していたローカルPSに対して割当てられたアドレスで応答する。ステップS197で、子サイトのDRSから全てのSドメインに対するドメイン解決要求があったら、ステップS198で、ローカルPS記憶部を参照してロバストハッシングにより各Sドメインに対応するPSアドレス群を決定し、解決要求してきた子DRSにそのアドレスを応答して終了する。なお、上記ステップS198におけるロバストハッシングとしては、非特許文献11もしくは特許文献3の方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているSドメインに別のPSが割当てられるような割合を最小にするためのものである。図19cは、PS割当て部81におけるローカルPSの監視動作を示すものである。ステップS199で、前回の監視動作から一定時間経過後、タイムアウト回数Nを0にして、ローカルPS記憶部にある各PSアドレスに向けてpingを送信する。ステップS200でタイムアウトせずに戻ってきた場合は、そのPSの状態を使用化とする。タイムアウトした場合はNをインクリメントしてpingを再び送信する。そのタイムアウト回数が一定数以上になった場合は、そのPSの状態を使用不可とする。そしてステップS199に戻る。[プロキシサーバPS]次に、本実施形態におけるプロキシサーバPSについて説明する。各サブストリームは個別のドメイン名を持っているので、ローカルサイトの各PSは、ローカルサイトのDRSを使って、サブストリーム単位で親サイトのPSアドレスを解決させる。次に、解決された親PSのアドレスに対して単一のHTTPパーシステントコネクションを設定して、同じサブストリーム内の各ブロックについて、その同一コネクション上をパイプライン形式で、すなわちB-URIでのブロック番号が大きくなる順番で連続してHTTPリクエストを出し、HTTPレスポンスでブロックのデータを取得する。ここでは上述のメタデータに含まれる異なるURIすなわちブロック単位でHTTPコネクションを設定することはしない。パーシステントコネクションおよびパイプライニングについては非特許文献12に記載がある。[クライアント]次に、本実施形態におけるクライアントについて説明する。図20に示すように、クライアント41は、送信装置22と受信装置23とデータ処理装置24と記憶装置11と入力装置25と出力装置21とからからなる。ここで、入力装置25および出力装置21は、ユーザが使うものであり、例えばそれぞれキーボード、液晶ディスプレイである。データ処理装置24は、再生処理部2402と、表示処理部2401と、背景処理部2403とからなる。表示処理部2401は、ユーザの入力装置25からの入力信号に基づいて表示を変更し、また再生処理部2402から受取ったデータを処理して出力装置21に渡す。背景処理部2403は、送受信装置を通じて表示処理部2401からの指示でデータの送受信を行う。そのために、エッジサイトのDRSとの間でドメイン解決も行う。なお、背景処理部2403と表示処理部2401は、Webブラウザの主要な機能に含まれる。再生処理部2402は、背景処理部2403から再生開始の支持があったら、ブロック記憶部1101からブロックを順番に取り出し、ビデオであれば復号化を行って出力装置21に表示する。なお、記憶装置11は、ブロック記憶部1101とメタデータ記憶部1102とからなる。次に、クライアントの動作について説明する。まず、出力装置21で示されているWeb画面上に示された番組アイテムへのリンクに関して、入力装置25からそのリンクがクリックされた信号が表示処理手段に伝わると、メタデータの要求をORGに送る。その後表示処理部2401は、OGSからメタデータを取得すると、それをメタデータ記憶部1102に格納し、背景処理部2403にコンテンツ取得の指示をだす。図21は、クライアントの背景処理部2403のその後の動作を説明するためのフローチャートである。ステップS211で、表示処理部2401からコンテンツデータ取得指示を受けたら、ステップS212で、メタデータ記憶部1102からメタデータを取り出して、メタデータのファイル内に記載されたパラメトリックなURI群における全てのSドメインに対してまとめてPSのドメイン解決を行う。ステップS213で、ドメイン解決された各PSにパーシステントなHTTPコネクションを設定し、同じサブストリームに属する異なるブロックに対するHTTPリクエストを、パイプライン形式で転送して終了する。ステップS214で、B-URIに関するHTTPレスポンスとしてブロックデータを受信したら、ステップS215で、ブロック記憶部1101に格納する。ステップS216で、取得したブロックがFドメインに関して先頭ブロックである場合は、再生処理部2402に再生開始の指示を行う。本実施形態は、以上のような構成により、ファイルをセグメント化してブロック単位で転送する場合でも、サブストリーム単位でドメイン解決をするので、ブロック単位ここではBURIで識別されるでドメイン解決を行なう場合に比べてドメイン解決に必要となるメッセージ数を削減することができる。さらに、各サブストリームにPSを割当てるためのドメイン解決をまとめて行うので、サブストリーム毎に行う場合に比べてドメイン解決に必要となるメッセージ数を削減することができる。また、クライアントとPS間、経路上の1組のPS間では、サブストリーム単位でパーシステントコネクションが設定されて、同じサブストリームに含まれる各ブロックは一旦設定された同一のパーシステントコネクション上を転送するので、非特許文献1におけるように、PSがブロック単位でHTTPコネクションを設定するのに比べて処理付加や設定遅延を削減することができる。次に、本実施形態における動作を説明する。まず、図22は、ドメイン解決の動作例を示す。クライアントがアクセスするトップページには、メタデータ情報へのリンクが張られている。これはO-URIをもっている。これをクリックすると、OGSよりメタデータ各サブストリーム内のBURIをパラメトリック表現してあると、上述した背景処理部2403を実現するjavascriptプログラムがダウンロードされるT1。ここで、クライアントのWebブラウザにおいて動作するプログラムであるJavascriptについては、非特許文献13に記述がある。次に、クライアントの背景処理部2403は、メタデータに含まれるs1s2s3のドメインについて、メタデータ内に示されているDRS302にまとめてドメイン解決要求すると、それぞれのドメインについて、同一のサイト102内に設置された複数のPS、つまり、PS504505506のアドレスが解決されるT2。次に、それぞれ解決されたアドレスをもつPSに対して、パーシステントコネクションを設定し、各サブストリームに含まれる最初のブロックに相当するURIを含むHTTPリクエストを出すT3,T4,T5。すると、各PSにはキャッシュが無いので、それぞれのPSはローカルDRS302に、それぞれ担当するSドメインについて、親PSのドメイン解決要求を出すT6,T7,T8。次に、DRS302のPS割当て部は、T6,T7,T8のドメイン解決要求のいずれか一つを最初に受取ったタイミングで、親サイトDRS301にFドメインの解決要求を出すT9。これに対して、DRS301がDRS302へ、s1s2s3を含む各ドメインにそれぞれPS501、PS502、PS503のアドレスを応答してきたらT10、PS501PS502PS503にそれぞれ対応するPSのアドレスで解決応答するT11,T12,T13。これらのPSは、受取った親PSに対してパーシステントコネクションを設定し、サブストリームIDであるs1,s2,s3をそれぞれもつB-URIを含むHTTPリクエストをHTTP11のパイプライン形式で送出するT14,T15,T16。なお、クライアントも、PSも、URI変換により同じドメイン名をもつサブストリーム内の各ブロックに対しては、最初にそのドメインに対して割当てるべきPSが解決されたら、以降はブロック毎にドメイン解決することなく、HTTPリクエストを出すことができる。図23は、サブストリームの並列転送状況とサブストリーム内のブロック番号の順番を示す説明図である。この場合サブストリームは3つあり、各サブストリームで転送されるブロックとその順番はs1:block1block4block7s2:block2block5block8s3:block3block6block9となる。オリジンサイト103でst1st2st3に割当てたPSは507508509である。中継サイト101でst1st2st3に割当てたPSは501502503である。エッジサイト102でst1st2st3に割当てたPSは504505506である。クライアント46の内部において背景処理部が各コネクションからラウンドロビンのように受信したブロックは、クライアント内の再生処理部において順番に組み立て再生される。以上のように、本実施形態では、オリジンサイト103が、経路上の同一のサイトに設置された複数のPSに対して、コンテンツを分割したブロック群からなるサブストリームデータを並列配信するため、スループットをより向上させることができる。なお、上記では、実施形態1,2で説明したように、ドメイン解決サーバにて設定した有向分配木に基づく経路に従って、同一サイト上の複数のPSに対して複数のサブストリームデータを並列転送する場合を説明したが、予め設定された経路に従って、同一サイト上の複数のPSに対して、複数のサブストリームデータを並列転送してもよい。<実施形態4>次に、本発明の第4の実施形態について図面を参照して詳細に説明する。本実施形態では、クライアントがブラウザ上から設定できるHTTPコネクション数が限られている場合に、転送網内では、その定数倍のサブストリームを用いて高速転送する、という構成を有している点に特徴を有する。図24は、サイトの構成を説明する図である。第1の実施形態に加えて、あらたにサイト内に変換サーバ中継サーバ2301,2302以下、TSと呼ぶが加わる。この変換サーバ2301,2302は、コネクション設定数に制限のあるクライアントとのデータのやり取りを直接行うと共に、同じサイト内のPSとHTTPコネクションを設定してデータのやり取りをおこなう。これにより、TSはサブストリームの載せ替えを行う。具体的には、PSとの間で、所定のセッション数にてサブストリームデータの送受信を行うと共に、クライアントに対しては、当該クライアントが接続可能なセッション数の上限数の範囲内にサブストリームデータを集約して、クライアントに転送する機能転送手段を有する。ただし、TSはPSと違ってURIで区別できるブロックのキャッシュは行わない。TSとPSには異なるIPアドレスが付与され、DRS302は、送られてきたデータのソースアドレスをみてTSとPSを区別することができるものとする。図25は、DRS302のPS割当て部の動作を示すフローチャートである。ここでは、第3の実施形態と異なる部分について説明する。図19aを変形して次のようになる。ステップS251で、クライアントからFドメインの解決要求がHTTPリクエストとしてあったら、ステップS252で、該当する全SドメインのそれぞれにTSを割当てて、そのアドレスを返す。ただし、異なるTSのアドレスは、クライアントのコネクション設定上限数以下になるようにする。ステップS253で、TSからSドメインの解決要求があったら、ステップS254で、対応するSドメインに割当てたローカルPSがローカルPSキャッシュ部にある場合はそれを応答し、ない場合はロバストハッシングにより全てのSドメインに対してローカルPSを割り当ててそのアドレスを応答する。ステップS255で、ローカルなPSからSドメインに関して解決要求があったら、ステップS256で、12親PSキャッシュ部を参照して応答し、3無い場合は、Oドメインに対応する親DRSに、全てのSドメインに対する親PSのドメイン解決要求をする。TSはPSと同じ動作をするが、PSはHTTPレスポンスが戻って来たらそのデータをキャッシュしてもよいが、TSはキャッシュしない。ステップS256におけるロバストハッシングとしては、非特許文献11もしくは特許文献3の方法に基づいて行う。これは、同じコンテンツが複数のPSに複製されることをなるべく防ぐ一方で、PSが増設もしくは減設されたときに、既存のPSを割当てられているSドメインに別のPSが割当てられるような割合を最小にするためのものである。本実施形態は、以上のように構成することにより、サブストリームを載せ替えるためのTSをPSとクライアントの間に入れるので、クライアントにHTTPコネクション設定数の上限があっても、これとは独立に、分配網内では並列転送するサブストリーム総数を設定してスループットの向上を図ることができる。次に、第4の実施形態における実施例について説明する。図26は、クライアント45、DRS302TS2301,2302、PS501~506の間の連携動作を示す図である。ここではクライアントが終端できるHTTPコネクションが2であるのに対して、転送網内ではサブストリーム総数を6として並列転送を行うようにTSサーバがサブストリームの載せ換えを行う。以下IDがnであるサブストリームをssnと略記することにする。クライアントはコネクション数上限2で、メタデータ内で指定されたDRS302にFドメインの解決を要求すると、ss1ss2ss3にはTS2301のアドレスを、ss4ss5ss6にはTS2302のアドレスで解決応答されてくる。するとクライアントは、TS2301およびTS2302にそれぞれパーシステントコネクションを設定して、ss1ss2ss3およびss4ss5ss6に属するブロックのURIBURIを含むHTTPリクエストをパイプライン形式で送信する。すなわち、TS2301へは、block1block2block3block7block8block9...にそれぞれ対応するBURIを含むHTTPリクエストをその順番でTS2301に送る。また、TS2302にはblock4block5block6block10block11block12...にそれぞれ対応するBURIを含むHTTPリクエストをその順番でTS2302に送る。これらを受取ったTS2301は、ss1ss2ss3の各サブストリームIDを含むB-URIを始めて検出したら、DRS302に各Sドメインの解決要求を転送する。同様にして、TS2302は各Sドメインの解決要求をDRS35に転送する。これらの要求はDNSプロトコルを用いて行われる。そして、DRS302は、ss1ss2ss3に関する各Sドメインの解決要求に対してPS501、PS502、PS502を割当ててTS2301に応答したとする。またDRS302はss4ss5ss6に関する各Sドメインの解決要求に対してPS504、PS505、PS506をそれぞれ割当ててTS2302に応答したとする。するとTS2301はPS501PS502PS503に対してパーシステントコネクションを設定して、各Sドメインに対応するBURIを含むリクエストを対応する各パーシステントコネクション上に転送する。同様に、TS2302は、PS504PS505PS506に対してそれぞれパーシステントコネクションを設定して、各ドメインに対応するBURIを含むリクエストを対応する各パーシステントコネクション上に転送する。PSは自分がデータを保持する場合は、TSにブロックを返すが、無い場合はDRSに親サイトのPSのドメイン解決を要求する。なお、上記各実施形態においてプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。なお、本発明は、日本国にて2010年9月2日に特許出願された特願2010-196417の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。<付記>上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるデータ転送システムの構成の概略を、図27及び図28のブロック図を参照して説明する。また、本発明におけるプログラム、情報処理方法等の構成の概略について説明する。但し、本発明は、以下の構成に限定されない。付記1-1:図27参照コンテンツが蓄積されたオリジンサーバ5010と、要求されたコンテンツを転送する複数のプロキシサーバ5020と、クライアント6000がデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバ5030と、を設置したサイト5000,5100,5200が、ネットワークを介して複数接続されており、前記ドメイン解決サーバ5030が、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段5031と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段5032と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段5033と、を備え、前記経路設定手段5032は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、前記割り当て手段5033は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である親サイトにあるプロキシサーバを自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、データ転送システム。付記1-2付記1-1に記載のデータ転送システムであって、前記計測手段は、各サイトに設置されたドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、データ転送システム。付記1-3付記1-2に記載のデータ転送システムであって、前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前記各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムのうちの最大値が最小となる経路を設定する、データ転送システム。付記1-4付記1-2に記載のデータ転送システムであって、前記計測手段は、前記リンクパラメータとして、前記各サイトにそれぞれ設置された前期各ドメイン解決サーバ間におけるラウンドトリップタイムを計測し、前記経路決定手段は、前記各経路上における各サイト間のラウンドトリップタイムの総和が最小となる経路を設定する、データ転送システム。付記1-5付記1-2乃至1-4のいずれかに記載のデータ転送システムであって、前記ドメイン解決サーバの前記計測手段は、他のドメイン解決サーバに対して、自己であるドメイン解決サーバと他のドメイン解決サーバとの間における前記リンクパラメータを計測すると共に、この計測時に、他のドメイン解決サーバに対して当該他のドメイン解決サーバが既に計測した計測結果を要求して取得する、データ転送システム。付記1-6付記1-1乃至1-5のいずれかに記載のデータ転送システムであって、前記ドメイン解決サーバが備える前記計測手段と前記経路設定手段とは、予め設定されたタイミングで作動して、経路及び親ドメイン解決サーバの設定を行う、データ転送システム。付記1-7付記1-1乃至1-6のいずれかに記載のデータ転送システムであって、前記各サイトの各ドメイン解決サーバが備えた前記経路設定手段は、自サイトの前記オリジンサーバが記憶されているコンテンツを配信する経路を決定すると共に、前記親ドメイン解決サーバを決定して、他のドメイン解決サーバに通知し、前記他のドメイン解決サーバは、それに基づいて親ドメイン解決サーバを設定する、データ転送システム。付記1-8コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバであって、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を備え、前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、ドメイン解決サーバ。付記1-9付記1-8に記載のドメイン解決サーバであって、前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、ドメイン解決サーバ。付記1-10コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバとを設置したサイトが、ネットワークを介して複数接続されている場合における前記ドメイン解決サーバに組み込まれるプログラムであって、前記ドメイン解決サーバに、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測する計測手段と、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定する経路設定手段と、前記ドメインに対応するプロキシサーバを割り当てる割り当て手段と、を実現すると共に、前記経路設定手段は、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、前記割り当て手段は、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、プログラム。付記1-11付記1-10に記載のプログラムであって、前記計測手段は、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、プログラム。付記1-12コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、前記ドメイン解決サーバが、各サイト間における通信状況を表すリンクパラメータをそれぞれ計測し、この計測結果に基づいて各サイトの各オリジンサーバから他の各サイトまでコンテンツを配信する各経路を設定し、前記ドメインに対応するプロキシサーバを割り当てると共に、前記経路設定時に、前記オリジンサーバ毎にそれぞれ設定された経路上において、自ドメイン解決サーバが配置された自サイトよりも上流に隣接する親サイトに設置されたドメイン解決サーバを、自サイトに設置されたドメイン解決サーバに対する親ドメイン解決サーバとして設定し、前記割り当て時に、前記親ドメイン解決サーバに、データ転送先のプロキシサーバへの前記識別子に基づくドメイン解決の要求を行うと共に、当該親ドメイン解決サーバからの応答に従って、自サイトのプロキシサーバがコンテンツ要求を転送すべき先である、親サイトにあるプロキシサーバ、を自サイトのプロキシサーバに通知し、前記クライアントもしくは前記経路上の下流に隣接する子サイトのドメイン解決サーバからの要求に応じて自サイトに複数設置された前記プロキシサーバから必要となるプロキシサーバを割り当て、前記クライアントもしくは子サイトにあるドメイン解決サーバに通知する、データ転送方法。付記1-13付記1-12に記載のデータ転送方法であって、前記リンクパラメータの計測時に、各サイトに設定された各ドメイン解決サーバ間におけるデータの送受信方向を区別した当該各ドメイン解決サーバ間における通信状況を、前記各サイト間における通信状況を表すリンクパラメータとして計測する、データ転送方法。付記2-1:図28参照コンテンツが蓄積されたオリジンサーバ7010と、要求されたコンテンツを転送する複数のプロキシサーバ7020と、クライアント8000がデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバ7030と、を設置したサイト7000,7100,7200が、ネットワークを介して複数接続されており、前記オリジンサーバ7010は、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段7011を備え、前記ドメイン解決サーバ7030は、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段7031を備え、前記割り当て手段7031は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、データ転送システム。付記2-2付記2-1に記載のデータ転送システムであって、前記オリジンサーバが有する前記コンテンツ処理手段は、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、データ転送システム。付記2-3付記2-1又は2-2に記載のデータ転送システムであって、前記オリジンサーバが有する前記コンテンツ処理手段は、前記サブストリームの総数を含む前記識別子を、前記ブロックに付与する、データ転送システム。付記2-4付記2-1乃至2-3のいずれかに記載のデータ転送システムであって、前記クライアントがアクセスしたエッジサイトにおいて、前記クライアントと前記プロキシサーバとの間に、前記コンテンツを転送する中継サーバを備え、前記ドメイン解決サーバの割り当て手段は、前記クライアントのドメイン解決要求に対して、前記クライアントが設定可能なコネクション数の上限以内の中継サーバを割当てる、データ転送システム。付記2-5コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバであって、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を備え、前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、オリジンサーバ。付記2-6付記2-5に記載のオリジンサーバであって、前記コンテンツ処理手段は、サブストリームの総数を含む前記識別子を、前記ブロックに付与する、オリジンサーバ。付記2-7コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記オリジンサーバに組み込まれるプログラムであって、前記オリジンサーバに、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与するコンテンツ処理手段を実現させると共に、前記コンテンツ処理手段は、前記各ブロックに、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームに対応するドメインを含む識別子を付与する、プログラム。付記2-8コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバであって、前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を備え、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、ドメイン解決サーバ。付記2-9コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおける前記ドメイン解決サーバに組み込まれるプログラムであって、前記オリジンサーバにて、コンテンツを分割してできるブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子が付与されており、前記ドメイン解決サーバに、前記サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定する割り当て手段を実現すると共に、前記割り当て手段は、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームに対応するドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの所与の経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求において、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、プログラム。付記2-10コンテンツが蓄積されたオリジンサーバと、要求されたコンテンツを転送する複数のプロキシサーバと、クライアントがデータを要求するための識別子に含まれるドメインを前記プロキシサーバに解決するドメイン解決サーバと、を設置したサイトが、ネットワークを介して複数接続されているデータ転送システムにおけるデータ転送方法であって、前記オリジンサーバが、コンテンツを分割してできるブロックの単位で保持し、前記ブロックに、当該ブロックが1つもしくは複数含まれる各サブストリームを識別するドメインを含む識別子を付与し、前記ドメイン解決サーバが、前記各サブストリームを識別するドメイン毎に割当てるべきプロキシサーバを決定し、前記ドメイン解決サーバによるプロキシサーバの割り当て時に、自ドメイン解決サーバが配置された自サイトの前記プロキシサーバから一つのサブストリームのドメインを、前記オリジンサーバのあるサイトからクライアントがアクセスしたエッジサイトまでの経路上で、上流側に隣接する親サイトのプロキシサーバに解決する要求をするときに、親サイトのドメイン解決サーバに、前記一つのサブストリームの元となるコンテンツを構成する全てのサブストリームの各々に対して前記親サイトにあるプロキシサーバを割り当てるためのドメイン解決要求を行う、データ転送方法。付記2-11付記2-10に記載のデータ転送方法であって、前記オリジンサーバが前記ブロックに識別子を付与するときに、前記各ブロックには、当該各ブロックの元となるコンテンツが再生される順番に対応した識別番号を付与すると共に、前記分割データの識別番号を前記サブストリームの総数で割った余りの値が等しいブロックには、同一の前記サブストリームのドメインを含む識別子を付与する、データ転送方法。"