検証 ネットワーク管理者のためのNapster入門 3．Napsterの通信メカニズム 井口圭一／デジタルアドバンテージ 2000/07/22

　Napsterの仕組み、つまりサーバやクライアントがどのような内部構造を持っていて、いかなる通信プロトコルを使ってユーザー間でファイルを交換しているかなどの仕様については、残念ながら公開されてはいない。Napster社自身が今後どのようなビジネス モデルで収益を上げようとしているかは不明であるが、少なくとも、わざわざ仕様を公開して他社の参入を招き、自社の収益のチャンスをみすみす逃すことはないであろうと思われる（まだ開発途上なので、将来仕様が変更される可能性が高いから仕様を公開しないという理由もあるだろう）。

　しかし、インターネットの検索エンジンなどで探すとすぐに分かるが、実はNapsterで使われているネットワーク プロトコルはほぼ解明されており、そのドキュメントが公開されている。さらにこれに基づいて、Napsterクライアントと互換性のあるソフトウェアや、さらには、Napsterのサーバと互換性のあるソフトウェアなども開発されているし、Napster互換ソフトウェア開発者のためのメーリング リストなどもある。今回はこのような情報と、ネットワーク上のプロトコルをモニタした結果に基づいて、Napsterのシステム（プロトコル）について見てみよう。

Napsterシステムの構成要素

　Napsterは、ユーザーの手許に置かれている音楽ファイル（MP3もしくはWMAファイル）を、ユーザー同士が交換するのを手助けするためのシステムである。Napster社のサーバに音楽ファイルが格納されていてそれをダウンロードしているわけではなく、あくまでも、ユーザーの手許にある音楽ファイルを、ユーザー自身が直接交換するためのシステムである。Napster社ではその交換の手助けをしているだけにすぎない、というのがNapster社の主張である。実際のところはどうなっているのであろうか、以下で見ていこう。

　まず、Napsterシステムを構成する要素についてまとめておく。Napsterシステムは、ユーザーの側にダウンロードして動作するNapsterクライアント プログラムと、Napsterの社内（？）で動作しているNapsterサーバ プログラムの2つから構成されている。さらにサーバ側を詳しく見ると、Napsterクライアントが最初に接続を試みるサーバと、ユーザーのログイン情報を扱うサーバの2種類があり、負荷分散（？）を図っているようである。このあたりの関係を図にまとめると、次のようになる。図中で、青い太い矢印はTCP接続が確立される向きを（矢印の先の数字はTCPのポート番号）、オレンジの細い矢印はそこを流れるデータの内容を表している。

Napsterシステムへのログイン処理

　Napsterクライアントを起動すると（ログインすると）、最初に、図中の「リダイレクト用サーバ」と書いてあるマシンにTCP接続（接続先ポート番号は8875番）を試みる。なお「リダイレクト用サーバ」とは、Napster社の正式な呼び方ではなく、この記事で参照するために付けた仮の呼び名である。このリダイレクト用サーバのアドレスは「server.napster.com」という名前をDNSで解決することで得られるが、記事執筆時点では、2つのIPアドレスが割り当てられているようだ。つまり、世界中からの接続要求を処理するために、2台のリダイレクト用サーバを用意しているものと思われる。将来的には、Napster側の負荷の増加に応じて、さらにサーバが追加されるのだろう。リダイレクト用サーバの役割は、次に述べるユーザー ログイン用サーバのIPアドレスを返すことである。ログイン用サーバとは、Napsterクライアントが実際にログインして、タイトル名（ファイル名）を登録、検索したり、ダウンロードの指示を出したり、チャットなどの処理をしたりするという、メインとなるサーバである。

