Peer to Peer







P2P型ネットワーク(図はピュアP2P型)。コンピューター同士が対等に通信を行うのが特徴である。


Peer to Peer(ピア・トゥ・ピア または ピア・ツー・ピア)とは、複数の端末間で通信を行う際のアーキテクチャのひとつで、対等の者(Peer、ピア)同士が通信をすることを特徴とする通信方式、通信モデル、あるいは通信技術の一分野を指す。P2Pと略記することが多く、以下本記事においてもP2Pとする。




目次






  • 1 概要


  • 2 P2Pの端末装置


  • 3 インターネットにおけるP2P


  • 4 インターネットにおけるP2P通信のメリット、デメリット


    • 4.1 メリット


    • 4.2 デメリット




  • 5 P2Pアプリケーションの分類


    • 5.1 一対一通信型


    • 5.2 放送型


    • 5.3 オンデマンド型


    • 5.4 分散型データ管理




  • 6 技術的な分類


    • 6.1 インデックス情報の持ち方での分類


      • 6.1.1 ハイブリッドP2P


      • 6.1.2 ピュアP2P


      • 6.1.3 スーパーノード型P2P




    • 6.2 ピュアP2Pの構造による分類




  • 7 P2Pノードの一般的な機能


  • 8 P2Pに対する誤解と技術的課題


  • 9 脚注


  • 10 関連項目


  • 11 外部リンク


    • 11.1 研究資料


    • 11.2 P2P関連情報サイト







概要





クライアント-サーバ 型ネットワーク。サーバー(図中央)とクライアントは一対一の通信を行うのが特徴である。


P2Pに対置される用語としてクライアント-サーバ方式がある。クライアント-サーバ方式ではネットワークに接続されたコンピューターに対しクライアントとサーバに立場・機能を分離しており、一般的には多数のクライアントに対してサーバーが一つである。クライアントはサーバーとだけ通信でき、あるクライアントが他のクライアントと通信するにはサーバーを介す必要がある。


P2Pではネットワークに接続されたコンピューター同士が端末装置として対等の立場、機能で直接通信するものである。クライアント-サーバ方式ではクライアント数が非常に多くなると、サーバおよびその回線に負荷が集中するのに対して、Peer to Peer方式はその構造上、端末数が膨大になっても特定端末へのアクセス集中が発生しづらいという特徴がある。


P2P通信の一例としては、インターネットに接続した一般ユーザーの複数パソコン同士が互いのIPアドレスを呼び合う直接通信が挙げられる。P2Pによるネットワークはオーバーレイ・ネットワークの一つに数えられる。


実用化されたシステムとしてはP2Pデータ配信、P2P電話、P2P掲示板、P2P放送(テレビ、ラジオ)、P2Pグループウェア、P2P分散ファイルシステム、P2P-SIP[1]、P2P-DNS、P2P-仮想ネットワーク[2]、P2P地震情報などがある。またここ数年、商用的にも注目を集めており、特にIP電話(Skype,LINEなど)や動画配信サービス(Veohなど)といった応用例が増えてきている。


しかしこれらの応用技術は2000年代初頭から実用化され始めた技術であり、歴史的にはまだ日が浅く、成熟技術となるまでには解決しなければならない様々な問題がある(後述)。そのため現在でも学術的な研究が盛んな分野である。また無線通信で使われるモバイルアドホックネットワークもP2Pの一種であるが、無線での通信可能距離を稼ぐという特殊な使い方であるので詳細な解説は別項に譲る。



P2Pの端末装置


P2Pにおける通信端末はピア(peer)と呼ばれるが、トポロジー理論、グラフ理論などで用いる「ノード」(node:節点)という呼称を用いることも多い。またクライアントの機能とサーバの機能を併せ持つという意味でサーバントという呼び方をすることもある。


端末装置の種類としては一般家庭のパソコンやスマートフォンが使われることが多いが、STBやHDDレコーダ、HDD内蔵ルーターといったものもピアになりうる。



インターネットにおけるP2P


インターネットの基盤であるIPネットワークはIPアドレスさえ分かっていればどの端末にも到達できる。つまり端末同士が相手のIPアドレスを知っていればP2P通信が可能である。したがってインターネット上のP2P応用技術はIPネットワークのオーバーレイ・ネットワーク(Overlay Network:以下、OLNと略記する)と見ることができる。


