カテゴリー「P2P」の210件の記事

2015.01.08

WebRTCを実現するためにSTUNだけでなくTURNも必要な理由

WEBベースの技術で音声・ビデオチャットを実現できるWebRTCが最近注目を集めています。

このWebRTCを使うことによって、音声技術の知識が熟知していなくても、比較的容易に音声・映像サービスを提供できるようになるからです。
また、WebRTCを使うとブラウザー上で音声・映像サービスを実現できます。

そこで、今回はWebRTCの隠れ仕事人のSTUNとTURNと話を簡単に説明してきます。

■WebRTCのアーキテクチャとは?

WebRTCは制御信号、音声信号を基本的には別の経路で通信を行います。
制御信号はクライアントーサーバー型、一方音声信号はP2Pで通信するところが興味深いところです。

音声信号をP2Pにすることにより、遅延がなく且つサーバーへの処理も軽減し音声サービスを実現できるわけです。

ところで、どのようにP2Pで音声信号を渡せるのでしょうか?NATがお互いある環境では不可能なような気がしませんか?

■STUNとは?

そこで登場するのはSTUNです。STUNはクライアントにおけるグローバルIPアドレスとポー番号を知る仕掛けです。

グローバルIPアドレス上にSTUNサーバを立て、クライアントとSTUNサーバが通信(通常はUDP)を使うことで、先ほどの情報をクライアントが知ることができます。

このあと、制御信号を使ってお互いのグローバルIPアドレスとポート番号をタイミング合わせて通信すると、なんと直接端末(あるいはブラウザー間)でUDPの信号が通ります。これをUDPホールパンチングと呼びます。

なんとも不思議な現象かもしれませんが、UDPホールパンチングの解説は下記のリンクをご覧ください。

P2Pとファイアウォール

※ちなみにTCPホールパンチングというTCPをP2Pで直接行う技術もありますが、ここでは触れません。

■TURNとは?

それでは、STUNがあれば音声サービスは必ずP2Pで実現できるのでしょうか?答えはNOです。それは、あるNATの組み合わせだと、どうしてもUDPホールパンチングでは通らないケースがあるのです。

詳しく言うと、Symmetric NAT同士あるいはSymmetric NAT-Port restrictedcone NATの組み合わせの場合、ほとんどのケースでUDPホールパンチングができません。

そのため、TURNというリレーサーバを使って、UDPホールパンチングを使えない場合の音声信号中継処理を行います。一般的にトラヒックの1〜2割はTURNを使うことになるといわれています。

NAT種別の解説は以下の資料を見てください。

ISPのNATには何が求められるか?

■ICEとは?

最後にICEです。STUNに始まり、UDPホールパンチング、TURNまでの一連の音声信号を経路確定するプロトコルがICEです。

■プロトコルの仕様について

P2PにおけるNAT越えの仕様は下記にまとめていますので、ご興味のある方は是非ご覧ください。

NAT技術者にお勧めするRFCとドラフト

| | コメント (0) | トラックバック (0)

2014.11.09

[P2P]P2Pストリーミングのサーベイ文書について

Youtubeのようなストリーミング配信はサーバ=クライアント型アーキテクチャをとります。これによって、サーバはクライアントに対してきめ細かい指示を出すことができますが、逆にスケーラビリティが伸びないというデメリットがあります。

最近はAWSなどのクラウドによるスケールアウトを使って、この問題は解消しつつありますが、スケールアウトしたときのコスト増という課題は現在も解決していません。

一方、クライアントがあたかもサーバのように振る舞い、ストリーミング配信処理を一部肩代わりする「P2Pストリーミング」も10年前から注目されていました。

このP2PストリーミングはIETFのPPSW WGによって標準化の検討をしており、そのWGドラフト(RFCの一歩手前の標準化状態)にP2Pストリーミングの調査文書が公開されているので紹介します。

[PPSPはPeer to Peer Streaming protocolの略]

P2Pやストリーミングに興味のある方は是非チェックしてみてください。

Survey of P2P Streaming Applications

P2Pストリーミングは、大きく分けると

・ツリー型
・メッシュ型

の2種類があります。

ツリー型はその名の通り、ストリームの配信経路が木の構造をしています。そのため構造は単純ですが、障害に弱いという欠点があります。
(一番シンプルな構造だと上位ノードが障害を起こすと下位ノードがすべて障害の影響を受ける。)

一方メッシュ型はストリームの配信経路または制御が網の目のようになっており、耐障害性は高いものの、構造が複雑で開発や設計に時間がかかります。

商用のP2Pストリーム配信は上記のような課題を解決するような工夫を製品独自で行っています。

最近はWEBRTCによって技術的にはブラウザを使ってP2Pストリーム配信が行えるようになりつつあります。プラグインなしでブラウザでP2Pストリーム配信を体感できる日も、もうすぐかもしれません。