　Napsterクライアントがリダイレクト用サーバに接続して、ログイン用のサーバ（この名称も仮に付けたもの）のIPアドレスを取得すれば、そこでいったん最初のTCP接続はクローズすることになる。そして取得したサーバのIPアドレスに対して、改めてTCP接続を開始し、実際にユーザーとの対話処理を行う。そして以後はずっとこのTCP接続を使うことになるが、いったんログオフして再度ログインし直したり、クライアントを再起動したりすると、異なるサーバ（やTCPポート番号）に接続することになるだろう。このときに使われるTCPのポート番号は、最初にリダイレクト用サーバから、サーバのIPアドレスと共にもらうことになっている。よって、使用するポート番号は毎回異なる可能性がある（実際には「7777番」とか「8888番」がよく使われているようだ）。

　このログイン用サーバが実際に何台あるかは詳しくは分からないが、実験中に何度か接続し直した限りでは、少なくとも10台以上は存在しているようだ。多数のマシンが用意されているのは、ユーザーの増加に応じて、Napster社がサーバ システムを順次強化しているからだろう。何しろ世界中で1000万ユーザー以上はいるとされているNapsterシステムであるから、負荷を考えると、大量のサーバ リソースを用意する必要があるのは想像に難くない。そこでなるべく負荷分散を図ることができるように、スケーラビリティの高いネットワーク プロトコルが決められているようである（2段階のログオンはそのための手段であろう。これなら将来サーバが何台に増えても困ることはない）。ユーザーがログオンすると、クライアントを終了するか、［Disconnect］を実行するまで、同じTCP接続が使われる。

　TCP接続が成功すると、クライアント側からユーザーID（ニックネーム）とパスワードを送信し、認証を受ける（暗号化はされておらず、クリアテキストのまま送信されているので、安全性は高くない）。認証が成功するとログイン メッセージが送り返されてくる。なお、このログイン時には、ファイルの転送のためにクライアント側がリッスン（待ち受け）しているTCPのポート番号や、クライアントのバージョン情報、リンク情報（通信速度）なども送信している。以後は同様に、クライアント側からコマンドを送って、サーバがそれを解釈、実行して、結果を返す、というふうに動作する（通信はすべてクリアテキストのまま行われ、暗号化などは行われていない）。

　ユーザー認証が完了すると、次に、公開するタイトル名（音楽ファイルの名前）とそのサイズなどの情報をサーバに送信する。以上でユーザーのファイルがサーバのリストに登録され、他のユーザーから検索できるようになる。

　なお、画面には表示されていないが、Napsterでやりとりする「名前」は、実際にはタイトル名 ではなく、フルパスで指定されたファイル名である（たとえば「C:\Program Files\Napster\Music\Mozart - Eine Kleine Nacht Musik Allegro.mp3」という具合だ）。

　また、設定画面ではフォルダ単位で公開するファイルを指定することができるが、実は公開されているのはこれらのファイルだけではなく、ダウンロード先に指定したフォルダの中のほかのファイルの情報も送られている。しかし、これらのフォルダの中のファイルがすべてが公開されるわけではなく、いくつかの条件を満たしたものだけが正式なファイル名として送信される。まず拡張子は「.mp3」か「.wma」に限られている。ただしまったく別のファイルの拡張子だけを変えても、MP3データのビットレートなどの必要な情報が取得できないので、無視される。試しにサウンドレコーダで録音したファイルをMP3でエンコードしてみたのだが、これもまた表示されなかった。これは、ファイル サイズが小さかったので無視されたのかと考え、エンコードした音楽ファイルの後ろにダミーのデータを付け足してファイル サイズを大きくしてみた。するとそのファイルは表示されるようになった。ただし実験したかぎりでは、同じサイズでもファイルによって表示されたりしなかったりするようなので、詳細は不明である。

音楽ファイルの検索