例えば放送型サービスにP2Pを応用する場合はマルチキャスト型の通信形態となる。そのためこれをオーバーレイマルチキャスト(Overlay Multicast: OLM)あるいはアプリケーションレイヤマルチキャスト(Application Layer Multicast: ALM)と呼ぶことがある[3]
後者の呼び方はIPマルチキャストがTCP/IPのレイヤでのパケットの複製によりマルチキャストを行うのに対して、アプリケーション層でデータのコピーをしてマルチキャストを行う、という意味合いから来ている。



インターネットにおけるP2P通信のメリット、デメリット


インターネットにおけるP2P方式の通信には、以下のようなメリットとデメリットがある。



メリット



高スケーラビリティ

昨今、P2P方式が注目されている最大の要因である。理想的なP2P方式では全ての端末が等価であり、特別な機能や役割を持った端末が存在しないため、接続するユーザ数が膨大になっても特定の端末に負荷が集中しにくい(スケーラビリティが高い)。つまり、より多くの端末への配信が可能になる。一方、対照となるクライアント-サーバ方式ではクライアントの数が増えるごとにサーバの処理能力およびサーバにつながっているネットワーク回線に負荷が集中し、限界に達すると実用的な配信ができなくなる(スケーラビリティが低い)。特に動画配信などサーバから送るデータのサイズが大きい場合にスケーラビリティは重要である。



低コスト

上記のスケーラビリティの高さからくる特長である。クライアントサーバ方式に比べて要求されるサーバ装置性能が低くなり、通信回線も通信帯域幅の細い安価な回線で済む。このコスト差は端末数が増えれば増えるほど顕著となる。一般的にクライアントサーバシステムを運用する際に一番コストがかかるのがサーバの回線費用であり、これを格段に安価にできる。(見方を変えるとサーバの通信帯域を各ノードの回線のアップロード帯域で代替していることになる。)



耐障害性の高さ

理想的なP2P方式では全ての端末が等価であるため、特定の端末に障害が発生しても全体への影響は発生しない。あらかじめ同じデータを共有した端末を複数用意することができれば、データを受け取る側はどれか一つとでも接続可能であればデータ受信を継続可能である。一方クライアント-サーバ方式ではサーバがダウンすると全てのクライアントがデータ受信不可能に陥る。





匿名性

P2P方式で、ピア間の通信を暗号化したりデータの中継転送の回数を多くなるようにすれば、大元のデータを誰が公開したか、誰がそのデータを手に入れたか、を解析することが難しくなる。


Winnyなどのファイル共有ソフトの違法利用においては、著作権を無視したコンテンツの利用を誰が行ったかを隠蔽するために匿名性が喜ばれた。しかし管理者側からするとデメリットになるわけで、最近は念入りにトラフィック解析を行うことで犯人を確定することができるようになってきており、匿名性は薄れてきている[4]。逆に商用のP2Pシステムでは「誰がいつ、どういうデータを送受信したか」までトレースできるような、匿名性を排除したシステムも模索されている[5]

また言論の自由という観点から、匿名性を持たせたP2P掲示板システム(新月など)も存在する。



デメリット



実装の困難さ

実装の難易度が高い。特に、エンドユーザの端末がPCである場合には、その電源オン期間が不確定な場合が多く、端末の頻繁な脱退や長期の不在期間を考慮したアルゴリズムが必要になる。参加脱退が激しいノードが居ることに対してどう対処するかは「Churn問題」という呼び方をする[6]。P2P方式はクライアントサーバ方式に比べて信頼性が劣るイメージがあるが、逆にこのChurn問題への対応策を取らざるを得ないことにより、自ずから耐障害性が高いシステムが出来上がるという側面もある。端末がPCである場合は各PCの処理能力、転送能力、保存容量などの条件が千差万別であり、できるだけ多くの種類のPCで動くようにするには注意深い実装が必要になる。



動作確認の困難さ

動作確認、評価の難易度が高い。設計段階ではシミュレータなどを用いての動作確認が可能であるが、最終的には多数のノードを実際に並べて動作確認を取る必要がある。これが技術的、経済的に難しく、実環境でシステム評価を行って確実に動くシステムに仕上げるには多大な手間と費用がかかり、これまでクライアントサーバ方式でやってきた配信業者がP2P方式に乗り換えようとする際の参入障壁となっている。実際には10000ノードレベルになると開発者や開発業者がこれを自前で揃えるのは現実的ではなく、一般人から有償・無償でモニターを募って実証実験を行うケースが多い[7]