続きを読む "[P2P]P2Pストリーミングのサーベイ文書について"

| | コメント (0) | トラックバック (0)

2013.07.07

Winnyの開発者、金子 勇氏の急逝を悼んで

Winnyの開発者である金子勇氏が急逝しました。ご冥福をお祈りします。
 
 私にとってはP2Pの各種勉強会、プロジェクトを起こすきっかけとなった人であり、また同世代でもあるだけに大変驚いています

 私がP2Pと関わったのは研究所時代でした。その後事業会社に移ったあとにWinnyが流行し世間を騒がす話題となっていました。当時の新聞等の記事ではP2P技術自体が完全否定されるような書きっぷりで、P2P技術の研究の経験がある私としては、大変心が痛むものでした。

 そのような状況を何とかしたかった私は、業務ではなかったのですがプライベートでP2Pに関わる動向等を改めて調査し、P2P技術に関わる技術を正確に伝えるようにBlogやWEBにまとめることが日課になりました。
  またP2P技術を研究をすること自体が問題視される風潮を何とか打開しようとしてP2P勉強会を開くことにしたのです。(このころの世間の状況は本当に悲惨で、勉強会を開くことで会社を辞めることになるかも、と思ったぐらいです。今となっては笑い話かも知れませんが。)

 活動を続けていくうちに、P2P教科書やUNIX Magazineを執筆することになってから、本当に素晴らしい出会いがあって、現在の会社でP2Pに関わる技術に関わる仕事をするようになりました。その縁で金子氏とは数度お会いすることがあったのですが、Winnyの開発をやめてからもP2P技術に関わる情熱は伝わってくるものがありました。初めてお会いするときに、金子氏から私のことを「よく知っていますよ」と言われたことは、今でも非常に嬉しいことです。

 もしWinnyがなければ、P2PだけでなくNATやVoIP関係の仕事に関わることはなかったことでしょう。そして何よりもWinnyがなければ、今でも大きく影響を受けている多くの技術者や研究者等と会うことはなかったでしょう。

 Winnyに関わる評価は現時点でも確定しているわけではありません。技術面から言うと、当時の非構造的なP2Pアーキテクチャが主流な時代にスケーラビリティを担保するために高度な技術を使っていました。また裁判の結果について、私も含めたP2P技術者はいつも注目していて、無罪が確定したときには「これでP2P研究が堂々とできる」とほっとしたことを昨日のように覚えています。P2P技術面、法律の観点からも金子氏の活動は非常に重要でした。

 今はP2Pから若干離れている身ですが、このような訃報を聞いて今一度私がP2Pに対して何かできることはないかと、ゆっくり考えています。

<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js" class="wysiwyg-script"> </script>

| | コメント (0) | トラックバック (0)

2012.12.16

「分散ハッシュシステムでのNAT超えの考察」に対する質問について

以前当ブログにて「分散ハッシュシステムでのNAT越えの考察」という記事を書きましたが、@Sn0wNightさんから質問を頂きましたので、ここでお答えしたいと思います。

質問はTwitter経由で3つ頂きました。

【質問1】
P1がNext(Hash_P2)を使うことに関わり、どのようにしてP2のハッシュを見つける事ができるか?

⇒ChordではIPアドレスをハッシュとして使うことが一般的ですが、必須ではなかったはずです。ここではP2を何らかの識別子の名前空間(例えば氏名など)から取得します。その識別子をハッシュすることにします。

【質問2】
P2のハッシュをP1が把握しているにも拘らず、P2がG2に対してIPアドレスをポートを通知する理由とは?

⇒P2とP1はお互いプライベートIPアドレス空間のため、UDP hole punchingなどを行っても直接通信できない可能性があります。そのため、P2はG2経由で他のプライベートなIPアドレスの通信をする場合があります。

つまり、多くの場合UDP hole punchingでP2/P1はお互いのプライベートアドレスを知り直接通信ができる。(UDPの場合)、しかしながら一部のNAT状態では何らかのグローバルIPアドレス空間のノードと中継しないと通信ができない。そのためにはP2は自らのプライベートIPアドレスだけでなく、中継を肩代わりしてくれるG2のグローバルIPアドレスを相手に伝える必要があります。UDP hole punching及びグローバルなノードを使ってNAT越えをする手法はICEと呼ばれIETFで標準化されています。

詳細は私が過去「P2Pネットワーク実験協議会」にてNAT越えについて解説したプレゼン資料をご覧ください。

【質問3】
P1からG2経由でP2への接続要求があった場合、G2からP2へどのようなタイミングでリクエストを転送するのでしょうか?