　Napsterクライアントを使って音楽ファイルをダウンロード（ほかのNapsterクライアントの提供している音楽ファイルを、自分の手許に持ってくること。中央集中型のシステムではないので、ダウンロードというのは少々語弊があるかもしれないが、ここではダウンロードという用語を使うことにする）するときには、まずそのタイトル名を検索する必要がある。Napsterクライアントの検索のページでは、アーティスト名とタイトル名から検索できるようになっているが、これらの情報が実際にサーバに登録されているわけではない。音楽ファイルの中には、圧縮された音楽信号データ情報以外にもいくつかの情報が含まれているが、このうちサーバに登録されているのは、データのビットレートやサンプリング周波数、演奏時間だけである。たとえばMP3ファイル中のID3タグ部分には、たいていの場合にはアーティスト名やタイトル名が入力されているのだから、それらを登録することもできると思うのだが、実際には使っていないようだ。現実のファイルでは、登録されていないものが多いとか、たとえ入力されていたとしても、（いろいろな言語で書き込まれているので）、すべてのユーザーが正しく読めるかどうか分からないから、というのが理由ではないかと思われる。いずれにしろ、タイトル名やアーティスト名情報はサーバには登録されていない。

　ではどうやって検索しているのかというと、サーバに登録しているファイル名（フルパス名）に対して、入力したアーティスト名とタイトル名の両方が含まれているかどうかを、文字列として検索しているのである（アーティスト名かタイトル名のいずれかしか指定しない場合は、他方は空であるとみなされる）。そのため、フルパス名の途中に含まれているようなよくある文字列でも、検索がヒットしてしまう可能性がある。たとえば、音楽ファイルはデフォルトでは「C:\Program Files\Napster\Music」ディレクトリに置かれていることが多いので、「Program Files」などでもヒットしてしまう（検索結果からは、なぜヒットしたのか分からないだろう。しかしなぜか「Napster」や「Music」などはヒットしないようだ。無視される語のリストがあるのかもしれない）。検索しやすい名前にするには、ファイル名にアーティスト名やタイトル名を（正しいアルファベットのスペルで）付けておく必要があるだろう。

　以上のような「アーティスト名」や「タイトル名」（実際は「ファイル名」）による検索のほかに、Napsterクライアントでは、「ユーザー」を指定した検索も可能である。ユーザーを「hotlist」に登録しておくと、そのユーザーが公開しているファイルの一覧を表示し、そこから効率よくダウンロードすることができる。ただし、ログインしていることが分かっているユーザーが「Offline」と表示されることもよくあり、その場合はダウンロードすることはできない。ログイン サーバは複数あると先ほど述べたが、実際にどのサーバにログインするかはリダイレクト用がサーバの返す応答によって振り分けられている。現状のNapsterシステムでは、ファイルのリストは、それぞれのログイン用サーバごとに独立して管理されており、サーバ間ではこれらの情報の交換は行われていないようである。したがって、別のサーバにログインしているユーザーを見つけることはできないし、ファイルのやりとりもできないのである。もし特定のユーザーを見つけたければ、メニューの［Connect］と［Disconnect］で何度も接続と切断を繰り返し、運良く同じサーバにログインできることを期待するしかない。データの一貫性という点から見ると、かなり未熟な負荷分散システムであるが、不特定多数のユーザー間で音楽ファイルを共有するという目的からすると、これでもよいのかも知れない。Napsterは、特定のユーザー間でファイルのやりとりをするためのものではないからだ（うがった見方をすると、どんな音楽ファイルでも、十分な数のコピーがすぐに世界中にダウンロードされて流布してしまうので、わざわざサーバ間での一貫性を保持する必要もない、ということなのかも知れない）。

音楽ファイルのダウンロード

　検索の結果、目的とするファイルが見つかったら、次はそれをダウンロードすることになる。以下の図に、一般的なダウンロード時の通信の様子を示しておく。先ほどの図と同じく、青い太い矢印はTCP接続の接続の向きを、オレンジの細い矢印はそこを流れるデータの内容を表している。

　検索の結果、欲しいファイルが見つかり、ダウンロードを指示すると、その要求はまずサーバへ送られるが、その後のファイルのやり取りはNapsterクライアント同士で直接行われる。そのやりとりを詳しく見てみよう。数字は図中の番号と一致している。