削除制御の困難さ


Winny事件で注目されたように、データが一旦P2P網に公開されるとキャッシュを持つノードが存在する限りデータが公開され続けるという問題がある。Winnyの場合ではそのデータに誰もアクセスしなくなるとしだいにキャッシュから忘れられて、最後にはデータがP2P網上から消滅するのであるが、覚えている端末が少しでもいると誰かがアクセスしたときに増殖する。また一旦データのコピーをキャッシュに持った端末が電源を切った状態になると、一旦P2P網上からなくなったように見えても再び電源が入ったときにデータが復活するという事情も手伝って、完全な削除を困難にしている。ただ最近の商用のP2P配信システムでは管理側からリモートで削除ができる仕組みをあらかじめ実装しておくことでこの問題は克服されつつある。





セキュリティ制御の困難さ

これもWinny事件で注目されたように、エンドユーザのPC上の個人情報がユーザが意識しないうちに漏洩する可能性がある。これはエンドユーザが自分でデータを公開できるようなタイプのP2Pシステムで起きる。この公開機能を利用して、違法なコンテンツやウィルス入りのデータが頻繁に公開されて様々な社会問題となった。商用の多くのP2Pシステムではこの問題に対する対策として、データの投入口を管理者側にしか設けない作りとなっており、不正なデータが混入する恐れは無くなっている[8]





インターネットへの負荷

P2Pはサーバ回線負荷を軽減する代わりに各ノードの回線負荷を高めてしまう。クライアントサーバ方式では一般的に、Webサイトなど送信専用サーバが集約されているサイトで、Akamaiに代表されるCDN(Contents Delivery Network)によるキャッシュサーバや代理サーバによってバックボーン回線の帯域を使用しないように負荷分散されている。しかし、P2Pによるファイル共有ソフトでは、基本的にクライアント間で行われる1対1の通信が基本となるため、通信の集約や負荷分散ができずバックボーン回線の帯域を大幅に使用する。


バックボーン回線における通信キャリアやISPの間の通信料金体系は、インターネットの階層(Tier)の上下関係、およびIPパケットの通過量に応じて従量制のトランジット料金のやりとりが行われている。そのためバックボーン回線の帯域の増大はISPの収益に直結している。

2000年代の初頭にはファイル共有ソフトによるバックボーン回線の帯域の使用率が75%を超える場合すら出てきて、ファイル共有ソフトを使用していない他の利用者の通信速度にまで影響が出てくるようになったため、ISP各社は約款でファイル共有ソフトなどによる回線当たりの平均帯域を上回る極端な通信量のユーザの帯域を制限するようになっている。これには2006年に通信の秘密に関連してISPによる「Winny」通信の遮断は行き過ぎであると総務省が違法性を指摘したことが関連している。ISPとしてはバックボーン回線維持のコストが増えることは言うまでもなく、プロバイダ責任制限法による通信監視の都合もあり、ファイル共有ソフトによる通信を完全に遮断したいところであったが、この総務省の指摘を受けて特定通信サービスの遮断ではなく特定ユーザが使用する帯域を制限することで落ち着いている。


通信相手特定の困難性

P2P方式では通信相手の端末の存在や接続経路を前提とすることができず、常に相手の存在とその接続経路を確認する必要がある。特に現在のインターネットの典型的な端末である各家庭のPCの多くはインターネットプロバイダーが提供するグローバルIPアドレスを使用してインターネットに接続していて、多くのプロバイダーは一般ユーザーが接続要求を出すたびに異なるグローバルIPアドレスを割り当てる。このような端末同士でのP2P通信を実現するには通信相手のIPアドレスを特定する方法を何らかの別方法で用意する必要がある。一方、クライアント-サーバ方式ではサーバーが固定のグローバルIPを取得するか、クライアントが参照可能なDNSに登録することでクライアントは毎回同じ方法によりサーバーにアクセスできる。



通信経路による通信速度の制限