⇒P2とG2は定期的に通信していますが、これはP2とG2のリンクが確立しているかを確認する目的だけです。(※プライベートIPアドレスのノードがグローバルIPアドレスのノードとリンクを絶えず成立することにより、他のノードからの各種リクエストを受け入れる状態を取れるようにする)
P2とG2はTCPで接続が絶えず確立しており、G2からP2へのリクエストがあった場合は、即時にP2に流すように設計します。このため、P2とG2はWebsocketあるいはSIPのように1つのTCPコネクションで両ノードがクライアント-サーバのように振舞います。

Blogの記事等で質問がある場合は@toremoro21までお気軽にご連絡ください。

| | コメント (0) | トラックバック (0)

2011.11.20

[P2P]Websocketでブラウザ間P2P通信は実現できるか?(その2)

前回はWebsocketでブラウザ間P2P通信は実現できるかどうかを考察し、Javascript+Websocketだけではそれが実現できないことを解説しました。

[P2P]Websocketでブラウザ間P2P通信は実現できるか?

この記事ではWebsocketに関わるP2P通信について研究会で投稿があったことを記しましたが、その著者からプライベートで連絡を頂き研究会の内容を元に解説記事を書いて頂きました。ありがとうございました、大変興味深い記事でした。

WebSocketを使ってWebブラウザ間P2P通信をしてみた

結論から言うとXPCOMと呼ばれる技術を使いTCPソケットを作成します。このXPCOMはFirefoxのアドオン機能として実装できます。研究会の著者はこの技術を使ってTCPによるWebSocket通信を実現したわけです。

ところで前の記事に書いたようにTCPによるNAT越えP2P通信はかなり難しいのが現状です。TCPを接続するタイミングなどをうまく使わないと実現できません。(TCP hole punchingと言う技術を使う。)

そのため、もしこの手のNAT越えをするのであればUDPを使うことになるでしょう。UDP hole punchingはTCP hole punchingと比べてぐっと難易度は下がります。これはUDPがステートレスなので、NATルータの処理を(うまい意味で)ごまかすのが簡単だからです。

NAT越えに詳しい人であればUDP hole punchingはSymetric NATと言われるNAT越えがしにくいことをご存知かと思います。しかしながら実際にUDP hole punchingができないのはSymetric NATでもその一部のタイプとなります。詳しくは私の実名をキーにして資料等検索してみてください。

少し脱線をしますが、実はJavascriptを使ってUDPやTCPソケットを利用できるライブラリを作成しているプロジェクトがあります。残念ながら今は休止状態となっています。

JNEXT- Javascript Native Extention
もしこのプロジェクトが休止してなかったらこの手の話はもっと興味深い話題になっていたことでしょう。

では、やはりWebSocketで何らかの特別なライブラリを使ってP2P通信ができないかと言われると気になる標準化動向があります。

現在ブラウザ間におけるリアルタイムにコミュニケーションを実現するための規定がW3Cによって標準化されつつあります。

WebRTC 1.0: Real-time Communication Between Browsers

それと連動してRtcwebというIETFのWGが既に設けられています。ただし現時点での標準化作業はようやくWGドラフトがでてきたという状況です。

Rtcweb Status Pages

そのWGドラフトである「 Overview: Real Time Protocols for Brower-based Applications」を見ると、シグナリングとしてHTTP/WebSocketを使い、メディアは直接ブラウザ間で通信するモデルとなります。これはSIPでいう台形モデルにかなり近いです。
http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02

ですので、RTCWEBを使ってWebsocketをP2P通信をするという想定は、IETFの現時点の議論状況では当分なさそうです。メディアはRTP/SRTPを想定しており、NAT越えのネゴシエーションとしてICEを利用するようです。本ドラフトを見るとメディアとしてUDPを意識していることがわかります。

RTCWEBの世界においてWebsocketはサーバ/クライアントモデルによるシグナリング通信として使われ、P2Pの対象はメディアのみと言う状況です。まだWGドラフトの2版ですので、シグナリングもP2P通信を対象にしていくのか等今後どうなるかは更なる注目が必要ですね。Rtcweb WGの状況は機会を見て紹介しますのでお楽しみに。

websocketを勉強するには「徹底解説 HTML5 APIガイドブック コミュニケーション系API編」をお勧めします。websocketの良書が少ないなか、サンプルプログラミングを含めてwebsocketの特徴をわかりやすく、網羅的に説明しています。


また、websocketに関する資料は私が主催する「websocket勉強会」サイトにもありますので、併せてチェックすると良いでしょう。
http://homepage3.nifty.com/toremoro/study/websocketconf.html

| | コメント (0) | トラックバック (0)

2011.10.30

[P2P]Websocketでブラウザ間P2P通信は実現できるか?

□WebsocketでP2P通信ができるのか?を検討するきっかけ

第2回Websocket勉強会の開催を来年度また開催しようと考えています。今度は自分としても何か講演できるネタがないか少しずつ考えているところです。その一つのネタはWebsocketで実現できること、できないことはなにか?を解説することです。

