サーバ-クライアント協調型 P2Pコンテンツ配信ネットワークシステムの

信学技報
IEICE Technical Report
社団法人電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS
サーバ-クライアント協調型
P2P コンテンツ配信ネットワークシステムの検討および実装
辻
智博†
金子三紀雄†
荒川
豊†
岡本
聡†
山中直明†
† 慶應義塾大学理工学部情報工学科〒 223–8522 神奈川県横浜市港北区日吉 3–14–1
E-mail: †[email protected]
あらまし
マルチメディアコンテンツを高速に伝送するネットワークとして，CDN(Contents Delivery Network) が
注目されているが，HDTV(High Definition TeleVision) をはじめとするリッチコンテンツに対するダウンロード遅延
を削減するには至っていない．そこで，P2P(Peer-to-Peer) の技術を CDN に応用し，サーバのみではなくコンテンツ
のダウンロードが終わったクライアントもダウンロード先の候補とし，候補リストの中で RTT(Round Trip Time) が
最短のクライアントからコンテンツのダウンロードを行うネットワークの実装を行った．しかし，この方式ではコン
テンツを要求するクライアント側のみによる RTT 測定でダウンロード先の選択を行っているため，常に RTT が最短
のダウンロード先にアクセスが集中してしまい結果的に全クライアントへのコンテンツ配信時間に影響が出てしまう
という問題があった．そこで，本稿ではダウンロード先候補の適応的絞り込みと，各候補への最大コネクション数を
制限することにより，更なる負荷分散を図ったサーバ-クライアント協調型 P2P コンテンツ配信ネットワークシステ
ムを提案する．計算機シミュレーションにより特性評価を行い，RTT のみを考慮した従来プロトタイプシステムと比
較して提案方式における全クライアントへのコンテンツ配信時間を最大 40%改善できることを示す．
キーワード
コンテンツ配信ネットワーク，P2P，High definition TV
Study and Implementation on P2P based Contents Delivery Network
System using Cooperation of Server and Clients
Tomohiro TSUJI† , Mikio KANEKO† , Yutaka ARAKAWA† , Satoru OKAMOTO† , and Naoaki
YAMANAKA†
† Dept. of Information and Computer Science, Faculty of Science and Technology, Keio University Hiyoshi
3–14–1, Kohoku-ku, Yokohama, 223–8522 Japan
E-mail: †[email protected]
Abstract Although CDN(Contents Delivery Network) is the remarkable network to transmit multimedia contents
fast, it could not reduce the download time for rich contents such as HDTV(High Definition TeleVision). So, we
implemented the P2P based Contents Delivery Network System that download contents from not only the Contents
Server but also Clients who finished downloading the contents. To select the download site, we send Pings to the
list of download site, and then select the download site which has the shortest RTT. But, in this implementation
requests from Clients flock to the download site which has the shortest RTT, because the download site has been
selected only by Client side. As a result, there are possibility that download time deteriorates. In this paper,
we propose a “P2P based Contents Delivery Network System using Cooperation of Server and Clients” which is
aiming for load-balancing by adjusting the candidates of download sites given to the client at the server side, and
by restricting the number of maximum connections of each candidate. The performance of our proposed methods
and the prototype system are evaluated by computer simulations. As a result, we showed that the contents delivery
time of our proposals are reduced up to 40% compared to the prototype system.
Key words contents delivery network, P2P, High definition TV
—1—
1. 序
論
㪦㫉㫀㪾㫀㫅㪸㫃㩷㪪㪼㫉㫍㪼㫉
Web サービスの急速な普及およびアクセス網の高速化に伴
い，ネットワークを伝送されるコンテンツとしてリッチコンテ
ンツと呼ばれる映画や音楽などの大容量ファイルが増加してい
㪪㪪㩷㪘
㪪㪪㩷㪚
る．また，2011 年 7 月 24 日に地上波アナログ放送が終了し，
完全に地上波デジタル放送へ移行することが決定している．こ
れらを受けて，近年 HDTV(High Definition TeleVision) に注
㪪㪪㩷㪙
目が集まっている．HDTV とは「高品位テレビ」の略で，現在
のテレビより走査線数を増やして画質を向上させた次世代のテ
レビ方式の総称である．地上波デジタル放送・衛生放送や次世
㶎㪪㪪㪑㩷㪪㫌㫉㫉㫆㪾㪸㫋㪼㩷㪪㪼㫉㫍㪼㫉
代 DVD は HDTV に含まれる．
現在，音楽配信では Apple，動画配信では YouTube，Gyao，
図 1 HDTV 配信に伴う CDN の問題
ニコニコ動画などのサービスが普及している．これらの動画配
信サービスは非常に多くのチャンネルを持っているため，ユー
ケツリレー式にデータを運ぶ pure P2P の 2 種類がある．前者
ザーが比較的大きなデータを伝送する機会が増えている．現状
には Napster [2] や Rumor，WinMX [3] などがあり，後者には
のこのような動画コンテンツ配信サービスは，ほとんどの場合
Gnutella [4]，ArielAirOne [5]，Winny [6] などがある．
がストリーミングによるものである．しかし，ストリーミング
CDN で HDTV の配信を考えた場合，大きく 2 つの問題
には，
「ネットワーク接続がなければ映像を閲覧することがで
が考えられる．1 つ目は「回線速度」，2 つ目は「ダウンロー
きない」，
「ネットワークに大きな負荷を与える」，
「ネットワー
ド時間」である．図 1 にクライアントの膨大なアクセスにより
ク回線のデータ転送スピードやコンピュータのパワーに画質が
SS が過負荷状態になった CDN を示す．図に示すように，同じ
影響される」という欠点がある．また，Youtube のビットレー
クラスタ内で単一の SS に接続されているすべてのクライアン
トは 280kbps，Gyao は 384kbps もしくは 768kbps 程度で共
トが，HDTV 配信のためにそれぞれ 20Mbps の帯域をネット
に解像度も低い．一方 HDTV を見てみると，ビットレートは
ワークに要求した場合，SS は過負荷状態となりサーバがダウ
22Mbps と高く，解像度も高く高画質高精細である．今後普及
ンすることが考えられる．また，サーバが過負荷状態になると
すると予想される HDTV コンテンツはデータ量が莫大なため，
ネットワークの回線速度に影響が出るため，大幅なダウンロー
多チャンネル配信サービスを考えた場合，ネットワークに与え
ド遅延が生じる可能性がある．このように，CDN では HDTV
る多大な負荷や，画質の劣化のためストリーミングによる配信
をはじめとするリッチコンテンツに対するダウンロード遅延を
は難しいと考えられる．そこで，本稿ではダウンロード型に着
削減するには至っていない．
目し，HDTV コンテンツの多チャンネル配信を検討する．
この問題を受けて，現在の CDN によるコンテンツ配信の
大容量コンテンツを高速に伝送するためのネットワークとし
仕組みと異なるブレイクスルーが必要となってきている．そこ
て Contents Delivery Network(CDN) と Peer to Peer(P2P) が
で，本稿では P2P 技術を CDN に応用し，HDTV 等のリッチ
ある．CDN とはコンテンツプロバイダーから多数のユーザへ動
コンテンツを高速に配信するコンテンツ配信ネットワークシス
画などのマルチメディアコンテンツを効率的に配信するための
テムについて検討する．図 2 に実装を行ったプロトタイプシス
手助けをする中間レイヤである．複数の Surrogate Server(SSs)
テムを示す．プロトタイプシステムの主要素は 2 つあり，
「カテ
が地理的に分散配置され，各 SS は Original Server の保持す
ゴリー（嗜好性）」と「ダウンロード先選択」である．本プロト
るコンテンツの中で人気の高いもののレプリカを持ち，ユーザ
タイプシステムでは，従来の CDN とは異なりクライアントと
のリクエストを SS で解決することにより，Original Server へ
コンテンツサーバで自動的にカテゴリー（嗜好性）のマッチン
集中する負荷を各 SS へ分散することが可能となる．ユーザが
グを行い，動的に最適なダウンロード先を選択することによる，
最近傍の SS にコンテンツのリクエストを行い，その SS がリ
HDTV コンテンツの自動配信が可能となっている．そのため，
クエストされたコンテンツを持っていなかった場合，リクエス
クライアントはローカルの HDD(Hard Disc Drive) に溜まった
トは他の SS へと転送される．そして，すべての SS がリクエ
HDTV コンテンツを即時に閲覧することができる．
ストされたコンテンツを持っていなかった場合，リクエストは
まず，1 つ目の要素である「カテゴリー（嗜好性）」につい
最終的に Original Server に転送される [1]．このような機構に
て説明する．ここで言うカテゴリーとは嗜好性を意味してお
より，CDN システムはユーザのリクエストに対して円滑なコ
り，YouTube や Gyao などの現行サービスでのチャンネルを指
ンテンツ配信を可能としている．一方，P2P とは不特定多数の
す．クライアントがカテゴリー情報を登録しておくと，コンテ
コンピュータが相互に接続され，直接ファイルなどの情報を送
ンツサーバに登録されているコンテンツと自動的にカテゴリー
受信するインターネットの利用形態，またはそれを可能にする
のマッチングを行い，自分の嗜好性に合ったコンテンツが自動
ソフトウェアやシステムのことである．P2P には中央サーバの
配信される．次に 2 つ目の要素である「ダウンロード先選択」
媒介を必要とする Hybrid P2P と，中央サーバを必要とせずバ
について説明する．最適なダウンロード先を選択することは
—2—
(1)register a content
with category
2. 従来方式
Contents Server
2. 1 コンテンツ配信手順
*movie
図 2 にプロトタイプシステムにおけるコンテンツ配信の様子
Administrator
を示す．図中の手順 (1)，(2)，(3) について以下に説明する．
Client 6
*movie
*sport
（ 1 ）ネットワークの管理者がコンテンツサーバにカテゴ
(2)auto
access&&Meta
Meta
auto access
information
acquisition
information
acquisition
リー（嗜好情報）と共にコンテンツを登録．図では一例として
(3)Automatic
㽴Automatic
delivery
delivery
Client 5
*cartoon
*sport
*other
Client 4
*news
*sport
*other
movie となっている．
Client 1
（ 2 ）各クライアントはランダムにコンテンツサーバに自動
*movie
*sport
*news
アクセスしカテゴリーマッチングを行う．またこの際に，カテ
Client 2
Client 3
*movie
*others
*cartoon
*news
図 2 プロトタイプシステムの全体像
ゴリーがマッチしたコンテンツを既にダウンロード済みのクラ
イアントのリストも取得する．その後，リストのクライアント
すべてに Ping を送り RTT が最短のダウンロード先を選択す
る．ここで，カテゴリー情報・カテゴリーがマッチしたコンテン
HDTV のような大容量コンテンツをダウンロードする際に非
ツを既にダウンロード済みのダウンロード先候補リストなどの
常に重要になる．ここでいう最適とはコンテンツのダウンロー
情報はコンテンツサーバから XML 形式の meta データとして
ドが早く終わる，つまり伝送速度が速いということを意味する．
クライアントに配信される．本プロトタイプシステムで XML
しかし，ネットワークの伝送速度を正確に測定することは難し
の含む情報としては，カテゴリー情報，ファイルサイズ，アブ
いため，伝送速度の測定を行わずにある程度最適なダウンロー
スト情報，コンテンツを既にダウンロード済みのダウンロード
ド先を選択する手法としては大きく別けて以下の 2 つがある．
先候補リスト，最終 update 日時などである．
（ 1 ）「コンテンツサーバ側のみによるダウンロード先選択」
（ 2 ）「クライアント側のみによるダウンロード先選択」
前者は，CDN などで用いられている DNS，Round Robin
などでクライアントからのリクエストを各サーバに振り分け
る手法である．しかし，コンテンツサーバ側のみによるダウン
ロード先選択では，クライアント側にとって必ずしも最適なダ
ウンロード先が指定されるとは限らない．
そのため，今回実装を行ったプロトタイプシステムでは，後者
を採用した．プロトタイプシステムでは，コンテンツサーバの
みではなくコンテンツのダウンロードが終わったクライアント
もダウンロード先の候補とする．プロトタイプシステムではこ
の部分に P2P の要素を導入している．コンテンツを要求する
クライアントはコンテンツサーバからダウンロード先候補リス
トを受信し，すべてに Ping を送信し RTT(Round Trip Time)
を計測する．そして，RTT が最短のクライアントをダウンロー
ド先として自動選択しコンテンツのダウンロードを行う．しか
し，この方式ではクライアントによる RTT 測定のみでダウン
ロード先の選択を行っているため，コンテンツを要求するクラ
イアントのアクセスが，そのクライアントにとって常に RTT
が最短のダウンロード先に集中してしまう．その結果，全クラ
イアントへのコンテンツ配信時間に影響が出てしまうという問
題点があった．
そこで，本稿では新たに「サーバ-クライア
ント協調型ダウンロード先選択」という概念を導入し, ダウン
ロード先候補の適応的絞り込みと，各候補への最大コネクショ
ン数を制限することにより，更なる負荷分散を図ったサーバ-ク
ライアント協調型 P2P コンテンツ配信配信ネットワークシス
テムを提案する．計算機シミュレーションにより特性評価を行
い，RTT のみを考慮した従来プロトタイプシステムと比較し
て提案方式における全クライアントへのコンテンツ配信時間を
最大 40%改善できることを示す．
（ 3 ） RTT が最短のダウンロード先からコンテンツを自動
ダウンロード．
2. 2 プロトタイプシステムの問題点
図 3 にプロトタイプシステムにおける問題点を示す．プロト
タイプシステムではコンテンツ要求のあったクライアントに，
カテゴリーのマッチしたすべてのクライアントのリストを配信
していた．そのため，複数のコンテンツをクライアントが同時
に要求した場合，RTT が最短のダウンロード先へとアクセス
が集中してしまい，結果的に全コンテンツのダウンロード時間
が増大するという問題があった．図 3 を用いて具体的に説明す
る．クライアント 8 がカテゴリー B, C, D のコンテンツを同時
に要求した場合を考える．今，カテゴリー B のコンテンツを既
にダウンロード済みのクライアントはクライアント 1, 3, 5, 6,
9，カテゴリー C のコンテンツを既にダウンロード済みのクラ
イアントはクライアント 2, 4, 5, 7, 9，カテゴリー D のコンテ
ンツを既にダウンロード済みのクライアントはクライアント 1,
3, 4, 6, 9 である．プロトタイプシステムではコンテンツ要求の
あったクライアントにコンテンツサーバの持つすべてのダウン
ロード先候補リストを配信するため，クライアント 8 にこれら
のすべてのリストが配信される．そのため，RTT が最短であ
るクライアント 9 にアクセスが集中してしまい，結果的に全コ
ンテンツのダウンロード時間が増大していた．
3. 提案方式
プロトタイプシステムでは従来の CDN の同じクラスタ内の
リクエストがすべて同一 SS に一極集中することによるダウン
ロード遅延の増大を解決した分，ダウンロード時間の短縮は期
待できる．しかし，プロトタイプシステムではコンテンツを要
求するクライアント側のみによる RTT 計測でダウンロード先
—3—
Contents Server
B
C Client 9
D
e
liv
he
rt
C
nt
lie
st
Li
Client 1
B
D
De
Client 2
A
C
B
C
D
Client 3
Client 7
A
C
Client 4
Client 6 Client 5 C
B
D
B
C
Client List (Category B)
Client 1, Client 3, Client 5
Client 6, Client 9
Client List (Category C)
e
liv
Client 1, Client 3, Client 4
Client 6, Client 9
B
D
D
he
rt
Cl
t
ien
st
Li
Client 1
B
D
De
Client 2, Client 4, Client 5
Client 7, Client 9
Client List (Category D)
Client 8
Contents Server
B
C Client 9
D
Client List (Category B)
Client 2
A
C
Client 1, Client 3
Client 6
Client List (Category C)
Client 2, Client 5
Client 7
Client List (Category D)
Client 8
B
C
D
Client 3
Client 7
A
C
Client 4
Client 6 Client 5 C
B
D
B
C
Client 1, Client 4
, Client 9
B
D
D
図 3 プロトタイプシステムの問題点
図 4 提案方式のダウンロード先候補リスト配布方法
選択を行っているため，P2P を導入しているにも関わらず常
ると考えられる．図 4 を用いて具体的に説明する．クライアン
に RTT が最短のダウンロード先にアクセスが集中してしまい
ト 8 がカテゴリー B, C, D のコンテンツを同時に要求した場合
結果的にダウンロード遅延に影響が出てしまうという問題点が
を考える．今，カテゴリー B のコンテンツを既にダウンロード
あった．そこで，本稿ではダウンロード先候補の適応的絞り込
済みのクライアントはクライアント 1, 3, 5, 6, 9 である．しか
みと，各候補への最大コネクション数を制限することにより，
し，提案方式ではコンテンツサーバがクライアントに与えるダ
更なる負荷分散を図ったサーバ-クライアント協調型 P2P コン
ウンロード先候補の絞込みを行う．この場合，クライアント 1,
テンツ配信配信ネットワークシステムを提案する．最大コネク
3, 6 を含んだダウンロード先候補リストがクライアント 8 に配
ション数制限のみを考慮した場合と，最大コネクション数制限
信される．次に，カテゴリー B のコンテンツを既にダウンロー
とダウンロード先候補の適応的絞込みの両者を考慮した Sliding
ド済みのクライアントはクライアント 2, 4, 5, 7, 9 である．同
Window 方式・Alternately Sliding Window 方式についてそれ
様の方法で，コンテンツサーバはクライアントに与えるダウン
ぞれ検討する．
ロード先候補リストを絞込む．この場合，クライアント 2, 5, 7
3. 1 最大コネクション数制限
本提案ではダウンロード先に最大コネクション数制限を設け，
ダウンロード先のコネクション数が最大コネクション数を超え
た後のクライアントの挙動を工夫する．
まずサーバ側の動作について説明する．サーバ側の動作はプ
ロトタイプ実装システムと同様であり，要求のあったクライア
ントのカテゴリーと一致したコンテンツを既にダウンロード済
みの全ダウンロード先候補リストをクライアントに配信する．
次にクライアント側の動作について説明する．クライアント
を含んだダウンロード先候補リストがクライアント 8 に配信さ
れる．また，カテゴリー D のコンテンツを既にダウンロード済
みのクライアントはクライアント 2, 4, 5, 7, 9 である．しかし，
クライアント 1, 4, 9 を含んだダウンロード先候補リストがク
ライアント 8 に配信される．この場合，絞込みによりクライア
ントの要求が真に最速のダウンロード先へ送信されないので，
ダウンロード速度を劣化させずに負荷分散を図るためには，ダ
ウンロード先候補リストの絞込み方法が重要となる．以下に 2
つのダウンロード先候補リストの絞込み方式を提案する．
は受信したダウンロード先候補リストすべての RTT を計測し
3. 2. 1 Sliding Window 方式
最短のものをダウンロード先として選択する．プロトタイプ
まずサーバ側の動作について説明する．コンテンツサーバは
実装システムでは最大コネクション数を越えた後に来た要求は
要求のあったクライアントのカテゴリーと一致したコンテンツ
キューイングされていたため遅延が大きくなっていたが，提案
を，ランダムに並べられた既にダウンロード済みのクライアン
方式では RTT が最短の所で要求をキューイングせずに，RTT
トの中から window size 分のダウンロード先候補リストを選択
が 2 番目に短いものを DL 先として選択しコンテンツを要求す
して配信する．ここで window size をクライアントに配信され
る．そのため，提案方式の全クライアントへのコンテンツ配信
るダウンロード先候補リストのサイズと定義する．図 5 にサー
時間の短縮が見込める．
バ側のダウンロード先候補リストの選択方法を示す．図中の長
3. 2 ダウンロード先候補の適応的絞込み
提案方式では，クライアントに提示するダウンロード先の重
複を減らし負荷分散を図ることと，Ping の送信測定回数及び
測定時間の低減を目的とし，コンテンツサーバ側でクライアン
トに与えるダウンロード先候補を絞込む．クライアント側は，
従来通り提示されたダウンロード先候補の中から最も RTT が
短いものを選択するだけで，ネットワークの負荷分散が期待で
き，全クライアントへのコンテンツ配信時間の短縮を実現でき
方形はコンテンツサーバの持つすべてのダウンロード先候補リ
ストを示している．各クライアントの IP アドレスはランダム
に並んでいる．今，例として window size を 3 として説明する．
最初にアクセスのあったクライアントには先頭から 3 つ選択し
8, 2, 6 のダウンロード先候補リストを配信する．2 番目にアク
セスのあったクライアントには window size 分ずらして 4, 10,
7 のダウンロード先候補リストを配信する．以降のアクセスに
ついても同様である．
—4—
表 1 シミュレーション諸元
All the Client List of the Contents Server
Kind of Contents
8 2 6 4 10 7 1 5 9 3
Third access
First access
Second access
……….
HDTV (20%)
DVD (80%)
Number of Clients
The Maximum Connection
図 5 Sliding Window 方式のダウンロード先候補リスト選択
20GB
4GB
10, 40, 100
4, 8
FTTH (50%)
25Mbps ∼ 35Mbps
Second access
1 2 3 4 5 6
Speed of Circuits
CDTV(20%)
15Mbps ∼ 25Mbps
7 8 9 10
DSL (30%)
First access
Third access
3Mbps ∼ 6Mbps
……….
図 6 Alternately Sliding Window 方式のダウンロード先候補リスト
選択
4. 1 シミュレーション結果
4. 1. 1 Connection Restriction とプロトタイプシステムと
の比較
次にクライアント側の動作について説明する．クライアント
図 7 に最大コネクション数制限のみを考慮したもの (以下，
は受信した window size 分のダウンロード先候補リストの RTT
Connection Restriction とする) とプロトタイプシステムにお
を計測し最短のものをダウンロード先として選択する．Sliding
ける，全クライアントがコンテンツのダウンロードを終了するま
Window 方式ではコネクション数制限を考慮しているため，最
での時間を示す．最大コネクション数を以下では C と表現する．
大コネクション数を越えた後に来た要求を遅延させず，RTT が
図 7 を見ると，プロトタイプシステムに比較して，Connection
2 番目に短いものを DL 先として選択しコンテンツを要求する．
Restriction では C の値に関わらずダウンロード時間が改善さ
3. 2. 2 Alternately Sliding Window 方式
本方式は，RTT の短いダウンロード先を効率的に複数のク
ライアントに割り当てることを目的とする．まずサーバ側の動
作について説明する．サーバは要求のあったクライアントのカ
テゴリーと一致したコンテンツを既にダウンロード済みのダウ
ンロード先候補リストの中からダウンロードが早く終わった順
に並べ，window size 分の偶数番目・奇数番目のダウンロード
先候補リストを選択して配信する．図 6 にサーバ側のダウン
ロード先候補リストの選択方法を示す．図中の長方形はコンテ
ンツサーバの持つすべてのダウンロード先候補リストを示して
いる．各クライアントの IP アドレスはダウンロードが早く終
わった順に並んでいる．今，例として window size を 3 として
説明する．最初にアクセスのあったクライアントには先頭から
3 つ選択し 1, 3, 5 のダウンロード先候補リストを配信する．2
番目にアクセスのあったクライアントには window size 分ずら
して 2, 4, 6 のダウンロード先候補リストを配信する．以降の
アクセスについても同様である．クライアント側の動作につい
ては，Sliding Window 方式と同様である．
4. 特性評価
本章では，計算機シミュレーションにより提案方式における
全クライアントがカテゴリーマッチしたコンテンツをダウン
ロード終了するまでの時間について特性評価を行う．提案方式
と実装を行ったプロトタイプシステムとの比較を行う．トポロ
ジはフルメッシュトポロジとし，構成要素はコンテンツサーバ，
管理者，クライアントである．表 1 にシミュレーション緒元を
示す．コンテンツ配信時間をカテゴリーのマッチしたコンテン
ツを全クライアントに配信するまでの時間と定義する．
れていることが分かる．プロトタイプシステムではコンテンツ
を要求するクライアント側のみによる RTT 計測でダウンロー
ド先選択を行っており，P2P を導入しているにも関わらず常に
RTT が最短のダウンロード先にアクセスが集中してしまい結
果的にダウンロード遅延が増大していた．しかし，提案方式で
はサーバ側で受け付け可能な最大コネクション数の制限を設け，
RTT が最短であってもコネクション数でクライアントからの
アクセスを制限し，RTT が 2 番目に短いダウンロード先へ，3
番目に短いダウンロード先へとリクエストを行い直す．このこ
とにより，RTT が最短のダウンロード先へのアクセスの一極
集中を回避することができる．そのため，サーバとクライアン
トが協調してより最適なダウンロード先を選択することが可能
であり，プロトタイプシステムに比較してダウンロード時間が
短縮されたと考えられる．
また C=4 の場合，プロトタイプシステムではクライアント
数が増加すると，併せてダウンロード時間も顕著に増加してい
る傾向が見られるが，提案方式ではプロトタイプシステムほど
ダウンロード時間が増加していない．これは，プロトタイプシ
ステムではクライアント数が増えると必然的に RTT が最短の
ダウンロード先にコンテンツを要求するクライアント数が増え，
サーバ側が最大コネクション数に達した後に来た要求はキュー
で待たされるためであると考えられる．一方，提案方式では
サーバ側が最大コネクション数に達した後に来た要求は 2 番目
に RTT の短いダウンロード先へ・3 番目に RTT の短いダウン
ロード先へと転送するためダウンロード遅延の増大を従来方式
に比較して低減することができたと考えられる．
図 7 を見ると分かるように C=8 の場合は，C=4 の場合に比
較して提案方式のプロトタイプシステムからの改善率が劣化し
ている．これは，クライアントサーバ間の伝送速度を 4 本のコ
ネクションで共有するよりも 8 本のコネクションで共有する場
合の方が，コネクションごとの伝送速度が遅くなるからである．
—5—
Prototype (C=8)
Proposal (Connection Restriction) (C=8)
Prototype (C=4)
Proposal (Connection Restriction) (C=4)
4
3
7 10
Time to Finish Delivering Contents (Sec)
1.8 10
Time to Finish Delivering Contents (Sec)
Proposal(Only Connection Restriction) (C=4)
Proposal(CR + Sliding Window) (C=4)
Proposal(CR + Alternately Sliding Window) (C=4)
4
1.6 10
4
1.4 10
4
1.2 10
4
1 10
3
8 10
3
6 10
3
6.5 10
3
6 10
3
5.5 10
3
5 10
3
4.5 10
3
4 10
3
4 10
0
20
40
60
80
100
120
0
20
80
100
120
していないダウンロード先を選択するのではなく，Window
Sliding Window (window size=5)
Sliding Window (window size=4)
Sliding Window (window size=3)
Sliding Window (window size=2)
size を導入したことで分散してコンテンツをダウンロードでき
7 10
Time to Finish Delivering Contents (sec)
60
図 9 提案方式の比較
図 7 Connection Restriction とプロトタイプシステムとの比較
3
40
Number of Clients
Number of Clients
ているためと考えられる．また，Sliding Window 方式と Al-
ternately Sliding Window 方式を比較した場合，Alternately
3
6.5 10
Sliding Window 方式の方が若干特性の改善がみられる．この
3
6 10
理由は，コンテンツのダウンロードが終わった順にリストを並
べ替えて偶数番目・奇数番目と交互に配信しているため，RTT
3
5.5 10
の短いダウンロード先がリストに含まれる可能性が高いためで
3
5 10
あると考えられる．しかし，サーバの持つダウンロード先候補
3
4.5 10
リストの後ろの方には RTT の遅いリストが集中してしまうた
3
4 10
0
20
40
60
80
100
120
Number of Clients
図 8 Sliding Window 方式における Window size ごとの評価
4. 1. 2 Window Size ごとの Sliding Window 方式の比較
次に 2 つめの提案方式である Sliding Window について
め，ランダムにダウンロード先候補リストを選択する Sliding
Window 方式に比較して大幅な特性の改善は見込めないと考え
られる．
5. 結
論
本稿ではダウンロード先候補リストの適応的絞り込みと，各
Window size ごとにコンテンツ配信時間の特性評価を行う．
候補への最大コネクション数を制限することにより，更なる負
Window size=2 , 3 , 4 , 5 の場合について比較を行う．図 8 に
荷分散を図ったサーバ-クライアント協調型 P2P コンテンツ配
Sliding Window 方式における window size ごとのコンテンツ
信配信ネットワークシステムを提案した．計算機シミュレー
配信時間の評価を示す．図から window size=3 の場合が特性が
ションにより特性評価を行い，RTT のみを考慮した従来プロ
最もよいことが分かる．window size が大きい場合，複数のクラ
トタイプシステムと比較して提案方式における全クライアント
イアントに RTT が短い DL 先を重複して配信してしまい，そ
へのコンテンツ配信時間を最大 40%改善できることを示した．
こにアクセスが集中することが考えられる．逆に window size
謝辞本研究は，平成 19 年度科研費基盤 (C)「P2P による
が小さい場合，RTT の短い DL 先がダウンロード先候補リス
事前ダウンロード型 CDN 実現へ向けた新しい通信方式の研究」
トに含まれない可能性が考えられる．そのため，このような結
および，グローバル COE プログラム「アクセス空間支援基盤
果となったと考えられる．この結果を受け，本稿では window
技術の高度国際連携」(C12) の助成を受けたものである．
size を 3 として特性評価を行う．
4. 1. 3 コンテンツ配信時間に関する評価
図 9 にコンテンツ配信時間についての特性評価を示す．
最大コネクションのみを考慮した Connection Restriction よ
りも，ダウンロード先候補リストの与え方も工夫した Sliding
Window 方式・Alternately Sliding Window 方式の方が特性が
改善されていることが分かる．これは Sliding Window 方式と
Alternately Sliding Window 方式は Connection Restriction
文
献
[1] 本間潤一郎, 辻智博, 荒川豊, 岡本聡, 山中直明, “ロングテール化
するユーザリクエストを効率的に処理するコンテンツ配信ネット
ワークシステム,” 電子情報通信学会技術研究報告, Vol. NS2006,
No. 186, pp. 149-154, March 2007.
[2] http://www.napster.jp/
[3] http://pc.nikkeibp.co.jp/word/page/10019462/
[4] http://www.gnutella.com/
[5] http://ascii24.com/news/i/tech/article/2002/06/21/636711000.html
[6] 金子勇, 「Winny の技術」, Ascii 書籍編集部 2005.
とは異なり，単純に RTT が短い順に最大コネクション数に達
—6—

Download Report