P2P方式で最適な通信速度を確保するには全ての端末間の回線品質が等価である必要がある。しかし、これはインターネットでは不可能な要求であり、通信速度は端末を結ぶ中継回線の中で最も遅い回線の速度が上限となる。現在のインターネットは少数の高速な基幹ネットワークから多数の低速なサブネットワークに分岐していく構造になっていて、クライアント-サーバ方式ではサーバーを基幹ネットワークのなるべく近くに接続することで広い範囲のクライアントがなるべく高速な回線でサーバーに接続できるように設計できるが、P2P方式ではこの方法は少なくとも一般ユーザー間の通信では使えない。また、一般家庭の接続するインターネット回線は、ほとんどの場合ダウンロードよりもアップロードが遅いため、さらに制約が大きい。



P2Pアプリケーションの分類


ピア間で何を行うか、という観点で、大きく以下の4つのタイプ:



  1. 一対一通信型

  2. 放送型

  3. オンデマンド型

  4. 分散型データ管理


のアプリケーションに分けられる。
複数の機能を併せ持ったアプリケーションも存在する。



一対一通信型


IP電話、LINE電話やSkypeに代表されるような、端末間で一対一のコミュニケーションを行う使い方である。相手のIPアドレスを、電話番号やニックネームなどから見つけ出し(=IPアドレス解決と呼ぶ)、その後、ピアとピアが対等の立場で通信を行う。音声データであれば電話となり、映像データであればテレビ電話となる。インスタントメッセージやオンラインチャットもある。通常、アプリケーションの背後に特定の利用者が居ることが想定されており、その人物に対して接続を行うような使い方が多い。この種のアプリケーションのほとんどには、相手がオンラインかどうかを認識する仕掛け(プレゼンス機能)が設けられている。


このタイプのアプリケーションでは、データは通常、リアルタイムでのストリーミングでやりとりされる。


P2P-SIPでは、SIP-URIからIPアドレスを知るためにP2P技術を利用しており、従来からあるSIPサーバを不要にできる。アドレス解決以外の、接続・切断のシグナリング、音声データのストリーミングに関しては、従来からのSIPやRTP/RTCPの技術をそのまま利用している。


応用例:IP電話、Skype、LINE、MSN メッセンジャー、P2P-SIP、P2Pグループウェア。



放送型


ノード間接続を、カスケード状に多段階層化して、配信ツリーを形成することで、放送型のサービスが実現できる。ツリーの根元のノードが、放送局となり、上流ノードから下流ノードへ、データをバケツリレーさせることで、全参加ノードに、ほぼ同時に同じデータを配信することが出来る。これにより、リアルタイムのストリーミング中継が可能となる。




オーバーレイマルチキャストの配信ツリーの概念図


多くのP2P型放送システムでは、アドレス解決にハイブリッドP2P方式(後述)を採用しており、通常、チャンネル名でインデックスサーバに問い合わせると、「あのノードの下流につながってストリームをもらいなさい」というようにノードを紹介してくれる。インデックスサーバの役割を各ノードに分散させる(=ピュアP2P型OLM)ことも可能ではあるが、そのような実装例はまだ発表されていない。


上流ノードが脱退したときに、ストリームが途切れるが、内部にバッファを持つことで、一定時間は再生が途絶えないようにして、その間に、別の上流ノードを探し出して、再接続を行う。再接続の処理には時間がかかるため、通常、予備の上流ノードを用意しておく。再接続先候補のノードを、効率的に準備しておくために、様々な創意工夫が考案されている(詳細は、オーバーレイマルチキャスト or アプリケーションレイヤマルチキャストを参照)。


応用例:P2P放送(映像+音声、音声のみ); (PeerCast[9][10][11][12])



オンデマンド型


動画コンテンツの配信などでは、コンテンツを欲するノードが、当該コンテンツを持っているノードを探し出して、そこへデータを要求することで、保持ノードがそれに応じてデータを送信する(オンデマンド)、という一方向型の通信が行われる。言い換えると、持っている者から欲する者へ、という通信である。送信元は、持っている端末が複数ある場合、どれからでも良くて、不特定多数の中からアプリケーションまかせで選ばれる。送信元のIPアドレスは、コンテンツのタイトルなどを手がかりに、インデックスを検索して見つけ出し、コンテンツ保持ノードにデータ送信を要求することで、データ転送が開始される。


オンデマンド型のP2Pアプリケーションでは、配信効率を上げるために、コンテンツのコピー(レプリカ)を作ることが良く行われる。一度取得したコンテンツのコピーを保持して、他のノードに対して提供可能な状態にすることで、他の誰かが再度同じコンテンツをリクエストしたときに、負荷分散の効果が期待できるからである。これは特に、人気のあるコンテンツに対してのアクセス集中の緩和に効果的である。レプリカを作るアプリケーションでは、通常、レプリカをキャッシュフォルダ内に作り、古いレプリカから追い出すような実装になっていることが多い。