さてWebsocketはブラウザ等によって双方向な通信を行うプロトコルとなります。Websokcetを使うことによって従来の技術では困難であった、サーバからのPush通信が容易になります。この考え方を拡張し、Websocketを用いてブラウザ間の直接通信を実施すること、すなわちP2P通信の実現を考えることは自然なことです。

ただWebsocketは現在の仕様を見る限りクライアント-サーバ間通信を基本としており、P2P通信を意識したプロトコルとは残念ながら考えにくいことは事実です。それを承知としてP2P通信をWebsocketとしてできるのか、もしできないなら何故なのかを今回思考実験してみます。

また自分が方式検討/開発として関わった050plusを世に出した後、この検討によってP2P、NAT越え技術を改めて振り返る良いきっかけになると考えています。皆様のコメントを是非頂きたいと考えています。

なお、今回は非常にラフな検討ですので(今夜思いついたアイデアをサラっと書いています)後日詳細な分析結果を改めて書きたいと考えています。

*本検討範囲はブラウザ単体で簡単に処理できるWebsocketとJavascriptの組合せまでとします。

□Weboskcetを用いたP2P通信を実現するための課題

Websocketではクライアント-サーバ間で通信する場合、HTTPのようなプロトコルにて通信を行います。P2P通信をする場合、互いの端末(ここでは端末をノードと呼ぶことにしましょう)はクライアントとサーバ機能を両方持つ必要があります。

これを実現するには以下の課題があります。

[課題1]ノード間でTCPによる接続を実現させるための技術が必要
[課題2]課題1を実現した後Websocketレイヤにおいてクライアント-サーバ間のハンドシェイクを実現するための技術が必要

まず課題1についてです。WebsocketはTCPを使う以上、ノード間でTCP接続をする必要があります。ブラウザはHTTPクライアント機能はありますがサーバ機能は一般的にはないため、どのようにしてブラウザにてサーバ機能を実現できるかが大きな課題となります。

残念ながらJavascriptだけではブラウザ間でP2P通信を行うことは2008年当時で困難であることを過去の記事で纏めています。
ブラウザー間直接通信で広がる世界と課題

すなわち、TCPにおけるブラウザ間P2P接続が実現しない限りWebsoketによるP2P通信の実現までたどり着くことはできません。ブラウザ間P2P接続を実現する可能性の一つとしてTCPのNAT越えで利用するTCP hole punchingを使い、お互い同時にTCPのハンドシェイクを開始することによってP2P実現をすることが考えられます。これを実現するにはJavascriptがTCPのsokcetレベルまでコントロールする必要があり、現在のJavascriptの規定を超えています。

仮にNATがない状態においてブラウザ間P2P接続ができたとしても、サーバレスでNAT越えを行うにはTCP hole punchingを使う必要があります。そのため、商用レベルでブラウザ間P2P通信を行うには、どうしてもブラウザにてTCPのsocketレベルでのコントロールが必須と考えられます。

課題1の解決ができた前提で課題2についても説明します。Websokcetではクライアント/サーバの役割がきっちりと明確化しています。仮にTCP hole punchingでブラウザ間P2P通信がうまく行った場合、どちらのノードがクライアントか、サーバかを決定する必要があります。Websocketのハンドシェイク前に独自プロトコルでクライアント/サーバを決定する、あるいはWebsokcetのハンドシェイク信号の受信タイミングによって役割を決定する等が考えられます。(*後者は受信タイミングによって色々なノード状態がありうるので慎重に実装の検討をする必要があります。)

そして課題1、2をクリアしてもWebsocketの実装によってはセキュリティ対策によってP2P通信が抑止される可能性もあります。参考にJavaAppletによってP2P通信を行う場合、このセキュリティ対策を回避するために、ちょっとしたおまじないをする必要があります。

□結論

上記の検討結果を踏まえると現時点でのWebsokcet+Javascirptの仕様においてはブラウザ間P2P通信の実現は困難だと考えられます。

ところで、信学会の研究会において「WebSocketを用いたWebブラウザ間P2P通信の実現とその応用に関する研究」という発表が既に行われています。サマリーを見るとJavascriptを「独自に拡張する」ことによってWebsocketにおけるブラウザ間P2P通信を実現しているようです。まだこの発表内容は未読ですが、どの程度のJavascriptの拡張をしているのか、それは今後仕様として実現できる見込みがある拡張なのか気になります。近々チェックしたいと考えています。

また、ブラウザ間でP2Pを実現することについては、W3Cのワーキンググループとして「Web Real-Time Communications Working Group」が立ち上がっていますので、本記事に興味がある方はこちらの動向をウォッチすると良いでしょう。機会があったらこの手の情報を随時ご紹介します。

