「P2P共有」の版間の差分

履歴の双方向閲覧

← 古い編集

削除された内容追加された内容

ビジュアルウィキテキスト

インライン

2014年9月14日 (日) 05:32時点における最新版

転送先:

ファイル共有ソフト

@@ 1行目: / 1行目: @@
-{{Mergeto|ファイル共有ソフト|ファイル共有ソフト|date=2014年9月}}
+#redirect [[ファイル共有ソフト]]
-P2P共有は、本来は単にP2P（[[Peer to Peer]]の略称）通信によるデータ共有のことであるが、実例上は多数ユーザーによるP2P通信を利用したファイル共有を指す。匿名性をP2P共有の特徴とする用例も目立つが、匿名性はP2P共有の必要条件ではない。このようにP2P共有という用語の立場は不明瞭であるが、以下ではこの「実例上のP2P共有」を単にP2P共有として述べる。
-なお、用語としてP2P共有とP2Pが区別されず使用されていることがあるが、P2P技術を用いたサービスがP2P共有技術を用いたサービスと誤解されるケースも目立つため、明確に区別するべきである。
-P2P共有には、（通信を行う[[ソフトウェア]]や[[通信プロトコル]]などに左右されつつも、）発信者の[[匿名]]性がある程度確保できるという特徴があり、[[Winny]]に代表されるような[[アンダーグラウンド (文化)|アンダーグラウンド]]な用途でも利用が多い。
-== P2P共有における匿名化技術 ==
-従って、実際のP2Pでは、'''どのように相手のIPアドレスを知るか'''、が重要なポイントとなる。昨今のP2Pでは、例えば、コンテンツのタイトルや検索キーワード、放送局のチャンネル名といった、人にとって意味のある名前で通信相手を特定して、通信ができるようになっている。
-この意味で、P2P方式での通信網は、[[オーバーレイ・ネットワーク]](Overlay Network)と見ることができる（以下、OLNと略記する）。
-通常のIPネットワークの上に、もう一層、別のネットワークを、特定のニーズに合うノード同士で作り上げる、という意味合いである。
-もう少し具体的に言うと、例えば[[Winny]]では、「欲しいコンテンツの名前」で「そのキャッシュを持っている相手」を特定して通信をおこない、例えば、[[Skype]]では、「ニックネーム」で「ニックネームに対応する相手」を特定して通信をおこなう。一般化すると、「キー」を手かがりに「キーに対応するデータを持つ者」を発見して、その相手と通信をする、という動作になる。「キー」と「データ」をペアで結びつけた情報を'''インデックス情報'''と呼ぶ。通常「データ」は、そのデータを持つ者のIPアドレスとして記憶させる。（インデックスは、'''key-valueペア'''という呼び方をする場合もある。）
-P2Pでは、インデックス情報をどのように管理するかが重要となる。
-=== メリット ===
-;匿名性
-<!--匿名性には、利用者の目的によって、メリット、デメリットの両面があるが、この位置に書いておく-->
-:P2P方式で、データの中継転送を数多く行えば、誰がそのデータを公開したかを突き止めることを、非常に困難にすることができる。[[Winny]]、[[Share (ソフトウェア)|Share]]、[[Perfect Dark]] などの、アンダーグラウンドなP2Pシステムでは、著作権を無視した違法なコンテンツの公開を、誰が行ったかを隠蔽するために、匿名性が重要視される<ref>[http://imony.fbox.info/develop/point.html Imony開発者の考慮ポイント]</ref>。これは、管理をする立場から見るとデメリットになるわけで、逆に、商用のP2Pシステムでは匿名性は排除して、トレーサビリティを重視した実装を目指す場合も多い。誰がいつどういうデータを送受信したか、までトレースできるようになっているシステムも模索されている<ref>[http://www.nec.co.jp/press/ja/0501/0402.html NEC P2PWeb]</ref>。
-:また、言論の自由という観点から、匿名性を持たせたP2P掲示板システム（[[新月 (掲示板)|新月]]など）も注目されている。
-=== デメリット ===
-;実装の困難さ
-:実装の難易度が高い。
-:特に、エンドユーザの端末がPCである場合には、その電源オン期間が不確定な場合が多く、端末の頻繁な脱退や長期の不在期間を考慮したアルゴリズムが必要になる。参加脱退が激しいノードが居ることに対してどう対処するかは、「Churn問題」という呼び方をする<ref>[http://www.shudo.net/publications/ComSys2007-churn-resilience/shudo-ACS-21-churn-resilience.pdf 下位アルゴリズム中立なDHT実装への耐churn 手法の実装]</ref>。P2P方式は、クライアントサーバ方式に比べて、信頼性が劣るイメージがあるが、逆に、このChurn問題への対応策を取らざるを得ないことにより、自ずから耐障害性が高いシステムが出来上がるという側面もある。
-:端末がPCである場合は、各PCの処理能力、転送能力、保存容量などの条件が千差万別であり、できるだけ多くの種類のPCで動くようにするには、注意深い実装が必要になる。
-;動作確認の困難さ
-:動作確認、評価の難易度が高い。設計段階では、シミュレータなどを用いての動作確認が可能であるが、最終的には、多数のノードを実際に並べて動作確認を取る必要がある。これが、技術的、経済的に難しく、実環境でシステム評価を行って確実に動くシステムに仕上げるには、多大な手間と費用がかかり、これまでクライアントサーバ方式でやってきた配信業者が、P2P方式に乗り換えようとする際の参入障壁となっている。実際には、10000ノードレベルになると、開発者や開発業者が、これを自前で揃えるのは現実的ではなく、一般人から、有償・無償でモニターを募って、実証実験を行うケースが多い<ref>[http://www.tv-bank.com/jp/20081031.html TVバンクのP2Pライブ配信のプレスリリース]</ref><ref>[http://www.biglobe.co.jp/press/2008/1111-1.html BIGLOBEとウタゴエによるライブ動画配信トライアル]</ref><ref>[http://www.brother.co.jp/news/2007/dstream/ ブラザー工業 D-Stream コンテンツ配信システムの実証実験]</ref>。
-;削除制御の困難さ
-:[[Winny#Winnyによる情報流出事件|Winny事件]]で注目されたように、データが一旦P2P網に公開されると、キャッシュを持つノードが存在する限り、データが公開され続ける、という問題がある。Winnyの場合では、そのデータに誰もアクセスしなくなると、しだいにキャッシュから忘れられて、最後にはデータがP2P網上から消滅するのであるが、覚えている端末が少しでもいると、誰かがアクセスしたときに増殖する。また、一旦データのコピーをキャッシュに持った端末が、電源を切った状態になると、一旦P2P網上からなくなったように見えても、再び電源が入ったときに、データが復活するという事情も手伝って、完全な削除を困難にしている。
-:ただ、最近の商用のP2P配信システムでは、管理側からリモートで削除ができる仕組みを、あらかじめ実装しておくことで、この問題は克服されつつある<ref name="EinyOnDmand">[http://www.brother.co.jp/einy/about/ondemand.htm Einy On-Demand]</ref>。
-;セキュリティ制御の困難さ
-:これもWinny事件で注目されたように、エンドユーザのPC上の個人情報が、ユーザが意識しないうちに、漏洩する可能性がある。これは、エンドユーザが自分でデータを公開できるようなタイプのP2Pシステムで起きる。この公開機能を利用して、違法なコンテンツや、ウィルス入りのデータが、頻繁に公開されて、様々な社会問題となった。商用の多くのP2Pシステムでは、この問題に対する対策として、データの投入口を管理者側にしか設けない作りとなっており、不正なデータが混入する恐れは無くなっている<ref>[http://www.bittorrent.co.jp/ BitTorrent DNA]</ref><ref>[http://www.skeedtools.com/ SkeedCast]</ref><ref>[http://www.gridsolutions.co.jp/technology/ グリッド・デリバリー]</ref><ref name="EinyOnDmand"/>。
-;インターネットへの負荷
-:昨今のインターネットのトラフィックの中身を解析すると、そのほとんどがファイル共有ソフトの物であることが、問題視されている。これ自体は、利用者のニーズがあるために発生している結果であり、使いたい人が多いのであれば、通信キャリアやISPとしてはインターネットを強化していくべきものであるが、問題は、次項に掲げたように、この負荷と料金が経済的に折り合っていないことである。
-;ISP、通信キャリアの料金体系とのミスマッチ
-:現状の通信キャリアやISPの間の通信料金体系は、インターネットをクライアントサーバモデルで利用することを想定している。すなわち、一般ユーザは、さほど大きなトラフィックを使うことはないので、使いたい放題の固定料金体系とし、一方、コンテンツを提供する業者は、サーバを設置して太い回線を使うので、これらの業者から比較的高い料金をもらうという構造である。また、各ISPや通信キャリア会社の間では、インターネットの階層(Tier)の上下関係、および、IPパケットの通過量に応じて、従量制のトランジット料金のやりとりが行われている。
-:ここにP2P方式のアプリケーションが増えてくると、当初想定していなかったような量のデータが一般ユーザのPCから送受信され、大きなサーバを設置していない地区のネットワークから大量のトラフィックが発生し、ISPのルータに負荷がかかったり、ISP間のトランジット料金のバランスが実体トラフィックと合わなくなるなど、料金体系を考えたときの目論見が外れて、様々なコスト上のアンバランスが生まれる。ただこれは、料金体系の改訂が、利用状況に追いついていないために生じている問題であり、時間が解決するものと思われる。
-;環境への負荷
-:通常P2Pはサーバを設置しないため環境負荷が低いと思われがちだが、ファイル共有ソフトを使用する場合は主に使っているパソコンの他にP2P用のパソコンを用意した方が無難なため、ファイル共有目的だけ見ればパソコンの台数は倍になる計算になる。またクライアント型では受信したいときだけパソコンを起動していれば良いがP2Pでは常に起動している必要が有ることも要因となる。
-:ただしこの問題は規模や用途により異なるので一概に環境負荷が高いとは言えないので注意が必要。(チャットなどの用途では環境負荷は低くなることが多い)
-== 技術的な分類 ==
-=== インデックス情報の持ち方での分類 ===
-「このキーに対応するデータを持っているのは誰か？」という問いに答えるためには、キーとデータのありかの対応表（インデックス）を持っている必要があるが、これをサーバに集中して持たせる場合と、各ノードに分散して持たせる場合と、特定の選ばれたノードに分散して持たせる場合、の3種類が存在する。''(図を入れると良い)''
-==== ハイブリッドP2P ====
-[[ファイル:BitTorrent DNAの動作説明2.PNG|thumb|200px|ハイブリッドP2Pの仕組み（図はBitTorrentのもの）。<br />欲しい情報となるキーファイルをサーバーに伝え、実際のデータはノード同士でやりとりを行う仕組み]]
-ハイブリッドP2Pにおいては、インデックス情報を、中央のインデックスサーバで一括して管理する。新しいデータを保持したノードは、自分が持っていることを、インデックスサーバに申告しておく。データを欲するノードが、「このキーに対応する相手を教えて下さい」とインデックスサーバに問い合わせると、対応する相手のIPアドレスを教えてくれる。インデックスが膨大になると、スケーラビリティが無くなる点が、後述のピュアP2Pと比べて劣るが、通常規模のシステムであれば、この方式で事足りるケースが多い。インデックスサーバがダウンすると、システム全体が停止するため、耐障害性の面では、ピュアP2Pに劣る。
-[[BitTorrent]]、[[Napster]]、[[WinMX]]、放送型P2P([[オーバーレイマルチキャスト|OLM]])の多くは、この方式を採用している。
-<span id="pureP2P"></span>
-==== ピュアP2P ====
-[[ファイル:P2P-network.svg|thumb|200px|ピュアP2Pの仕組み。一切の処理をコンピューター同士が対等に通信を行うのが特徴である。]]
-インデックス情報は、各ノードが少しずつ分散して持ち合う。
-自分の知っているノードに、「データを持っているのは誰ですか？」というメッセージを投げると、そのノードが知っていれば回答が返り、知らなければ又聞きをしてくれる（メッセージを転送する）仕組みになっている。インデックスが膨大になっても破綻しないため、スケーラビリティが高い。メッセージ転送の方式により、非構造化タイプと構造化タイプの2つに分類できる（後述）。
-[[Gnutella]]、[[Freenet]]、[[OceanStore]]、[[Winny]]、[[Share (ソフトウェア)|Share]]は、この方式を採用している。
-ピュアP2Pに参加する際には、既に参加しているノードのIP情報を何らかの形で知っている必要がある。このためには、常に活きているノード(コンタクトノード)を用意しておいて、参加時はいつもそこに接続するようにするか、あるいは、参加しているいくつかのノードの情報をサーバに集めて、ここから知るように構成する。
-==== スーパーノード型P2P ====
-インデックス情報は、特定の選ばれたノード（スーパーノード）が分担して持つ。スーパーノードには、できるだけ安定な端末（ずっと電源が入っていて、通信回線も安定していて、帯域幅も太いようなノード）が選ばれる。スーパーノードは、一般のエンドユーザの端末から能力に応じて選ばれるが、サービス提供者側が用意した端末であることも多い。
-[[Kazaa Lite|KaZaA]]、[[Skype]]は、この方式を採用している。
-=== ピュアP2Pの構造による分類 ===
-ピュアP2Pにおいては、インデックス情報も分散されて持たれるため、相手先IPアドレスの発見の仕組みは、検索メッセージを転送することで行われる。転送方式で、2種類に分類ができる。
-;非構造化オーバーレイ
-:問い合わせ元のノードは、キーに対応する相手を発見するために、手当たり次第に、自分が知っているノード（かつて通信をしたことがあるノードなど）に対して、「データを持っているのは誰ですか？」というメッセージを投げつけ、受け取ったノードは、持っていれば返答し、持っていなければ検索メッセージをコピーして、他のノードに転送する方式。メッセージがネズミ算式に増えるので、フラッディング方式（洪水という意味）という別名が付いているが、メッセージが増えすぎないように、転送回数やメッセージの生存時間などで制限をかける必要がある。そのため、OLN上のどこかに相手が存在するにも関わらず、発見できない場合がある。
-:[[Gnutella]]、[[Freenet]]、[[Winny]]、[[Share (ソフトウェア)|Share]]などで実装されている。
-;構造化オーバーレイ
-:「データを持っているのは誰ですか？」というメッセージを転送する際の、転送先を選ぶ方法をあらかじめ構造的に決めておいて、「キーに対応する相手」が確実に分かるようにした方式である。よく知られている方式として、[[分散ハッシュテーブル]](Distributed Hash Table, DHT)、[[SkipGraph]]などがある。検索メッセージの転送先の範囲が、キーに応じてだんだんと絞られていくように設計されている。概略イメージは、A県の中のB市の中のC町の中の田中さん、というように範囲を絞る形で、メッセージが転送される、と考えると理解がしやすい。
-:DHTの実装例としては、[[Chord]]、[[CAN]]、[[Pastry]]、[[Tapestry]]、[[Kademlia]]、[[OpenDHT]]、[[Overlay Weaver]]などがよく知られている。
-== 脚注 ==
-{{脚注ヘルプ}}
-{{Reflist}}
-[[Category:P2P]]