オンデマンド型のP2Pアプリケーションでは、データ全体を、一旦リクエストした端末までは持ってきてから利用する「ダウンロード方式」の実装がほとんどである。


応用例:P2Pコンテンツ配信、P2P掲示板、P2Pグループウェア、P2P分散ファイルシステム、無線のアドホックネットワーク、ゲームソフトのアップデート[13]



分散型データ管理


ビットコイン、Ripple (支払いシステム)などでは、通貨の取引履歴情報を、各ノードで分散して持つことによって、通常はサーバで管理する台帳データの不正な改竄を防ぐことができるので、P2Pを利用している。これにより自分のノードの台帳データを改ざんしたとしても、他の多数のノードが正しいデータを保持していることにより、比較した際に改竄を検知することができる。



技術的な分類



インデックス情報の持ち方での分類


「こういうデータを持っているのは誰ですか?」という問いに答えるためには、データを検索するための属性キーとデータのありかの対応表(インデックス)を持っている必要があるが、これをサーバに集中して持たせる場合と、各ノードに分散して持たせる場合と、特定の選ばれたノードに分散して持たせる場合、の3種類が存在する。





ハイブリッドP2P




ハイブリッドP2Pの仕組み(図はBitTorrentのもの)。
欲しい情報となるキーファイルをサーバーに伝え、実際のデータはノード同士でやりとりを行う仕組み


ハイブリッドP2Pにおいては、インデックス情報を、中央のインデックスサーバで一括して管理する。新しいデータを保持したノードは、自分が持っていることを、インデックスサーバに申告しておく。データを欲するノードが、「このキーに対応する相手を教えて下さい」とインデックスサーバに問い合わせると、対応する相手のIPアドレスを教えてくれる。インデックスが膨大になると、スケーラビリティが無くなる点が、後述のピュアP2Pと比べて劣るが、通常規模のシステムであれば、この方式で事足りるケースが多い。インデックスサーバがダウンすると、システム全体が停止するため、耐障害性の面では、ピュアP2Pに劣る。


BitTorrent、Napster、WinMX、放送型P2P(OLM)の多くは、この方式を採用している。





ピュアP2P




ピュアP2Pの仕組み。一切の処理をコンピューター同士が対等に通信を行うのが特徴である。


インデックス情報は、各ノードが少しずつ分散して持ち合う。
自分の知っているノードに、「データを持っているのは誰ですか?」というメッセージを投げると、そのノードが知っていれば回答が返り、知らなければ又聞きをしてくれる(メッセージを転送する)仕組みになっている。インデックスが膨大になっても破綻しないため、スケーラビリティが高い。メッセージ転送の方式により、非構造化タイプと構造化タイプの2つに分類できる(後述)。


Gnutella、Freenet、OceanStore、Winny、Share は、この方式を採用している。


ピュアP2Pに参加する際には、既に参加しているノードのIP情報を何らかの形で知っている必要がある。このためには、常に活きているノード(コンタクトノード)を用意しておいて、参加時はいつもそこに接続するようにするか、あるいは、参加しているいくつかのノードの情報をサーバに集めて、ここから知るように構成する。





スーパーノード型P2P


インデックス情報は、特定の選ばれたノード(スーパーノード)が分担して持つ。スーパーノードには、できるだけ安定な端末(ずっと電源が入っていて、通信回線も安定していて、帯域幅も太いようなノード)が選ばれる。スーパーノードは、一般のエンドユーザの端末から能力に応じて選ばれるが、サービス提供者側が用意した端末であることも多い。


KaZaA、Skypeは、この方式を採用している。



ピュアP2Pの構造による分類


ピュアP2Pにおいては、インデックス情報も分散されて持たれるため、相手先IPアドレスの発見の仕組みは、検索メッセージを転送することで行われる。転送方式で、2種類に分類ができる。



非構造化オーバーレイ