websocketを勉強するには「徹底解説 HTML5 APIガイドブック コミュニケーション系API編」をお勧めします。websocketの良書が少ないなか、サンプルプログラミングを含めてwebsocketの特徴をわかりやすく、網羅的に説明しています。


また、websocketに関する資料は私が主催する「websocket勉強会」サイトにもありますので、併せてチェックすると良いでしょう。
http://homepage3.nifty.com/toremoro/study/websocketconf.html

| | コメント (0) | トラックバック (0)

2010.05.03

TwitterをP2Pで実現する方法をもう少し考えてみる

第2回Twitter研究会は今年7月~9月に開催する予定になりそうだ。ということで、そろそろ講師用MLを作ることを考えている。次回のTwitter研究会では私も講師陣に加わってTwitterライクなサービスをP2P(というよりもクラウドと言ったほうが適切かもしれない)で実現するための手法について議論したいと考えている。本記事はその議論のためのメモである。

さて、TwitterをP2Pで実現する方法については、既に本Blogにおいてほぼ3年前に議論している。本記事はその記事に対して実現方式等を補足したものである。

Tomo's Hotline [P2P]TwitterのP2P化を考えてみる

TwitterのようなサービスをP2Pあるいはクラウドで実現するメリットはスケーラビリティの向上と運用コストの抑制である。

P2PシステムとしてDHTを利用する。今で言うとkey-valueストレージをイメージしてもらえば充分だ。DHTはkeyを引数としてvalueを引き出すことができる。つまりDHTとは分散化されたデータベースようなものだ。

DHTの詳細な説明は拙著「P2P教科書」を読んでもらうこととして、本論に移ろう。
なお、今回はアイデアを紹介するのが目的であるので、各種用語の定義、議論の厳密さよりもわかりやすさを優先する。

[1]基本的なツイートのデータ蓄積方法

前提として各ユーザに対してユニークなアカウントを払い出しているとする。(ユニークな払い出しの実現方法については後述。)
例として@toremoro21というアカウントのユーザがいたとする。今ハッシュ関数をhash()と定義する。

各ノードには一意のノードIDがDHTによって割り当てられている。
@toremoro21に対する各ツイートはノードID=hash(@toremo21)となるノードに格納する。

次の目標は各ツイートにユニークな識別子をつけることである。
今ツイート識別子としてアカウント名+(各アカウントに対するユニークな識別子)で割り当てることを考える。この(各アカウントに対するユニークな識別子)として一番単純なのは、世界標準時(GMT)だろう。GMTを使うと各ツイートの時系列が簡単に把握できる。つまり、タイムライン等における時系列表示が容易に実現できる。当然端末の時間の誤差などが課題であるが、ツイートのように順番が多少ずれていても、あまり問題のならないサービスであればGMTで事足りるだろう。なお、BOTのように大量にツイートを作成するアカウントがいる場合は、GMTの後に各GMT内単位時間内での発言に対するシーケンス番号を付け加えることが考えられる。

話を単純にするため、各ツイートの識別子はアカウント名+区切り文字+発言したGMTで記述することにする。区切り文字を*とすれば、ツイートの識別子の例は@toremoro21*20100503となる。区切り文字より前の情報から、ツイートを発言したアカウント名及びこのツイートを格納しているノードが判明する。区切り文字以降から発言した時間がわかる。

次に、アカウントを一意に作成する方法について述べる。議論を単純にするため、P2Pシステムに悪意のあるノードがいないとする。今、あるノードAがアカウント@toremoro21を作成しようとする。ノードAはノードID=hash(@toremoro21)となるノードと通信を行い、アカウント@toremoro21がまだ作成されていないことを確かめる。もし、既に@toremoro21のアカウントが作成されていたら、別のアカウントを作成し先ほどと同様な手順で既存アカウントと重複していないか確認を行う。

[2]タイムラインの表示
タイムラインを表示する方法として、各ユーザがフォローしている各アカウントのツイートを管理しているノードに対して情報の更新を定期的に確認することが一番シンプルである。ただ、この方法はDHTシステムに対して大きな負荷が掛かる。

よりスマートなタイムラインの実現方法は次のとおり。タイムラインを表示したいノード(ノードPとする)はフォローしている各アカウント(@toremoro21とする。)のツイートを管理しているノード(その一つをノードQとする)に対して、ツイートが更新したときに自ノードに対してプッシュ通知を行うように、指令を出す。つまり、ノードQは@toremoro21に関わるツイートの情報更新が行われた場合、ノードPに対してプッシュ通知を行う。通知方法としては、単にツイートが更新されたことを知らせる方法、更新されたツイートに関わる識別子を知らせる方法、更新されたツイートの内容全体を通知させる方法などがあるだろう。

[3]リツイートに対する処理

