Peer to Peer（ピアトゥピア、ピアツーピア）とは、多数の端末間で通信を行う際のアーキテクチャのひとつで、対等の者(ピア)同士が通信をすることを特徴とする通信方式、通信モデル、あるいは、通信技術の一分野を指す。P2Pと略すことが多い。

Peer to Peerに相対する用語として、クライアント-サーバ方式がある。これは、サーバのIPアドレスやURLが広く周知・公開されており、このIPアドレス、URLに対して、多数のユーザのクライアント（パソコンなど）がアクセスするという形態を取る。

これに対して、Peer to Peerは、一般ユーザの名もない端末装置（パソコンなど）に対して、他のユーザの端末装置が直接アクセスする、という点が大きな特徴である。

クライアント-サーバ方式では、端末数が非常に多くなるとサーバ装置・回線の能力不足が起きるのに対して、Peer to Peer方式は、端末数が膨大になってもサーバへのアクセス集中が少ないという特徴があるため、ここ数年、商用的にも注目を集めており、特にIP電話や動画配信サービスなどへの応用例が増えてきている。

さらにPeer to Peer方式には、（通信を行うソフトウェアや通信プロトコルなどに左右されつつも、）発信者の匿名性がある程度確保できるという特徴があり、Winnyに代表されるようなアンダーグラウンドな用途でも利用が多い。

以下、本文中では、P2Pと略記する。（英語で「2」が"two"であるため、発音の似通った"to"を「2」で置き換えた簡略表記）

P2P技術の応用範囲は非常に広く、P2Pデータ配信、P2P電話、P2P掲示板、P2P放送(テレビ、ラジオ)、P2Pグループウェア、P2P分散ファイルシステム、P2P-SIP^[1]、P2P-DNS、P2P-仮想ネットワーク^[2]、P2P地震情報、など、多くの適用例が生まれつつある。が、歴史的にはまだ日が浅く、西暦2000年頃から実用化された技術で、成熟技術となるまでには、まだクリアしなければいけない様々な問題がある（後述）。

無線通信で使われるアドホックネットワークも、P2Pの一種であるが、無線での通信可能距離を稼ぐという特有の使い方であるので、詳細な解説は別項に譲る。

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

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

[編集] オーバーレイネットワークとしてのP2P

今日のインターネットを支えているIPネットワークは、基本的にP2P方式を念頭に置いたネットワークである。IPアドレスさえ分かっていれば、誰にでも到達でき、ピアとピアで通信ができる。

従って、実際のP2Pでは、どのように相手のIPアドレスを知るか、が重要なポイントとなる。昨今のP2Pでは、例えば、コンテンツのタイトルや検索キーワード、放送局のチャンネル名といった、人にとって意味のある名前で通信相手を特定して、通信ができるようになっている。 この意味で、P2P方式での通信網は、オーバーレイ・ネットワーク(Overlay Network)と見ることができる（以下、OLNと略記する）。 通常のIPネットワークの上に、もう一層、別のネットワークを、特定のニーズに合うノード同士で作り上げる、という意味合いである。

もう少し具体的に言うと、例えばWinnyでは、「欲しいコンテンツの名前」で「そのキャッシュを持っている相手」を特定して通信をおこない、例えば、Skypeでは、「ニックネーム」で「ニックネームに対応する相手」を特定して通信をおこなう。一般化すると、「キー」を手かがりに「キーに対応するデータを持つ者」を発見して、その相手と通信をする、という動作になる。「キー」と「データ」をペアで結びつけた情報をインデックス情報と呼ぶ。通常「データ」は、そのデータを持つ者のIPアドレスとして記憶させる。（インデックスは、key-valueペアという呼び方をする場合もある。） P2Pでは、インデックス情報をどのように管理するかが重要となる。

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

[編集] メリット、デメリット

P2P方式の通信には、以下のようなメリットとデメリットがある。

ここで、iはnwlink.vxdファイルを置いていない

[編集] メリット

スケーラビリティ

昨今、P2P方式が注目されている最大の要因は、スケーラビリティの高さにある。クライアント-サーバ方式では、クライアントの数が増えていくと、サーバの負荷もそれに比例して増えていくため、クライアント数が膨大になったとき、サーバの処理能力、あるいは、サーバにつながっているネットワーク回線の能力が限界に達して、実用的な配信ができなくなるという問題がある（スケーラビリティが低い）。特に、動画データの配信を行う場合など、サーバから送るデータのサイズが大きい場合に、問題が顕著になる。これに対して、P2P方式では、サーバを使わない（あるいは一部の機能にしかサーバを使わない）ため、ユーザ数が膨大になっても、配信が可能になる、という点が大きなメリットである。いわば、ピアの装置と回線� �、サーバの肩代わりをしてくれているわけである。

コスト

スケーラビリティの高さから当然導かれる特長として、センターサーバ設備を、低コストで構築、運用できるというメリットがある。クライアントサーバ方式に比べて、サーバ装置に高性能な物を用意しなくて済むし、通信回線も通信帯域幅の細い安価な回線で済む。これは、端末数が増えれば増えるほど、顕著な差となる。一般的に、クライアントサーバシステムを運用する際に、一番コストがかかるのがサーバの回線費用であり、これを格段に安価にできる。

耐障害性

クライアント-サーバ方式では、サーバがダウンすると配信システム全体が停止するが、P2P方式では、単一障害点を減らすことができるので、耐障害性が向上する。特に、ピュアP2P方式のシステムでは、サーバに頼る箇所が少なく、たとえサーバ部分が故障しても、ピアのキャッシュにあるデータに関しては配信が続行できるため、この効果は顕著であり、ノード数が多くなればなるほど、システムの耐障害性が向上するという特徴がある。