問い合わせ元のノードは、キーに対応する相手を発見するために、手当たり次第に、自分が知っているノード(かつて通信をしたことがあるノードなど)に対して、「データを持っているのは誰ですか?」というメッセージを投げつけ、受け取ったノードは、持っていれば返答し、持っていなければ検索メッセージをコピーして、他のノードに転送する方式。メッセージがネズミ算式に増えるので、フラッディング方式(洪水という意味)という別名が付いているが、メッセージが増えすぎないように、転送回数やメッセージの生存時間などで制限をかける必要がある。そのため、OLN上のどこかに相手が存在するにも関わらず、発見できない場合がある。


Gnutella、Freenet、Winny、Share などで実装されている。

構造化オーバーレイ

「データを持っているのは誰ですか?」というメッセージを転送する際の、転送先を選ぶ方法をあらかじめ構造的に決めておいて、「キーに対応する相手」が確実に分かるようにした方式である。よく知られている方式として、DHT(Distributed Hash Table)、SkipGraphなどがある。検索メッセージの転送先の範囲が、キーに応じてだんだんと絞られていくように設計されている。概略イメージは、A県の中のB市の中のC町の中の田中さん、というように範囲を絞る形で、メッセージが転送される、と考えると理解がしやすい。

DHTの実装例としては、Chord、CAN、Pastry、Tapestry、Kademlia、OpenDHT、Overlay Weaverなどがよく知られている。



P2Pノードの一般的な機能


P2Pに参加するノードには、以下のような機能が必要となる。ソフトウェアで、これらの機能は実現できる。



参加処理

オーバーレイネットワークに参加するためには、OLNに既に参加しているノードを知っている誰かと、通信を行う必要がある。このノードをコンタクトノードと呼ぶが、そのIPアドレスは、参加前になんらかの方法で知っておく必要がある。コンタクトノードは、常時稼働していることが望ましい。ハイブリッド型P2Pでは、インデックスサーバが、コンタクトノードの役割も果たしている。参加処理では、コンタクトノードに参加の意志を伝える。すると、すでに参加している別のノードのIPアドレス情報が返送されるので、OLN上の他の誰かと通信ができるようになる。

脱退処理

行儀良く「抜けます」と言ってから抜ける場合と、何も言わずに抜ける場合がある。いきなり電源を切ったり、LANケーブルを抜いたりすると、後者となるので、これを想定した設計とする場合がほとんどである。しかし、脱退通知を行ってから抜けた方が、システムは安定するので、通知が可能な場合は脱退通知を行うように実装することが望ましい。ハイブリッドP2Pでは、インデックスサーバに対して、脱退通知を行う。ピュアP2Pでは、自分が知っている他のノードに対して、脱退通知を行う。脱退通知を行わない場合(行えない場合)は、通常、周りのノードとKeep-Aliveメッセージを定期的に交換しておくという手法を採る。これがなくなることを周りのノードが判断することで、脱退が認識される。

冗長化

通信相手がいきなり居なくなることを想定して、通信相手の予備候補を常に用意しておくことが重要になる。

例えば、フラッディング方式の場合は、自分の知っているノードすべてにメッセージを重複して投げており、どこかで通信エラーが起きても、複数のメッセージのうちのどれかが通れば、後の処理が続くようになっている。DHTの場合は、メッセージのルーティング経路が複数あるように設計されている。コンテンツ配信の場合は、希望のコンテンツのレプリカを持つノードが常に複数存在するように、キャッシュフォルダ内にレプリカが配置されるように設計する。OLM/ALMの場合は、上流接続を複数持たせてメッシュ状のネットワークを構成しておくような設計が、多く見受けられる。

このように、P2Pの方式やアプリケーションごとに、様々な冗長化が工夫されている。

データの取得と提供(転送)

自分が他ノードからデータを受けると同時に、他のノードに対してデータを提供する、という機能を持たせることが重要である。サーバにもなりクライアントにもなるということで、サーバント機能とも呼ばれる。

同時に複数の端末へデータを提供する機能を実装すると、システム全体でのデータ利用効率が向上する。この機能は、OLMでは必須となる。複数の端末から同時並行でデータを取得する機能を実装する(複数の端末から少しずつ部分データをもらって後で結合する)と、データ利用効率の向上、応答速度の向上、冗長性の向上などが期待できる。

その他

必要に応じて、以下の機能を実装する。

データの公開機能

「私はこういうデータを持っています」と、P2P網に対して宣言する。オンデマンド型のアプリケーションでレプリカをキャッシュさせる場合には、必須機能となる。

NAT越え機能