リツイートについては、引用したツイートに対する識別子情報も含めてDHTシステムに格納する。これによって、引用したツイートを他人が参照することが容易に可能である。なお、引用するときに引用元のアカウントを含めるため、後述の[6]の処理も行う。引用元ツイートにハッシュタグが含まれた場合、後述の[5]の処理も行う。

[4]ダイレクトメッセージに対する処理

@toremoro21に対してダイレクトメッセージを送信をする場合、hash(@toremo21)をノードIDとするノードにダイレクトメッセージを格納する要求をする。

[5]ハッシュタグに対する処理

@toremoro21が#twitterconfを含むツイートを行う場合、hash(@toremoro21)をノードIDとするノードに当該ツイートを格納するだけでなく、hash(#twitterconf)をノードIDとするノードにもツイートを格納する。これによって、#twitterconfを含んだ発言を他人が容易に参照できる。

[6]アカウントを含むツイートを含む処理

これも先ほどのハッシュタグIDと同じ議論である。あるアカウントを含んだツイートは、hash(アカウント)をノードIDとするノードにも格納する。これによって、各アカウントを含んだ発言を他人が容易に参照できる。

このようにP2PであってもDHTを使えば、Twitterライクなサービスはある程度容易に実現できると考えられる。

| | コメント (0) | トラックバック (0)

2009.10.25

オフィスツアー(ビットメディア)を振り返る

10/16(金)にP2Pライブ配信で有名なビットメディアでオフィスツアーを開催しました。参加者数は10名でP2P配信談義で大いに盛り上がりました。

オフィスツアーに関わる周知情報は以下のURLをご覧下さい。
http://toremoro.tea-nifty.com/tomos_hotline/2009/08/post-c2f4.html

以下概要と感想です。

□ビジョン先行の企業

ビットメディアといえば、P2Pライブ配信企業として有名ですが、それだけでなくポイントシステムやスマートグリッドに関わるシステムを開発しています。(スマートグリッドについては現在プロジェクト進行中とのこと。)

ビットメディアのビジョンは「地産地消」「徹底的にニッチ」ということで、ローカルなエリア対象にそこに根付いた小中規模な事業を手がけるところがユニークだと考えました。このビジョンは開発方針(システムの規模やコスト)にも反映され、結果的に

・「ニッチ」なため競合他社が入りにくい
・リーズナブルなシステムなため、小中規模なイベントでも利用できる
・「ニッチ」だがペイできる収益を確保できる

という好循環を生み出しています。ビジョンを通して更にユニークな分野に事業が広がるところを期待しています。

□P2P配信の話

いよいよ今回の目玉であるP2Pライブ配信の話です。P2Pライブ配信はツリー上で行います。つまり、ツリー(いわゆる配信木)に端末が存在し、端末はその下位の端末にコンテンツを渡します。このことで、コンテンツ配信サーバのネットワーク負荷と各種リソースを大幅に削減することができます。

ところで、コンテンツ配信サーバ自体をより動的に利用できるのが、ビットメディアの売りです。コンテンツ配信サーバとしてなんとAmzon EC2を使います。このことによって、本当にライブ配信をしたい前後だけにAmazon EC2を利用することで、配信コストを大幅にコストダウンすることができます。またAmazon EC2を使うことにより、配信をすぐに開始でき、(デモではAmazon EC2の設定を含め数分でコンテンツ配信が可能となりました。)また配信スケールも簡単に変えることができます。

つまり、ビットメディアのP2P配信システムはP2P+Amazon EC2によって

・コンテンツ配信のイニシャル/ランニングコストの低下
・高スケーラビリティなコンテンツ配信
・機動力のあるコンテンツ配信

を実現しているわけです。

Amazon EC2をコンテンツ配信サーバとして利用すると、やはり遅延が発生します。ただし、双方向性のコンテンツではないので、遅延は個人的には気になりませんでした。

最近ではネットワーク高度利用協議会で提案しているヒントサーバを利用して、トラフィックをISP内で閉じ込める工夫もしています。

□より収益のある事業に向けて

NHK合唱コンクールの地域予選をP2Pライブ配信したところ、各種から問い合わせがきたとのことです。中継では数100ぐらいの同時視聴者数があって、安定的に配信できたとのことです。この程度の視聴者数を見込められるライブ配信であれば、ビットメディアの配信システムも候補に入れた方が良いでしょう。

ビットメディアのライブ配信の良さはなんといってもコストパフォーマンスです。1ヶ月1チャネルを利用するときの配信料金はたった10万円です。これはP2PとAmazon EC2を採用しないと実現できない料金体系です。

