自律分散協調システム論第12回「Peer-to-peer systems」中村修 [email protected] クライアントサーバモデル • インターネット上の通信の基本モデル • 2種類のコンピュータ（明確な役割分担） – サーバ : サービスを提供するコンピュータ – クライアント : サービスを受けるコンピュータクライアントサーバあるポート番号でクライアントからの要求を常に待ち受けているプログラムクライアントプログラムクライアントサーバプログラム必要なときにサーバプログラムと通信して要求を送るプログラムクライアントサーバはSingle Point of Failure • ボトルネック – サーバの計算能力 – ネットワーク帯域アクセスの集中による回線の飽和 • ボトルネック解消のアプローチ – ロードバランサの利用 – キャッシュ/CDNの利用 – P2Pモデルの導入 Server サーバのダウン Clients 例(1/4) : IRCの負荷分散方法 • IRC(Internet Relay Chat) – サーバを分散し連携処理させる手法 • 一つサーバに処理が集中しない – RFC1459 Client 1 Server 1 Server 2 Hi! グループに1,2,3が加わってる場合 Hi! Server 4 Client 2 Server 3 Hi! Client 3 Server 4にはグループに加わったクライアントがないためメッセージはこない Client 4 例(2/4) : ロードバランシング • 同じIPアドレスで複数のサーバが反応 • ラウンドロビン、URLで、重み付け、負荷、コネクション数、反応速度などで割り振る • 利点コネクション要求 – CPU負荷を軽減できる • 問題点 – 負荷分散装置が必要 – ログが分割される – メンテナンス負荷は高くなる負荷分散装置例(3/4) : DNSラウンドロビン • 同じ名前で複数のサーバが登録されている • 物理的に別の場所で処理 • www.asahi.comなど www.asahi.comどこ？ www.asahi.comどこ？ Client 2 • 利点 – 回線資源を分散利用できる • 問題点 – 均等に負荷が分散されない – 落ちているサーバにも振る – Cacheがあるためタイムラグがある 209.249.129.20だよ 210.80.197.158だよ Client 1 209.249.129.20 Wwwld2.asahi.com 210.80.197.158 Uunet3.asahi.com 例(4/4） : CDNを利用した負荷分散 • Accelia Durasite http://www.accelia.net/japanese/news/12.html – ファイルを広域に分散しネットワーク負荷を分散 • Akamai http://www.akamai.com/ – クライアントに一番近い、最適なキャッシュを探す – サーバのかわりにキャッシュがクライアントに応答 Cache Servers キャッシュを拠点に置きアクセスを分散させる Server • 利点コンテンツの配置 – CPU資源の分散 – 回線資源の分散 Clients P2Pとは？ • Peer-To-Peer – Peerとは端末ノードのこと (中継ノードではない) – Peer(端末)とPeer(端末)が 1対1で直接対等な立場での通信形態 – 代表的なアプリケーション • ファイル共有・交換・配信型 – Napster • コラボレーション型 – Groove • 分散コンピューティング型 – SETI@home • 特徴 – 耐故障性の実現 – 資源分散が可能 – 自由なランデブーコミュニケーションとは？ • • • コミュニケーションには主体がある。 P2Pではこれらは対等のものとしてpeerと呼ぶ。誰かとコミュニケーションをとるためには、まずその主体同士が、 1. 相手を発見・識別する 2. コミュニケーションを開始する 3. コミュニケーションを終了する ……という手順が必要になる相手の発見と識別コミュニケーションの開始コミュニケーションの終了クライアントサーバ、P2Pモデルの比較クライアントサーバハイブリッドP2P 中心 : Server ピアピュアP2P 中心 : Server ピアピアランデブーも通信も中心で行うランデブーを中心で行い、通信をピア同士で行うランデブーも通信もピア同士で行う WWWなどのインターネット上の大部分のアプリケーション Napster MSN Messengerなどの主要IM Gnutella ,Freenet, Winny 身近なＰ２Ｐアプリケーション • ファイル共有 – – – – – – – – Napster Gnutella Morpheus WinMX Winny Share GNUnet BitTorrent • ストリーミング – PeerCast – Joost (Skype) • インスタントメッセンジャー – – – – MSNメッセンジャー ICQ、Jabber 3degrees、Skype Groove、Ariel AirOne • 資源分散 – OceanStore – SETI@home – HyperBee • ネットワークゲーム – Diablo – Age of Empire ファイル共有: P2Pモデルの代名詞 • ファイル共有アプリケーション – ファイルの公開・検索・転送を実現する – WWWとの比較(登場人物と役割は？) • 公開：WWWサーバへのアップロード • 検索：検索エンジン • 転送：ブラウザによるページの取得 • 自律的なコミュニケーションとしてどう実現するか – オリジナル・ファイルは各Peerが分散して保有 – ネットワーク上に分散したファイルからの検索 – ファイルの転送 • 中継転送、キャッシュの利用 • 直接転送 P2Pシステムの台頭 • 第1世代P2Pシステム (Hybrid P2P) – Index Server を利用した情報探索 – データの転送はノード間で実行される • 第2世代P2Pシステム (Pure P2P) – Index Serverを必要としない • 第3世代P2Pシステム – さらにキャッシュ機能を有する第1世代P2P: Hybrid P2P model • 特徴 – ピアの管理・ファイルの管理をIndex Serverが行う • Index Serverは検索・発見のためのインデックスを管理 – 所持ファイルの一覧をサーバに送信 – 検索条件をサーバに送り、結果をもらう – 公開されているファイルをサーバが制御できる – データの送受信はピア間で行うインデックスサーバファイルの検索自分の持つファイルを登録ファイルを取得第1世代P2Pの特徴 • 利点ハイブリッドP2P – サーバ・クライアントモデルにおけるサーバへの負荷集中を分散により軽減できる • 欠点中心にインデクッス・サーバが存在 – Index Serverが負荷集中点となるピアインデックスサーバに障害が発生すると、システム全体が停止する例： MSN Messenger サインイン時の通信ファイルの送受信メッセージの送受信サーバ・セッションの開始・コンタクトリストメッセージサインイン情報メッセージファイル転送例: Napster • Napster – Napster社のファイル共有ソフト – 2000年7月に音楽関係団体に提訴をされ、サービス差し止め第2世代P2P: Pure P2P model • Index Serverを用いないデータ共有 – Index Serverに対する負荷集中の分散 – 耐故障性 • 異常ノードの役割を他ノードが引き継ぎ可能 – 資源分散 • 計算機資源・ネットワーク資源の分散 – ただし，サービス管理が困難となる • Index Serverがあれば，ノード管理・データ管理が可能 P2Pモデルとオーバーレイネットワーク • オーバーレイネットワーク（P2Pネットワーク） – Pure P2P modelを実現するためのネットワーク – 一般にアプリケーション・サービス毎に構築される – ピアが協調することにより自立的に管理・構築されるサービスA サービスB トポロジを考慮しないデメリット • IPネットワークのトポロジとの分離 – 自分がピアを張る相手ノードの地理的（ネットワーク的）な接続関係は考慮しない • 実は相手は地球の裏側かも…… – 実際に転送できる帯域が細い！ – 返事が返ってくるのが遅い！ Pure P2P modelにおけるデータ検索 • インデックスサーバが存在しない – ノード情報を取得するための仕組みが必要 • IPアドレス、URI、ファイル情報などなど • 情報の検索方式による分類 – Unstructured Overlay Network • Floodingによりデータを見つけ出すモデル • 例：Gnutella, Winny など – Structured Overlay Network • Index Serverの機能をOverlay Networkノードの協調で実現 • Distributed Hash Table Gnutella • 自律的に参加するPeerの集合体 – – – – Index Serverに依存しない P2Pネットワーク上で検索要求を転送(TTLは最大7) 検索者が積極的にファイルを探しに行くファイルの所持者は受動的持ってないよ！持ってないよ！持ってないよ！持ってないよ！持ってないよ！持ってないよ！ Bさん Aさんあのファイルが欲しい… 皆に聞いてみよう！もってるよ！送るね！ Winny • Pure P2P model – Index Serverに依存せず • 堅牢性の実現 – 中継したキャッシュを再公開 • 高い匿名性 – 間接的な接続により、取得者には公開元が不明 – 暗号化により、中継者には通信内容が不明 • Winnyを悪用した犯罪行為が多発 – 知的所有権を侵害 – 摘発されにくかったが… Winny悪用による逮捕者とそのインパクト • 2003年11月27日に逮捕者がでた段階で日本中のトラフィックは2割減少した http://www.zdnet.co.jp/news/0311/27/nj00_winny.html http://www.mfeed.co.jp/jpnap/fr-traffic.html Winnyの悪用者が逮捕・製作者宅捜索 http://www.asahi.com/national/update/1127/035.html Winny: ネットワーク • ノードの持つネットワーク速度（自己申告）に応じて階層化より高速より低速 P2Pの鶏と卵問題 • 何も知らないピアがP2Pネットワークに参加する • 1つでもP2Pネットワークのノードを知らないと参加できない • P2Pネットワークに参加していればピアについて認知できる • 中心のないシステムの宿命オーバレイネットワークどうやってオーバレイネットワークに参加？ピア • Winnyでは「初期ノード」の登録を手動で行うことで解決ランデブーも通信もピア同士で行う Winny: 広告と検索 • 公開者がより積極的に広告を行う – 公開者は、ファイルの情報をP2Pネットワークを通じて隣接するPeerに広告 – 広告された情報と検索要求を各Peerが比較持ってないよ！持ってないよ！持ってないよ！ BさんのファイルをAさんが探してる！！ Bさんがあのファイルを持ってる Bさんがあのファイルを持ってる Cさん Aさん Bさんあのファイルが欲しい… 皆に聞いてみよう！このファイルを持ってることを皆に教えてあげよう！広告 Winny: ファイルの公開 • オリジナルファイルからキーとボディを生成 upload folder キー（ファイルの要約情報） file.ppt ファイルボディ（ファイルの本体） • キーに含まれる情報 – – – – ファイルサイズ更新時刻ハッシュ値ファイルの所在を表すIPアドレス・ポート番号など • ファイルの公開と同時にキーがネットワーク上を拡散 Winny: ファイルの転送 • Winnyでは中継転送とキャッシュを採用 – 第三者を介在する – 匿名性を実現 • Napster、WinMX、Gnutellaは相手に直接接続 – 公開者と検索者だけ転送が完結 Winny: 中継転送 • 中継転送 – P2Pネットワークでの中間のPeerが転送を中継 – 下の例では検索と広告を合致したCさんが中継転送 – 転送のパフォーマンスを犠牲にすることで、キャッシュを持つ Peerを増やし冗長性を確保 Bさんのファイルを中継してあげよう！ Cさん Aさん Bさん Cさんが持ってたんだね！私のファイル人気があって配るのが大変…… Winny: キャッシュ • キャッシュ – ファイルを取得したPeerや、中継転送したPeerがそのファイルの複製を第三者に自動的に再公開 – 耐故障性の実現(冗長性の確保) – 検索効率の向上中継したファイルを他の人にも配って良いよね！ Cさん Aさん Bさんこのファイルを他の人にも配ってあげよう！他の人も配ってくれると楽で良いね！ Winny: 中継転送とキャッシュによる匿名性 • 一度流れたデータを誰も消せないシステム – キャッシュとして多数のPeerに情報が残っている – ソフトの例：Freenet、Winny – 用途の例：P2P掲示板、ファイル共有 • 解決しなければならない問題 – 公開した元の人間の特定 – 法的に問題のあるコンテンツの転送を知らずに行えないようにする (ということが必要かもしれない) Bさんのファイルを中継してあげるね！ Aさん Cさん Bさん Cさんが持ってたんだね！中継したファイルを他の人にも配って良いよね！ Aさん Cさんこのファイルを他の人にも配ってあげよう！私が最初に公開したとわからなくなる！ Bさん Winny: ネットワークの上流と下流 • 能力の高いノードにキーとキャッシュが集まる高速なノードほどデータの流量が多い（処理に負荷がかかるがデータは大漁）キャッシュキャッシュキーキーキーキャッシュキャッシュキーキャッシュキャッシュキーキャッシュキャッシュキーより高速キーキーキーオリジナルファイルより低速キーキーオリジナルファイルキャッシュ低速なノードほどデータの流量が少ない Winny: クラスタリング • 検索嗜好のより近いものでグルーピング – より効率のよい検索が可能となる嗜好A 嗜好B 嗜好C 全体の輪の中からファイルを探索クラスタA クラスタB クラスタC 輪を絞ってファイルを探索 Unstructured Overlay Networkの問題点と解決手法 • Unstructured Overlay Networkの問題点 – ネットワーク負荷の増加 • Floodingを利用するために通信量が増加 – 全てのデータを確実に見つけられない • 検索対象が発見できない可能性がある • いくつかの解決手法 – Structured Overlay Network を利用する – P2Pネットワークの階層化 – アプリケーションの動作を工夫（Winnyの例） Structured Overlay Network • Unstructuredに比べ検索効率が高い – だいたい発見できる（としている） • 検索時のトラフィックの抑制を実現 • Distributed Hash Table （分散ハッシュ表）を利用 – 検索対象の発見を効率化する仕組み • ルーティングによって対象のデータを探索 – 検索対象を複数のノードで分散管理する仕組み • ハッシュ値とハッシュ関数 – 提案されているDHTプロトコル • Chord, CAN, Pastry, Tapestry, Kademlia, etc.. – DHTを実装しているソフトウェア • BitTorrent, Warez P2P, eMule, etc.. ハッシュ値とハッシュ関数ハッシュ関数ではA≠Bの場合、F(A)≠F(B）が成り立つ Wikipedia, Hash Function, http://en.wikipedia.org/wiki/Hash_table ハッシュテーブルとは • キーと値の組（エントリと呼ぶ）を複数個格納し、キーに対応する値をすばやく参照するためのデータ構造 Wikipedia, Hash Table, http://en.wikipedia.org/wiki/Hash_table DHTの特徴 • 利点 – flooding検索に対してのネットワーク的負荷軽減 – オブジェクトを漏れなく，かつ高速に探索することが可能 • 数10万ピアぐらいが限界だとされているが、DHTを使うと数10億ピアを探索範囲とすることが可能となる (Wikipedia: 分散ハッシュテーブル) • 欠点 – 実装が難解 • データの保持，データの分散，データの検索，とキーワードは様々 – データ検索の柔軟性がない • 完全一致探索しか行えない – 正規表現のような複雑な検索をDHTのみで実現することは困難 – これを解決するための研究は複数存在 DHTのアルゴリズム（代表的な例） • Chord – 円状スキップリスト • CAN – N次元トーラス • Kademlia, P-Grid – Binary Tree • Tapestry, Pastry – Plaxton Tree Wikipedia, Hash Table, http://en.wikipedia.org/wiki/Hash_table Chord • Creating Chord Ring N1 K54 SHA-1によるHash結果に基づき m-bitsのハッシュ値をアサイン N56 N8 N51 K10 N14 N48 N21 K24 N42 K38 N32 N38 K30 各担当ノードに配置 Chord • Lookup on Chord Ring（一番簡単なモデル） N1 K54 N56 発見 Lookup(K54) N8 Next Hop N14 Routing Table @ N8 N51 N48 N14 K54を発見するまで各ノードの経路表により順番にノードを探索 Next Hop N21 Routing Table @ N14 N21 この方法ではデータの発見に時間がかかりすぎる N42 N32 N38 Chord • Lookup on Chord Ring（探索の効率化） N1 K54 N51 Finger Table @ N8 Lookup(K54) N56 発見 N8 K54を発見するまで順番にノードを探索 N14 N48 N21 Finger Tableに基づき N42から探索を開始 N42 N32 N38 N8+1 N14 N8+2 N14 N8+4 N14 N8+8 N21 N8+16 N32 N8+32 N42 近隣ノードについてのノードリスト（経路表とは別に持つ） Kademlia • Creating Kademlia Tree – ハッシュキーを160bitsのハッシュ空間に配置 160bitsのハッシュ空間 11..11 1 1 0 0 1 1 0 1 1 0 1 0 00..00 0 1001 0 1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 Kademlia • Searching Kademlia Tree – ハッシュ空間からXORによりキーを探索 Lookup(1011) 発見 11..11 1011 00..00 1 1 0 0 1 1 0 1 1 0 1 0 0 0 1 0 1 0 1 0 0 1 1 0 1 0 1 0 1 0 Pastry • Example of Routing Table on node 83123456789abcdef0123456789abcdef 一致長 Node0 Node1 NodeD NodeE NodeF 0 0….. 1….. d….. e….. f….. 1 80… 81… 8d … 8e … 8f … 2 830.. self 83d.. 83e.. 83f.. 3 8310. 8311. 831d. 831e. 831f. ：：：：：： 831..e0 831..e1 831..ed 831..ee self 32 ・・・一致長の桁数の数字がNodeXに従って変化自身はself Pastry Lookup(d46a) • Searching with Pastry Algorithms 65a1 65a1とd46aのprefix一致長は0 経路表にd13dがあったので、転送 d13dとd46aのprefix一致長は1 一致 0 … 4 … 一致 f 0 0 1 … d 0 e f d13d 1 d421 2 2 3 3 d13d d461とd46aのprefix一致長は3 経路表にd421があったので、転送一致 0 1 2 … f 0 1 d421 一致 d421とd46aのprefix一致長は2 0 … 6 0 … 2 3 f 経路表にd461があったので、転送 d462 経路表にd462があったので、転送 d462 1 2 3 d461 d461 発見 DHT関連の論文 • Ion Stoica, Robert morris, David Liben-Nowell, David R. Karger, M. Frans Kaashoek, Frank Dabek, and Hari Balakrishnan, Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Aplications, IEEE/ACM Trans. Networking, Vol.11, No.1, p. 17-32, Feb. 2003. • Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Shenker, A Scalable Content-Addressable Network, In Proc. ACM SIGCOMM 2001, August 2001 • Antony Rowstron and Peter Druschel, Pastry: Scalable, decentraliszed object location and routing for large-scale peer-to-peer systems, Lecture Note in Computer Science, Vol.2218, pp. 329-350, 2001. • Ben Y. Zhao, John Kubiatowicz, and Anthony D. Joseph, Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing, Technical Report UCB/CSD-01-114, Computer Science Division, U. C. Berkeley April 2001, 55 • Petar Maymounkov and David Mazieres, Kademlia: A Peer-to-peer Information System Based on the XOR Metric, In Proceedings of IPTPS02, Cambridge, USA, March2002 Skypeと自律分散協調ファイル交換でないP2Pソフトウェアの例: Skype • 各ノードの自律性はどのようになっているか？ • 何を分散し、何を分散していないか？ • 分散しないことによって担保されているのは何か？ • Loginプロセスを中心に考察 Skypeとは？ • KaZaaの開発者によって開発されたVoIPクライアント • 音声通話とテキストメッセージングが可能 • MSN/Yahoo IMアプリケーションと以下の点で類似する – – – – 音声通話ができるテキストメッセージングができるカンファレンスができるバディリストを備える • 基本となるプロトコル、技術はまったく異なる SkypeのLook and Feelとできること • できること – 音声通話 – テキスト・メッセージング – ファイル送信 • ユーザ識別子 – Skype ID – 一意性のあるID – バディリストに登録できる • バディリストから選んで – 通話 – チャット – ファイル送信 Skype Network • Skypeの利用するオーバーレイネットワーク • 2種類のノード – Ordinary Hosts • Skypeアプリケーションが導入され、音声通話とテキストメッセージングに利用 • 普通はこれ – Super Nodes (SN) • • • • Skypeネットワークにordinary hostsが収容される端点 Global IP addressが利用できる十分なCPU、メモリ、帯域を備える自動的に選択される Skype Login Server • User namesおよびpasswordを管理し、ユーザの認証を行う • User nameがSkype名前空間内で一意であることを保証 • Skypeノードではないものの、Skype ネットワークの重要なエンティティである • ordinary hostsはログインの際、 super nodeに接続するだけでなく、 Skype login serverへも接続 Host Cache (HC) • オーバレイネットワークを構成するためにSkype Client (SC)内に記録更新される情報 – Super Node の IP address / port number – 少なくとも1つは利用できるエントリが無いと、動作しない – SCとして2日間動作すると、HCとして最大200エントリまで増えることが観測されている – Skype Node内のWindows registryに記録される host/peer cacheは目新しいものではなく、Chordでは、 Finger tableとしてノード発見に利用されている (参考) Skypeでlistenしているport • connectionダイアログボックスで設定された TCP/UDPポート • これはインストール時にランダムに設定される • 通常のインターネット上のプロトコルのように一定しない • それ以外に80/TCP (HTTP)および443/TCP (HTTPS)を利用する Buddy Listの利用 • Buddy ListをWindows registry内に保存 • 電子証明および暗号化されている • SCにローカルに保存されているだけで中央には一切おかれない • ユーザがSCとして異なるマシンを利用した場合、バディリストを再構築する必要がある (参考)Skypeで利用しているCodec • iLBC • iSAC • 未知のコーデックがあるかもしれない • GlobalIPSound – iLBCおよびiSACを実装し、Skypeがパートナーであると彼らの WEBで明言している – SkypeはGlobalIPSoundのcodecを使用しているものと推測される – 測定の結果50-8,000 Hz がSkypeのcodecで利用可能であった – これはwideband codecの特徴として認められる Skypeの暗号化 • 通話とインスタントメッセージングを暗号化 • AES(Advanced Encryption Standard, Rijndel)を使用と明言 • 256-bit暗号化 • 1.1 x 10^77の鍵を使用可能 • また、AES共通鍵のネゴシエーションに1536 2048 bitのRSAを使用 • ユーザの公開鍵がログイン時に使用されている NAT/Firewall通過 • STUNを利用NAT/Firewallの種類特定し、UDP Hole punchingを使って通信していると推測 • UDP Hole punchingが使用出来ない場合はスーパーノード越しに通信 • NAT/Firewall通過のためのサーバは存在しないと推測される • SCは定期的にNAT/Firewallについて調査し、結果をWindows Registry内に保存 UDP Hole punchingとは？ 192.168.0.15 133.27.4.20 パケット (1) (2) 133.27.4.20:1234 宛にパケットを送ると到達 203.178.141.25 パケット P2P-friendly NAT パケットのsourceを見ると 133.27.4.20:1234 Skypeの動作は以下に分類できる • • • • • • • startup login user search call establishment tear down media transfer presence messages (参考) Startup • SCのソフトウェアが導入され、初めて動作する際にSkype server (skype.com)にHTTP 1.1 GETリクエストを送る – このリクエストには‘installed’というキーワードが含まれる • 次に、新しいバージョンのSkypeが利用可能かを判断するためにHTTP 1.1 GETリクエストを送る – このリクエストには‘getlatestversion’というキーワードが含まれる Loginプロセスとは？ • 何も知らないピアがオーバレイネットワークに参加する • 1つでもオーバレイネットワークのノードを知らないと参加できない • オーバレイネットワークに参加していればピアについて認知できる • 鶏と卵 • 中心のないシステムの宿命オーバレイネットワークどうやってオーバレイネットワークに参加？ピアランデブーも通信もピア同士で行う Skype Loginの2つの意味 • Skypeネットワークへの参加 – オーバレイネットワークにピアとして参加する – 場合によってはSuper Nodeにもなりうる • SkypeID認証 – Skype IDが一意であることを保証している基盤 – 認証を行うオーバレイネットワークへの参加 • 自分以外のピアおよびバディに対してオンラインになったことを広告する • NAT/Firewallの背後にいるかどうか、型の判定 • Global IP AddressのSkypeピアを発見する • Host Cache (HC)は1つ以上の有効なエントリがなければいけない • HCに有効なエントリがない場合、Skypeネットワークに参加できない • このばあい、login failureとなる Login ServerによるSkype ID認証 • SNにSCが接続すると、SCはUser Name / passwordを用いてLogin Serverに認証される • Skype User Nameの一意性を保証する役割 • Login Serverは、Skype Networkにおける唯一の中央集権的なエンティティ • 観測によると – SCはいつも80.160.91.11というIP addressのノードとTCPで通信していた – これがlogin serverではないかと思われる – DNS(NSレコード)の逆引き • ns14.inet.tele.dk • ns15.inet.tele.dk 実際のLogin Processの流れ • HCを空にしてみる – SC内のキャッシュをクリアした – 1つのエントリを記録させた – このエントリのマシンはSkypeが動作していない – SCはログインを試みた – HCに無効なエントリしかないので、Skype ネットワークに到達できないが、 – UDPパケットをエントリのマシンに向けて送ることがわかった • 大体5秒くらい返答がない場合、SCは TCPコネクションを先ほどのエントリに張ろうとする – これは、HCのIP Addressへ80(HTTP)での通信を試みる – さらに失敗すると、HCのIP Addressへ 443 (HTTPS port)での通信を試みる – その後大体6秒くらい待つ • login failureとなった後、それら全てのプロセスをさらに4回行った Bootstrap Super Nodes • ソフトウェアのインストール後に初めてログインした場合 – – – – 7つのエントリを持っているらしいまれに違うこともあるが大体ここへつなげに行く Bootstrap Super Nodesと呼ぶ 7つ以上のHCで初期化される場合も、この7つは必ず含まれている • 逆引きにより4つのISPにあることが分かる – – – – – – – – IP address:port Reverse lookup result 66.235.180.9:33033 sls-cb10p6.dca2.superb.net 66.235.181.9:33033 ip9.181.susc.suscom.net 80.161.91.25:33033 0x50a15b19.boanxx15.adsl-dhcp.tele.dk 80.160.91.12:33033 0x50a15b0c.albnxx9.adsl-dhcp.tele.dk 64.246.49.60:33033 rs-64-246-49-60.ev1.net 64.246.49.61:33033 rs-64-246-49-61.ev1.net 64.246.48.23:33033 ns2.ev1.net まとめ:Skypeにおける鶏と卵の解決方法 • Skypeネットワークへの参加 – まずは、 Bootstrap Super Nodesをハードコーディングしておき、 Super Nodeのリストをどんどん追加・更新 • SkypeID認証 – Skype IDが一意であることを保証している基盤 – 認証を行うエンティティは世界で1つのLogin Server – 唯一、分散できていない部分 • 議論 – DNSSECのような信頼の伝播ができているわけではない – DoS攻撃があったら？参考文献 • An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol – Salman A. Baset and Henning Schulzrinne – Department of Computer Science Columbia University, New York NY 10027 – {salman,hgs}@cs.columbia.edu – September 15, 2004 • http://www1.cs.columbia.edu/~library/TRrepository/reports/reports-2004/cucs-039-04.pdf