一般家庭でのブロードバンドルータを介して利用する場合は、NATにポートフォワード設定を行う必要があるが、これをP2Pアプリケーションが自動的に行うようにする。最近のほとんどのルータには、UPnP機能が実装されているため、これを用いて、P2Pアプリがルータにポートフォワードの指示を出すことができる。

データの暗号化、改竄防止機能

一般ユーザのPC上で、データの改竄が行われる恐れがあるため、これを防止する。

データのリモート削除機能

商用システムの場合、著作権管理の点で、管理者側からリモートでデータ削除を行いたい場合がある。





P2Pに対する誤解と技術的課題






P2Pの技術は、実用化されて間もないため、成熟した技術として使われるためには、いくつかの課題が残されている。
また、これまでのP2P技術は、ファイル共有ソフトによって注目されてきた経緯があり、P2Pを使っていると聞くだけで有害なソフトウェアだと思うような誤解を与えてしまうことがある。しかし、以下に示すように、多くの誤解はアプリケーションやP2Pソフトの実装上の問題であり、解決策が見えてきている。つまり、P2P技術自体は、うまく使えば非常に有用な技術である。



意図しない情報の流出・混入の危険性(誤解1)


ファイル共有ソフトを初めとするオンデマンド型アプリケーションには、自分のPC上のデータを公開できる機能が付いているものがある。しかし、これによって、ユーザが意図しないデータ(極秘情報やプライベートデータなど)が流出する恐れがある。特に、WinnyやShareでは、ウイルスによりこの機能が利用されて被害が広がり、大きな社会問題となった。

対策としては、管理者の検閲を経てからの公開や、ウイルスチェックプログラムの利用徹底、利用者にアップロードファイルの確認を求める実装、などが有効である。その一方で、商用のP2Pシステムでは、元を絶つという意味で、ユーザの手元データの公開機能自体を実装せずに、正規コンテンツは管理者だけしか投入できない仕組みとする方向に動いている。

共有データの削除が困難(誤解2)

Winny利用のウイルス問題で有名になったが、一度P2P網に公開されると、削除するのが難しいという問題がある。しかし、これは単に、Winnyに共有データを削除する機能が実装されていなかったためである。最近の商用のP2Pシステムでは、管理者によるリモートでのインデックス削除とデータレプリカ削除機能が実装されている。

データの改竄の危険性(誤解3)

オンデマンド型アプリケーションでは、データのコピー(レプリカ)をキャッシュフォルダ内に持つケースが多い。しかし、一般ユーザが、いたずら目的でこのファイルを改竄する恐れがある。これへの対策としては、ファイルにハッシュコードや電子署名を付けることで、改竄の検出ができる。改竄が検知されたファイルは、P2Pソフトがすみやかに廃棄することで、不正ファイルの伝播を防止できる。

ISPの帯域制限


ファイル共有ソフトの利用の広がりにより、インターネットのバックボーンは、トラフィックのほとんどがファイル共有ソフトで食いつぶされる、という事態が起こっている。これに対して、多くのISPは、一般ユーザの利用帯域を制限するという対応に出ている。あまりに多くのトラフィックを使うユーザには、利用制限をかけようという動きである[14]。P2Pのフォーマルな利用に当たっても、この制限は課される場合があるため、P2Pアプリケーションの利用に制限が出る恐れがある。対策としては、ISP側が、WinnyやShareなどの問題があるソフトに関してのみ帯域制限をかけるようにすること、あるいは、ユーザの料金体系を従量制にすること、などが考えられる。

NAT越え問題

ほとんどの一般家庭では、インターネットへの接続にブロードバンドルータが使われている。しかし、P2Pソフトが外部からのIPパケットに対して接続を可能にするためには、ルータの中のNATに、ポートフォワードの設定を施す必要がある。これを通称、NAT越えと呼ぶ。ファイル共有ソフトでは「ポート開放」と呼ぶことも多い。ユーザが手動で設定することも可能ではあるが、専門知識が必要になることから、P2Pソフトから自動的に設定を行うようにすることが望まれる。これには、UPnP、STUN、UDPホールパンチングなどの利用が有効であるが、古いルータの中には対策が難しいものもあり、100%のNAT越え成功率を達成するのは困難である。

また、企業内のLANで、外部とのP2Pを行う場合は、セキュリティレベルの高いファイアーウォールを越える必要があるが、こちらの場合は、P2Pソフトによる自動対応は非常に難しく、手動でのポートフォワード設定に頼るしかないのが現状である。

将来的には、IPv6が普及して、各端末に個別のグローバルIPアドレスが付与されるので、一般家庭、企業内LANともに、NAT越え・ファイヤーウォール越えが不要になるのでは、という見方があるが、セキュリティ的な見地から、ファイアーウォールとしてのIPパケットフィルタは何らかの形で設けられるであろうことから、これをどのように越えるかが課題である。これを自動化することは、技術的には可能であるが、セキュリティの確保と利便性の向上は常にトレードオフの関係になり、ちょうど良い頃合いを見定めるのに、しばらく時間がかかりそうである。

また、IPv4アドレスの枯渇問題への対応として、ISPにラージスケールNATを設置するという計画が進行中である。これは各ユーザに対して、プライベートIPアドレスを配布するという物であるが、P2Pに取っては大きな問題であり、すべての端末間で自由にピア接続ができるようになるかどうかは、注視が必要である。

キャッシュの有効利用

オンデマンドタイプのP2Pアプリケーションでは、ユーザの端末内にキャッシュを多く持たせれば持たせるほど、配信効率が向上する(具体的には、特定ノードへの集中が起きない、データ取得に時間がかからない、など)。しかし、ユーザPCの限りある資源であるメモリーやHDD容量をどれだけ確保させてもらえるか、とのトレードオフとなり、ユーザの理解を求めながらユーザがどれぐらいの性能を欲するかを見極めるという、微妙なバランスを模索していく必要がある。

ネットワークのコストが最適な端末を選ぶ技術(P4P)[15]

データを持っているノードが複数ある時、どのノードを選ぶと、ISPや通信キャリアに取って都合がよいか、インターネットのバックボーンに負担をかけないか、という観点での技術開発が行われている。

例えば、北海道-札幌のユーザが何かのデータをリクエストして、データを持っているノードが、鹿児島、北海道-旭川、東京、に見つかったとき、旭川のノードを選ぶのが、北海道-東京間の回線を使わなくて済むので、多くの場合好ましいだろう。しかし、通信キャリアの立場から見ると、実は東京への回線のほうが帯域に余裕があって、こちらを使って欲しいという状況もあり得る。

このような通信インフラのコスト構造の実体に合わせたノード選択手法の必要性が、クローズアップされてきている(P4P=Proactive network Provider Participation for P2P)。



脚注





  1. ^ P2PSIP


  2. ^ P2P@i


  3. ^ アプリケーション層マルチキャスト


  4. ^ P2P調査


  5. ^ NEC P2PWeb


  6. ^ 下位アルゴリズム中立なDHT実装への耐churn 手法の実装


  7. ^ 「BBブロードキャスト導入事例


  8. ^ SkeedCast


  9. ^ PeerCastStation


  10. ^ シェアキャスト


  11. ^ 「BBブロードキャスト


  12. ^ UG live視聴ページ


  13. ^ コナミのゲームソフト、METAL GEAR ONLINE 2のパッチ配布にはBitTorrentの技術を用いて行っている


  14. ^ ISPの規制情報


  15. ^ P4PによるP2Pの効率化




関連項目


  • P2P共有


  • Antinny

  • Cabos

  • Freenet

  • Gnutella

  • LimeWire

  • Perfect Dark

  • Profes

  • Real Time Media Flow Protocol

  • Ripple

  • StealthNet

  • Tor

  • WinMX

  • 新月_(掲示板)

  • 分散コンピューティング

  • ファイル共有ソフトウェア



外部リンク



研究資料



  • PAST distributed storage utility

  • CoopNet cooperative content distribution system

  • More peer-to-peer research resources

  • P2Pとは何か?~基礎から研究紹介まで~

  • オーバレイ構築ツールキット



P2P関連情報サイト



  • ネットワーク高度利用推進協議会シンポジウム「商用P2P、クラウド、キャッシュを活用したネットワーク効率化最新動向」の開催について

  • P2P関連問題研究会 P2P基本提言

  • P2Pのこれまでとこれから : ネットワーク高度利用推進協議会活動の歴史とともに




Popular posts from this blog

'app-layout' is not a known element: how to share Component with different Modules

android studio warns about leanback feature tag usage required on manifest while using Unity exported app?

WPF add header to Image with URL pettitions [duplicate]