また配信料金の低価格を活かして、個人によるコンテンツ配信事業の検討をしているとのことです。料金体系は30分100円~で誰でもコンテンツをライブ配信可能な模様です。こうなるとビデオカメラを使って誰もが簡単にライブ配信ができる日がもうすぐやってくるのでしょう。なお個人配信のコンテンツとして、少年スポーツ団や結婚式のライブ配信などを想定しているようです。

□終わりに

今回のツアーはビジョンとマーケティングとの密接な関わり合いについて考えさせられました。ビジョンからマーケティングに落として、それから技術を生み出すというトップダウンの仕組みがビットメディアでは実践されています。その結果、ニッチだけれどもユーザから感謝される新たなサービスが数多く実現しているのです。このオフィスツアーを通して、技術者であってもマーケティングや経営戦略をもっと勉強しなければ消費者に訴えられるサービスは作れない、という気持ちが沸いてきました。

□追記+次回のオフィスツアーは?

今回のオフィスツアーのTwitterハッシュタグは#officetour です。また感想記事はSBMで「オフィスツアー」タグでまとめられています。

はてブで「オフィスツアー」タグ 

次回のオフィスツアーは2010年2月開催予定です。ユニークさ企業としてとても有名なのでお楽しみに。

本Blogではオフィスツアーにご協力頂ける企業、団体の方をお待ちしています。ユニークな企業の方、先進的な企業な方、楽しい雰囲気の企業、地域に貢献している団体等ご連絡をお待ちしております。また今後は大学、大学院の研究室のツアーもやりたいと考えています。

| | コメント (0) | トラックバック (0)

2009.08.14

[開催日変更]オフィスツアー(株式会社ビットメディア)参加者募集のご案内

久しぶりにオフィスツアーを開催します。
今回はP2Pライブ配信の「ビットメディア」にお邪魔します。

P2Pライブ配信の実装でJavaアプレットを採用しているため、
インストールレスでコンテンツの視聴ができるのが特徴です。
つまりブラウザーだけでP2P通信を行っています。
最近ではクラウドとの連携でも話題になっています。

オフィスツアー概要

□日時:10/16(金) 19:30~21:00(開催日が変更になりました)
□開催場所:下記の場所に直接お越し下さい
渋谷区渋谷2-7-5 URD渋谷第2ビル 6F受付
http://www.bitmedia.co.jp/map.html
□参加定員
10名
□参加費用
無料(軽食をご用意しています。飲み物は各自持参でお願いします。)
□参加表明方法
Mixiのイベントトピで受け付けます。
http://mixi.jp/view_event.pl?id=45394576

□参加条件
Blog、Twitter、Mixi等でオフィスツアーの感想を書いて頂くこと
□お願い
・首かけストラップ+名刺をお持ち下さい。
・飲み物は各自持参でお願いします。
・おつまみの持ち込みを歓迎します!

以上です。皆様のご参加、心よりお待ちしています!

| | コメント (0) | トラックバック (0)

2009.04.11

[NAT]NAT越え入門1-NATとは何か?

今日から私が一番得意とする研究開発分野である、NAT越えとNATに対するレクチャーを連載したい。もちろん、NAT越えやNATはP2Pにも大いに関連がある分野である。期待して欲しい。

そもそもNAT越えに関わったのは、現在の会社に異動後企画書を作り、VoIP(IP電話)のNAT越えの研究を自ら始めたからである。開発コードは「シームレスコネクション」と呼び、研究開発成果は信学会のNS研究会や全国大会で投稿しているので、関心のある方は図書館等で見て欲しい。またそれが縁でキャリアグレードNATのインターネットドラフト作成にも携わっている。

この連載の目標はNATとNAT越えの基本的な部分をレクチャーすることであるが、最終的には一番技術的に困難で複雑なVoIPのNAT越えまで話を進めたい。(体力と時間があれば)

またコメントや質問は基本的にはてブでお願いしたい。適宜連載途中で回答します。

さて、NAT越えを解説するまえにNATについて説明しよう。いつものように定義等は厳密でない。わかりやすさ優先であるので、そこはご容赦願いたい。

□NATとはなにか?

NATとは、Network Address Translatorの略で、文字通り訳するとネットワークアドレス変換装置となる。実際には、NATは家庭用のネットワーク領域(LAN)とインターネット用接続用のネットワーク領域(WAN)の境界に存在し、NATがLAN⇔WAN間の通信において、LANに存在する端末のIPアドレスをNATのWAN側に割り当てられたIPアドレスに変換する役割をする。ここでWANの規定は曖昧なのだが、あくまでもNAT解説ということでお許し頂きたい。

そもそもNATはIPアドレスの枯渇を解消する目的で作られた。インターネット上で使用できるIPアドレスは一意的で、通常グローバルIPアドレスと呼ぶ。これをみんなが使ってしまうとIPアドレスがなくなってしまい、結果的にインターネットを使えるユーザに制限がでてしまう。このグローバルIPアドレスは組織的に管理されていて、通常はISPから払い出されることになる。逆にインターネット上でない場所で使えるIPアドレスはプライベートIPアドレスと呼び、これはLAN等のネットワーク管理者が独自に管理することになる。

「みなさん、端末はグローバルIPアドレスを使う代わりにプライベートIPアドレスを使いましょう。ただインターネット上もつなぎたい場合があるでしょうから、そのときにはNATがLAN内の端末プライベートIPアドレスをNATに割り当てられているグローバルIPアドレスに変換してから接続してあげるよ。」というのがNATの「本来」の利用目的なのである。

ネットワーク図をざっくり書くとこんな感じである。
端末(プライベートIPアドレス)-LAN--NAT(グローバルIPアドレス)-WAN-インターネット

ところでNATは副次的に次の効果を生み出す。というか、むしろ以下に書いてあるNATの便利さがNATの存在意義を非常に複雑にしている。

1.セキュリティの確保

後日の連載にて説明するが、NATはWAN側からLAN側への通信をブロックすることが原則である。NATは多様なネットワーク攻撃を「結果的に」防御することになる。ここで注意することは、NATとファイアウォールを混同しないこと。NATはあくまでもIPアドレスの変換装置であり、後日書くNATタイマーやフィルタリングの効果によりWAN側からLAN側への通信を「結果的に」ブロックすることになる。特にブロードバンドルータはNATとファイアウォール機能を両方具備していることがあるので、多くのネットワーク技術者(ネットワーク管理者や研究者ですら!)を混乱させる原因となっている。

もうひとつのNATのセキュリティ効果は、実際にLANに存在してる端末のIPアドレスをインターネットで通信しているサーバor端末側から隠蔽できることである。このことはNAT66と呼ばれるIPv6のNATの提案でも議論されている事項である。NAT66については時間があれば解説したい。

2.ネットワーク設計の容易さ

NATのLAN側はプライベートIPアドレスを使うことができる。このことによって、管理者が簡単にLAN内のネットワーク設計を行うことができる。なぜならWAN側はグローバルIPアドレスが必要なので、ISPにIPアドレス利用申請等をしなければならなからだ。NAT66のインターネットドラフトでもネットワーク設計を容易にするために、IPv6でもNATが必要なんだ、と書かれている。

□NAPTとは何か?

NAPTはNATと違い、IPアドレスだけでなくポート番号までNAPTが変換してしまう。ポート番号まで変換することで、グローバルIPアドレスの利用効率を更に加速させることを意味する。

利用効率についてもう少し考えてみよう。

例えば、LAN内に4つの端末があるとする。この端末がすべてインターネット上のサーバと通信するとする。NATであれば、IPアドレスを変換するだけの機能なので、NATに割り当てられているWAN側のグローバルIPアドレスが4つ必要である。ところが、NAPTの場合は、ポート番号まで変換するので(ほとんどの場合)実はグローバルIPアドレスが1つで十分である。

例えば、{IPアドレス:ポート番号}という表記においてLANのネットワーク情報が端末1={192.168.1.1:1000},端末2={192.168.1.2:2000},端末3={192.168.1.3:3000},端末4={192.168.1.4:3000}の場合、NATのWAN側では端末1={1.1.1.1:1000}、端末2={1.1.1.1:2000}、端末3={1.1.1.1:3000},端末4={1.1.1.1:3001}と対応する。つまりLAN内に端末が4つあっても、WAN側のグローバルIPアドレスは1個しか消費しない。これはNAPTの変換例である。

このようにポート番号を変換することにより、グローバルIPアドレスの消費を大幅に減少させることに成功した。しかしながらネットワーク管理者はもはやNATのIPアドレスだけでなく、ポート番号まで管理する必要がでてくる。ここがNAPTの難しいところである。

通常、ブロードバンドルータで使われているのはNAPTであるので、今後は断りがなければNAPTをNATと呼ぶことにする。

そして、NATが一番ややこしいのは、つい最近までNATの詳細仕様が決まってなかったのである。これがNAT越えの問題を非常に面倒なものにしている。

以下簡単にまとめておこう。
[1]通常NATと呼ばれるのはNAPTのことである。
[2]NATはIPアドレスとポート番号の変換をするのがメインであるが、セキュリティの確保とネットワーク設計の容易さを提供する。
[3]NATの詳細仕様は最近まで決まってないため、NAT越えの仕様が複雑となっている。

NATについて興味のある方は、以下の2冊が大きな参考になるため、是非お読みください。なお、P2P教科書はNATに関わる情報の一部を私が執筆しています。


NAT越えについては、私のサイト(P2P入門)にも解説していますので、併せてご覧ください。
  http://homepage3.nifty.com/toremoro/p2p/firewall.html

| | コメント (0) | トラックバック (0)

より以前の記事一覧