�@ユーザーがファイルのダウンロードを指示すると、ダウンロードを要求するコマンドがサーバに送られる。引数はファイルを提供している側のユーザー名とファイル名である。
�Aサーバはファイルを提供する側のユーザーに対して、ファイルのダウンロード要求が届いていることを通知する。
�Bファイルをダウンロードする側に対し、ファイルを提供しているユーザー側のIPアドレスとリッスン（待ち受け）しているポート番号を返す（このポート番号は、最初にサーバにログインするときに、Napsterクライアント側からサーバに送信したもの）。
�C受信側は受け取ったIPアドレスとポート番号に対して、TCP接続を試みる。つまり、実際のファイルのやりとりは、Napsterクライアント間で直接行う。
�Dファイルの転送を要求する。
�E提供している側からダウンロードしている側にファイルが転送されて完了となる。

　このように、Napsterのサーバには検索用のファイル リストがあるだけで、実際の音楽ファイルそのものはNapsterのサーバに蓄えられているわけではなく、さらにNapsterのサーバを経由することもなく、ユーザー間で直接転送されている。これがNapster社が違法ではないと主張するよりどころなのだろう（ファイルの転送を「仲介している」だけであり、音楽ファイルを直接提供しているわけでない、ということ）。

ファイアウォール環境でのダウンロード

　Napsterでのファイル転送は、今見たように、ダウンロードする側から、ファイルを提供している側のマシンに直接TCP接続を確立して行っている（技術的に言うと、ファイル取得側からファイル提供側に対して、TCPのSYNシーケンスが送られている）。つまり、ファイルを提供する側では、TCPのポートをリッスンしており、外部からのダウンロード要求を待っているのである。ということは、ファイル提供側のマシンは、必ずグローバルIPアドレスを持ったマシンでなければならない、ということを意味している。でなければ、外部（インターネット側）からの接続要求が、ファイアウォールなどで拒絶されて失敗することになるからだ。

　一般に、企業などの組織では、インターネットとイントラネットの間にはファイアウォールというセキュリティ メカニズムを導入しており、外部からの勝手な接続要求は通さないようにしていることが多い。DNSサーバやWebサーバ、メール サーバなど、ごく一部のサーバにのみグローバルIPアドレスを付与してインターネット向けサービスを行い、それ以外のマシンにはプライベートIPアドレスを付けて（NATやProxyサーバを使って）、インターネットとは隔離するのである（プライベートIPアドレスを使わないまでも、少なくとも外部から自由にどのマシンにでも接続できるようにしたりはしないのが常識である）。このようなケースでは、イントラネット上のマシンからNapsterを使ってファイルを提供することはできない（ダウンロードすることは可能）。外部からのTCP接続要求が通らないからだ。ファイアウォールのコンフィギュレーションによっては、外部からの要求を一部内部へ中継できるようにすることもあるが（メール サーバなどをイントラネット上において、外部からの要求を中継したりする）、先に見たように、Napsterではクライアントがリッスンするポート番号はクライアント自身が決めるようになっているので（しかも、あまり一般的ではないポート番号なので）、この方法は使えない。

　さてそれでは、ファイルを提供する側のユーザーがファイアウォールの内側にいる場合は、ほんとうにファイルを提供することはできないのだろうか？　実は場合によっては、これができてしまうのである。Napsterには、わざわざそのための仕組みが備わっている（NapsterクライアントのProxy設定（SOCKS）を使うというのは、グローバルIPアドレスを使うのとほぼ同じことであり、それについてはここでは触れない）。ファイアウォールがある場合の通信の流れについて、以下の図に示す。

　この図で、�@〜�Bまでは先の図と同じだが、�Cから先の手順は異なっていることに注意していただきたい。

�@ダウンロードを要求するコマンドがサーバに送られる。
�Aサーバはファイルを提供する側のユーザーに対して、ダウンロード要求が発生したことを通知する。
�Bファイルをダウンロードする側に対し、ファイルを提供しているユーザー側のIPアドレスとリッスン（待ち受け）しているポート番号を返す。
�Cダウンロード用のTCP接続をオープンしようとする。しかしファイアウォールがあるので、この要求は失敗する。

　ここでTCPの接続要求が失敗するのは、サーバが�Bで渡すIPアドレスが、ファイアウォール自身のものだからである（サーバには、Napsterクライアントからのログオン要求時のマシンのIPアドレスが登録されている。NATなどのファイアウォールを使っていると、これはファイアウォール自身のアドレスになる）。このような場合、ユーザーはNapsterクライアントの設定で［I am behind a firewall〜］というふうに設定しておく（こうすると、ログイン時に渡すポート番号が0になる）。

　Napsterクライアントは、リッスンしているポート番号が0となっているマシンへはTCP接続を行わず、代わりにサーバへ逆方向転送要求を送ることになっている。

�D受信側はサーバに、逆方向に接続するように要求するコマンドを送る。
�Eサーバは、ファイルを提供する側のユーザーからのログイン接続を使って、ファイル提供側に逆方向転送の要求と受信側ユーザーのIPアドレス、ポート番号を通知する。つまり、ファイルを要求しているユーザーのIPアドレス情報を、ファイルを提供する側に通知するのである。
�F要求を受けたファイルの提供側は、受信側に向けてTCP接続をオープンする。先の図と比べると、TCP接続の向きが反対になっていることに注意されたい。
�GこのTCP接続を使って、ファイルを転送する。

　以上のようにファイアウォール環境下では、通常とは逆向きにTCP接続を確立することで、ファイルを転送することができる。ファイアウォールやNATを使ったネットワークへは外部からは接続できないが、内部から外部へは接続できることを利用しているわけだ。いってみれば、ファイルを取りに来れないユーザーに対しては、わざわざファイルを送ってあげている、というような感じであろうか（まさにNapsterは相互扶助の精神に基づいている、といえなくもない……）。

　ただしこのような方法で転送を実現している以上、両方のコンピュータがファイアウォールの内側にいる場合は、どうあっても転送が不可能である。残念ながら、これを解決する方法は（少なくとも現状のNapsterには）用意されていない。

Napsterの利用を禁止する方法

　Napster社は違法行為ではないと主張しているが、実際に交換されている音楽ファイルは著作権で保護されているプロのアーティストの曲がほとんどで、違法行為をほう助しているという理由で裁判も起こされている。また、1曲あたりのファイル サイズは4〜6Mbytes程度あり、多くのユーザーが使えば、それだけネットワークに負担をかけることにもなる。さらに、外部からは見えないはずのマシンのファイルを持っていくことができるのもセキュリティ上好ましくない。ネットワーク管理者としては、Napsterの利用を禁止したくなるのは当然だろうし（逆にいうと、積極的に利用を勧める理由はほとんどないだろう）、実際に（アメリカの）大学などでは禁止しているところがほとんどだ。

　では実際にどのようにして禁止すればよいだろうか。ユーザー間のファイルの通信（ファイルのダウンロード）に使われるポートはデフォルトではTCPの6688番か6699番だが、これは設定次第でどのようにでも変更できる。またNapsterのログイン サーバのTCPのポート番号も7777番と8888番が使われているようだが、これもリダイレクト サーバから送られてくるので必ずこのポート番号になっているという保証はない。となると、最初の入り口であるリダイレクト サーバへの接続を禁止するしかないだろうし、これが最も簡単で確実な方法でもある。

　Napsterクライアントは、最初にserver.napster.comという名前を（DNSで）調べ、そこから得たIPアドレスを使って、TCPの8875番ポートへ接続を行っている。したがって、これに関連するポートやIPアドレスを通過させないように、ファイアウォールを構成すればよいだろう。ファイアウォールにおけるTCP接続の禁止方法としては、

　　１．宛先ポート番号による制限
　　２．IPアドレスによる制限
　　３．ドメイン名による制限
　　４．１と２の組み合わせ

などがあるので、このなかから環境にあったものを使えばよい。

　このうち最も簡単なのは、1．のポート番号による制限だろう。TCPポートの8875番に対して外部へ接続できないようにすれば、Napsterの使用を止めることができる。この方法なら、まずどんなルータでも設定できるはずだ。

　２．のIPアドレスによる制限を行うこともできる。server.napster.comには、今のところ208.184.216.223と208.184.216.222の2つのIPアドレスが登録されているので、このIPアドレスへの接続をフィルタリングで禁止すればよい。

　しかし、１の宛先ポート番号による禁止の場合、他のサービスで8875番を使っている場合には使えないし、2のIPアドレスによる禁止はserver.napster.comのDNSの登録が変更されると設定を変更しなければならない。

　３．のドメイン名による制限は便利だが、ルータやファイアウォールにそのような機能がなければ利用できない。１．と２．を組み合わせて、IPアドレス208.184.216.0/24で、かつTCPの8875番への接続を禁止するという方法もある。この方法だとnapster.comのすべてのホストの8875番への接続を止めることができる。ついでに7777番や8888番も止めておけば安心だろう。

　以上のような措置で、Napsterクライアントの利用を（一時的にではあるが）止めることができるが、実際には、Napster側のIPアドレスが変わったりすることもあるので（外部のホスティング サービスを使い始めたりすると、IPアドレスが変わることがある）、管理者としては、常に情報収集に努める必要があるだろう。また、Napster以外のファイル交換ソフトウェアも続々と開発されているし、gnutellaのような完全な分散型の場合には、特定のIPアドレスやポート番号だけを禁止するような方法では対処するのが難しくなっているのも事実である。将来的には、より複雑なフィルタリング ルールの設定や、より高機能なファイアウォールを導入する必要に迫られることになるかもしれない。

ネットワーク管理者の頭痛のタネだが、P2Pという新潮流への一歩でもある

　Napsterのシステムは、基本的には以上のように非常に簡単なものである（他にチャット機能などもあるが、ここでは触れない）。サーバではユーザーの持っているファイルの一覧リストを管理しているだけで、実際にやり取りされるファイルに関しては、著作権に配慮したファイル交換など（たとえばユーザーの権利によって配布などに制限を付けたり、だれがどのようにダウンロードしたかをトラッキングしたりする機能など）ができるようにはなっていない（少なくとも現状では）。もちろん将来的にはこのような機能を取り入れることも可能であろうが、Napster互換ソフトウェアが大量に出回っている現在、そのようなより制限の強いシステムにすんなりと移行するユーザーがそんなにいるとは思えない。

　ただシステム的に見ると、1000万ユーザーもいるような世界規模でのファイル交換ソフトウェアが、この程度のプロトコルやシステムで実現できるということが実証されたのは非常に大きな成果であったといえよう。これからは、より分散性の高い（集中型のサーバが不要な）gnutellaのようなソフトウェアの開発がよりいっそう進むと思われるが、ビジネス モデル的に見ると、著作権管理機能などがきちんと組み込まれたP2P（Peer to Peer）ファイル交換ソフトウェアは、Webとはまたちがった、インターネットの大きな潮流になるのは間違いないだろう。ネットワークの管理者からすれば、やっかいな悩みのタネではあるが、Napsterは実に偉大な一歩だといえるかもしれない。

	関連リンク
		音楽業界を震撼させるNapsterの可能性（@IT IT Business Review）
		Napster社のホームページ（米Napster社）
		Napster互換ソフトウェア開発者のためのメーリング リスト（napdev）

INDEX
	［検証］ネットワーク管理者のためのNapster入門
	1．Napsterとは何か？
	2．Napsterを使う
	3．Napsterの通信メカニズム

　

検証

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）