2010-03-25

P2Pと帯域とBitTorrent DNA

[お知らせ]4月1日よりBitTorrent DNAクライアントの利用を停止します。 zoomeインフォメーション - 動画共有サイトzoome

インターネットで、帯域というのは、頭の痛い問題である。近年、インターネットで動画を公開するのは、当たり前になっている。私は、音声や動画というものを、特別視してはいない。画像と同じくらい、自然に表示されるべきだと考えている。今日、誰も、Webサイトが画像を使っていると文句をいうものはいない。とすれば、動画だって、自然に使われてしかるべきだ。

しかし、現時点では、まだ、動画は、ディスク容量と帯域を、大幅に消費する。まだ、画像と同じぐらい、自然に使うことはできないのである。

日本は、世界でも有数の、bpsあたりの価格の安いネット回線が、提供されている国である。せっかくの広帯域を、使えぬとあっては、宝の持ち腐れである。

ここで、P2Pという仕組みが出てくる。エンドユーザー同士は、それなりの帯域を持っているのだから、それをお互いに使おうという考え方である。

zoome.jpは、動画をアップロード、公開できるサービスを提供しているWebサイトであるが、帯域を節約するため、Bittorrent DNAを用いていた。

BitTorrentは、数あるファイル共有用のP2Pプロトコルの中でも、一番問題のないプロトコルである。Winnyのプロトコルの何が問題かというと、自分の意図しないファイルを、送信可能にしてしまうことである。それは、Winnyのプロトコルの仕様である。ネットワーク上に、ひとりでもバカがいれば、全員とばっちりを食う、実によろしくないプロトコルになっている。

BitTorrentプロトコルには、そのような問題はない。それゆえ、Operaは、BitTorrentプロトコルをサポートしているし、一部のゲームは、BitTorrentプロトコルをつかって、アップデートパッチを配信している。多くのLinuxのディストリビューションのISOイメージは、BitTorrentで配布されている。

BitTorrentプロトコルは、結構、面白い仕組みになっている。ファイルというか、データというか、とにかく、ダウンロードする一塊のデータを、細かく区切る。そして、最も皆が持っていないピースを、優先的にダウンロードしようとする。

もちろん、実際の仕組みは、もっと複雑である。ここでは、BitTorrentは、単なるプログレッシブダウンロードではないということを、示したいのである。

ところで、BitTorrentは、別にトラフィックを有効的に使ったりはしていないのである。むしろ、その逆で、エンドユーザーがアップロードする分、全体的に見れば、トラフィックを余計に増やしているのである。

ところで、動画のストリーミング再生というのは、広帯域を必要とする。一サーバーとしては、負担を減らすために、BitTorrentの力を借りたいところである。ところが、動画のストリーミング再生というのは、プログレッシブダウンロードを必要とする。そうでなければ、ダウンロードしつつ再生ということができない。

BitTorrent DNAは、主に、こういったストリーミング用途に最適化したBitTorrentプロトコルの実装で、ブラウザのプラグインという形で、提供されている。

zoome.jpのBitTorrent DNAの使用は、なかなか興味深かったが、結局、廃止されたようだ。理由は、実装が不安定ということらしい。

帯域の問題は難しい。マイナーなWebサイトである、zoomeだからこそ、BitTorrent DNAを使用できるのである。もし、ニコニコ動画が、BitTorrent DNAを利用しようとすれば、日本のインターネットは、崩壊する。

これはどういう事かというと、ニコニコ動画の帯域使用量は、もはや、いくら金を積んでも、増やせないレベルになっている。いまは、ISPと相談して、今月は、このくらい帯域を使おうなどと取り決めているらしい。ニコニコ動画が、無分別に帯域を使い出すと、日本のインターネットが崩壊する。

したがって、ニコニコ動画が、無駄にトラフィックを増やす、BitTorrentプロトコルを使えるわけがないのである。

これを解決するにはどうすればいいのか。思うに、マルチキャストができればいいのではないかと思う。今は、サーバーは、データを要求するホストひとつひとつに、それぞれデータを送信しているわけだ。マルチキャストがあれば、サーバーが送信するデータは、ホストひとつ分でいい。ISPが、必要なホスト全部に、あたかも、サーバーが全員に送信したかのように、送信してくれる。

これは、実に理想的だ。マルチキャストさえあれば、トラフィックは減らせる。問題は、マルチキャストには、ISP側の協力が必要だ。全体的にトラフィックが減るとしても、ISPの負担は増える。どのISPも、そんな余計な負担をしたがらない。結果として、マルチキャストはサポートされず、我々は未だに、個別にユニキャストしているのである。

私は、マルチキャストがないからこそ、BitTorrentのようなプロトコルが流行っていると思うのだが、なかなか、うまくいかないものだ。

追記:あるいは、現在、数MBの画像ファイルを使うのが、全く問題なくなったように、将来的には、数百MBから数GBの、動画ファイルを使うのも、問題なくなるのかもしれない。

しかし、我々は、常に、「今使える技術」を欲しているのである。「来年使える技術」は、意味がない。今使えないのだから。

3 comments:

  1. マルチキャストは「同じ」パケットがネットワーク内でコピーされ配送されるので、ライブ放送のようにある時点において大勢が「同じ」データを見るという通信にはむいていますが、通常の動画配信サイトのようにオンデマンドで大勢が「異なる」データを見るような通常の通信には残念ながらむきません。したがって、マルチキャストを効果的に使える場面はわりと限定的なのです。(ちなみに マルチキャストのサポートはそれほど困難ではなく、またトラフィックを効率的に配送できればその分運用・設備コストが減るので、マルチキャストサポートの負担増はそんなに問題ではないことが多いです。)

    ReplyDelete
  2. しかし、ニコニコ動画やYouTubeほどの規模ならば、クライアントのリクエストに、直後に応じるのではなく、
    数秒から数十秒待てば(その間に広告でも表示する)、
    特に人気のある動画ならば、データの送信を要求するホストは、複数集まります。

    このような仕組みを使えば、ある程度、サーバー側の負担を軽減できるとおもうのですが。

    ReplyDelete
  3. 仰る通り、まったく効果がないということはないとは思いますが、個人的にはその効果は限定的なんじゃないかと感じました。いわゆる人気のあるコンテンツが全体のトラフィックに占める割合と、その人気コンテンツがある程度「同時」に見られる割合がどれくらいかは分からないですが、かけ算をすると割と小さな数字になるんじゃないかと思ったためです。(CDNを併用した場合さらに「同一」「同時」が限定的になります) また普及のためには、各家庭のいわゆるブロードバンドルータの更新も必要ですね。

    とはいえ、仕様はあるんだから、とりあえず使えるようにして欲しい、という点は同意です。

    ReplyDelete

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.