匿名性

P2P方式で、データの中継転送を数多く行えば、誰がそのデータを公開したかを突き止めることを、非常に困難にすることができる。Winny、Share、Perfect Dark などの、アンダーグラウンドなP2Pシステムでは、著作権を無視した違法なコンテンツの公開を、誰が行ったかを隠蔽するために、匿名性が重要視される^[4]。これは、管理をする立場から見るとデメリットになるわけで、逆に、商用のP2Pシステムでは匿名性は排除して、トレーサビリティを重視した実装を目指す場合も多い。誰がいつどういうデータを送受信したか、までトレースできるようになっているシステムも模索されている^[5]。

また、言論の自由という観点から、匿名性を持たせたP2P掲示板システム（新月など）も注目されている。

[編集]

人々は、SAPのバージョン6で言う

88">デメリット

実装の困難さ

実装の難易度が高い。

特に、エンドユーザの端末がPCである場合には、その電源オン期間が不確定な場合が多く、端末の頻繁な脱退や長期の不在期間を考慮したアルゴリズムが必要になる。参加脱退が激しいノードが居ることに対してどう対処するかは、「Churn問題」という呼び方をする^[6]。P2P方式は、クライアントサーバ方式に比べて、信頼性が劣るイメージがあるが、逆に、このChurn問題への対応策を取らざるを得ないことにより、自ずから耐障害性が高いシステムが出来上がるという側面もある。

端末がPCである場合は、各PCの処理能力、転送能力、保存容量などの条件が千差万別であり、できるだけ多くの種類のPCで動くようにするには、注意深い実装が必要になる。

動作確認の困難さ

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

削除制御の困難さ

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

ただ、最近の商用のP2P配信システムでは、管理側からリモートで削除ができる仕組みを、あらかじめ実装しておくことで、この問題は克服されつつある^[10]。

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

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

インターネットへの負荷

昨今のインターネットのトラフィックの中身を解析すると、そのほとんどがファイル共有ソフトの物であることが、問題視されている。これ自体は、利用者のニーズがあるために発生している結果であり、使いたい人が多いのであれば、通信キャリアやISPとしてはインターネットを強化していくべきものであるが、問題は、次項に掲げたように、この負荷と料金が経済的に折り合っていないことである。

ISP、通信キャリアの料金体系とのミスマッチ

現状の通信キャリアやISPの間の通信料金体系は、インターネットをクライアントサーバモデルで利用することを想定している。すなわち、一般ユーザは、さほど大きなトラフィックを使うことはないので、使いたい放題の固定料金体系とし、一方、コンテンツを提供する業者は、サーバを設置して太い回線を使うので、これらの業者から比較的高い料金をもらうという構造である。また、各ISPや通信キャリア会社の間では、インターネットの階層(Tier)の上下関係、および、IPパケットの通過量に応じて、従量制のトランジット料金のやりとりが行われている。

ここにP2P方式のアプリケーションが増えてくると、当初想定していなかったような量のデータが一般ユーザのPCから送受信され、大きなサーバを設置していない地区のネットワークから大量のトラフィックが発生し、ISPのルータに負荷がかかったり、ISP間のトランジット料金のバランスが実体トラフィックと合わなくなるなど、料金体系を考えたときの目論見が外れて、様々なコスト上のアンバランスが生まれる。ただこれは、料金体系の改訂が、利用状況に追いついていないために生じている問題であり、時間が解決するものと思われる。

環境への負荷

通常P2Pはサーバを設置しないため環境負荷が低いと思われがちだが、ファイル共有ソフトを使用する場合は主に使っているパソコンの他にP2P用のパソコンを用意した方が無難なため、ファイル共有目的だけ見ればパソコンの台数は倍になる計算になる。またクライアント型では受信したいときだけパソコンを起動していれば良いがP2Pでは常に起動している必要が有ることも要因となる。

ただしこの問題は規模や用途により異なるので一概に環境負荷が高いとは言えないので注意が必要。(チャットなどの用途では環境負荷は低くなることが多い)

[編集] P2Pアプリケーションの分類

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

1. 一対一通信型
2. オンデマンド型
3. 放送型

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

[編集] 一対一通信型

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

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

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

microsftは、仮想サーバ環境をサポートしてい

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

[編集] オンデマンド型

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

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

オンデマンド型のP2Pアプリケーションでは、データ全体を、一旦リクエストした端末までは持ってきてから利用する「ダウンロード方式」の実装がほとんどであるが、中には、動画コンテンツ先頭の一部分を持ってきた早いタイミングから再生を開始する「ストリーミング方式」の実装^[10]も見受けられる。

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

[編集] 放送型

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

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

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

応用例：P2P放送(映像＋音声、音声のみ); (PeerCast^[15]他^{[16][17][18][19]})

[編集] 技術的な分類

[編集] インデックス情報の持ち方での分類

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

[編集] ハイブリッドP2P

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

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

[編集] ピュアP2P

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

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

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

[編集] スーパーノード型P2P

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

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

[編集] ピュアP2Pの構造による分類

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

非構造化オーバーレイ

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

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

構造化オーバーレイ

「データを持っているのは誰ですか？」というメッセージを転送する際の、転送先を選ぶ方法をあらかじめ構造的に決めておいて、「キーに対応する相手」が確実に分かるようにした方式である。よく知られている方式として、分散ハッシュテーブル(Distributed Hash Table, DHT)、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は、一般ユーザの利用帯域を制限するという対応に出ている。あまりに多くのトラフィックを使うユーザには、利用制限をかけようという動きである^[20]。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)^[21][22]

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

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

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

[編集] 関連項目

[編集] 外部リンク

[編集] 研究資料

[編集]

These are our most popular posts: