[特集]

中国の最新インターネット事情(9):インターネットのアプリケーション事情(その4)

2011/03/31
(木)
陶 一智

この連載では、中国のインターネットの歴史や特徴、社会に与える影響などを中心に最新の情報をお伝えしています。前回の前回の第8回では、中国におけるネット動画のを見る場合の方法について、ウェブブラウザでの視聴と専用ソフトでの視聴する場合を紹介し、また、中国における代表的なP2P動画配信サービスや動画共有サイトを見てきました
今回(第9回)は、CDN(コンテンツ配信ネットワーク)による動画配信の仕組みや、P2P(ピアツーピア)方式による分散配信方式を解説します。P2P方式については、とくに中国でよく利用されている、BitTorrentの例を挙げて解説します。

≪1≫CDN方式による動画配信の仕組みと特徴

〔1〕CDN(コンテンツ配信ネットワークによる動画配信の仕組み)

ウェブサイトを訪れて、そこでブラウザを使って動画を見る場合、多数の人が動画を再生すれば、サーバの負荷やサーバが接続されているネットワークの負荷が上がり、品質の低下をまねきます。また、接続できないことすらあります。これを輻輳(ふくそう)状態と呼びます。

そこで、輻輳(混雑)が発生しないように配信元(サーバ)をさまざまなISP(Internet Service Provide)に分散させ、近くのサーバから動画を送るCDN(Contents Delivery Network、コンテンツ配信ネットワーク)方式を使用します。CDNでは、ISPごとにプロキシー(代理)サーバ(Proxy Server)を置いておきます。そして、ユーザーのPCからの映像要求が来た場合には、そのPCに最も近いプロキシーサーバから送信を行います。すでにコピーを持っている場合には、それを送信し、持っていない場合には、オリジナルのサーバから受信してコピーして、かつ、PCへ送信します。コピーは他のPCからのリクエストに対しても送信されます。この様子を図1の(2)に示します。

図1 CDN方式によるコンテンツ配信の仕組み(クリックで拡大)

図1 CDN方式によるコンテンツ配信の仕組み


〔2〕DNSの仕組みを応用したCDN方式の特徴

CDNでは、DNS(Domain Name System)の仕組みを応用しています。 DNSとは、インターネットのドメイン名FQDN(Full Qualified Domain Name。例:www.sample.com)から対応するIPアドレス(例:96.30.44.124)を得たり、その逆を得たりするためのシステムです。メールの転送先のサーバも、メールアドレスのドメイン名部分からDNSで得ることができます。

例えば、server1.example1.comというFQDNのコンピュータのIPアドレスが192.168.1.1であると仮定すると、この対応表をあらかじめexample1.comドメイン全体を担当するDNSサーバに入れておきます。また、このDNSサーバはあらかじめcomドメイン全体(結局はルートサーバになるのですが)を担当するDNSルートサーバに登録しておきます。他のコンピュータが、server1.example1.comを知りたい場合には、ルートサーバに問い合わせ、そこからexample1.comを担当するDNSサーバが教えられますので、example1.comのDNSサーバへserver1.example1.comのIPアドレスを問い合わせると最終的に所望のIPアドレス192.158.1.1が得られます。

各ホスト名には、別名をつけることができます。これをCNAMEと呼びます。例えば、server1.example1.comに、別のドメインのserver2.exmaple2.comという別名をつけることができます。この場合には、example2.comのDNSからserver2のIPアドレスを得ます。

CNDでは、このCNAMEの仕組みを流用します。配信をする企業は、CDNのサービスを提供する会社と契約するとともに、自分のDNSにも前準備が必要となります。それは、動画の送信元サーバのFQDNを管理する自分のDNSレコードに、その別名CNAMEを設定しておくことです。この別名は、CDNのサービスを提供している会社から指定されたFQDNになっています。

ユーザーが動画の送信を要求する時には、次の手順で配信が行われます。

①ユーザーのPCは、動画サーバのドメインを管理するDNSサーバに動画サーバのIPアドレス解決要求を出す。

②そのDNSサーバは、すでに設定してあったCNAME(別名)を返す。

③PCは、そのCNAMEのFQDNを管理するCDNサービス会社のDNSサーバに対し、IPアドレス解決を要求する。

④CDNサービス会社のDNSでは、アドレス解決要求を送ってきたPCのIPアドレスを分析し、最も近いCDNのプロキシーサーバのIPアドレスを返す。

⑤PCは、このIPアドレスに対して、動画の転送要求を出す。

⑥もし、そのプロキシーサーバに要求された動画がなければ、オリジナルのサーバからコンテンツを一旦プロキシーへコピーしてからPCに渡す。このコピーは、別のPCからの要求に備え、一定時間、保持される。なお、リアルタイムの動画配信の場合には、周期的にサーバから継続的にプロキシーサーバへ動画データが送られてくるが、プロキシーサーバは一定時間が経過した部分を捨てる。

以上のシーケンスを図2に示します。なお、動画データの場合、プロキシーサーバは、スプリッターとも呼ばれます。

図2 CDNネットワークの構造と仕組み(クリックで拡大)

図2 CDNネットワークの構造と仕組み


≪2≫P2P方式による分散動画配信の仕組みと特徴

〔1〕P2P(ピアツーピア)の仕組み

CDN方式以外に、サーバの負荷やネットワークの負荷を下げる分散配信方式としてP2P(Peer to Peer)方式があります。P2Pでは、データを細かなブロック(これをピースやチャンクと呼ぶ。ピースを更にサブピースに分割して転送する方式もある)に分割します。データを配信するオリジナルのサーバは、シーダーと呼ばれます。配信を受けるPC(これをピアと呼ぶ)は、ランダムに異なるピースを選択してシーダーからダウンロードします。これらの異なるピースを持つピアは互いに自分の持たないピースをダウンロードし合います。

つまり、CDNと異なり、映像を受信するPCはダウンロードを行うクライアントでもあり、同時に、他のPCに自分の持つ映像のピースをアップロードするサーバでもあるということになります。このような分散方式により、オリジナルのサーバへ負荷が集中しない仕組みとなっています。また、GB(ギガバイト)級の大きなファイルの場合には、転送を速く完了することができます。

代表的なP2PのプロトコルとしてBitTorrent[6]があります。中国でよく使用されているP2Pは、このBitTorrentです。BitTorrentは、Bram Cohen(ブラム コーエン)氏が2001年に発表した技術で、大きなファイルを速くダウンロードするためのプロトコルとして設計されました。2004年には、アメリカでBitTorrent社が設立され、同氏は社長に就任しています。最初のソフトウェアは、2002年に発表されましたが、すぐには広まりませんでした。

その後ファイル交換に広く使われるようになったのですが、配信されるコンテンツの著作権侵害が問題となり、幇助をしているとして訴訟が相次ぎました。結局、2005年にアメリカ映画協会MPAA(Motion Picture Association of America)と、著作権上の問題があるコンテンツへのリンクをBitTorrentのサイトから削除することで合意しました。しかし、BitTorrentのソフトウェアは、オープンソースでプロトコルも公開されており、それを利用したシステムやサイトは膨大な数に上っていたため、MPAAは個別の訴訟で世界のサイトの運用者を訴えてきました。この結果、90%のサイトを停止させたと言われています。このように、P2Pの使用にあたってはコンテンツの著作権に十分な注意が必要です。

〔2〕中国で普及しているBitTorrentの仕組み

P2Pによる動画配信(ストリーミング)の説明を行う前に、そのシステムの元となったBitTorrentのファイルダウンロードの仕組みについて説明をしておきます。

(1)2段階のダウンロード

BitTorrentのファイルダウンロードは、2段階で行います。まず、目的のファイルのダウンロードを管理しているサーバ(トラッカーと呼ばれる)やファイルの名前や長さなどの属性が書かれているファイル(トレントファイルと呼ばれる)を、トレントファイルの検索サイトやトレントファイル配布サイト(インデックスサーバと呼ばれる。)からダウンロードします。つまり、インデックスサーバのウェブを閲覧し、インデックスを検索して所望のファイルに対するトレントファイルを見つけ、自分のパソコンにダウンロードします。

次に、これをパソコンにインストールされているBitTorrentのダウンロード専用ソフトウェアに読み込ませて、目的のファイルのダウンロードを行います。これを図3に示します。図3は、単一のファイルをダウンロードすることを想定して書かれていますが、あるディレクトリ配下の複数のファイルをまとめてダウンロードするようにトレントファイルに記述することもできます。

(2)ダウンロード用ソフトウェア

ダウンロード用ソフトウェアは、トラッカーおよび目的のファイルを同じようにダウンロードしている他のパソコン(ピアと呼ばれる)と通信を行い、ファイルをダウンロードします。この画面を図4に示します。

ファイルは、一定の長さの断片(これをピースと呼ぶ)に細分化されており、転送はピースの単位で行われます。ピースをダウンロードしたピアは、そのピースを他のピアにアップロードします。つまり、持たないピースをピア同士で補完し合うのです。また、ピア間では並列に、そして、双方向にピースの転送が行われます。このため、ダウンロードに参加しているピアが多ければ多いほど、ダウンロードが完了するまでの時間が短くなります。

例えば、図5では、ファイルを8つのピースに分解しています。ここでは、シーダーと3つのピアA、B、Cがあると仮定しています。シード以外のピアはリーチャー(Leecher)と呼ばれます。リーチャーの各ピアは、完全なファイルを持つシーダーや、他のピアから、自分の持たないピースをダウンロードします。どのピアがどのピースを持っているかを管理するのがトラッカーです。このため、各ピアは定期的に自分の持つピースをトラッカーに報告します。また、トラッカーからピアのリストを定期的に取得し、どのピアからどのピースをダウンロードするのかを決定します。

なお、ピアからそのピアの知っているピアのリストももらい、トラッカーからのピアのリストとマージしてピアのリストをより充実させることも行います。そして、ダウンロード先のピアをできるだけ分散させ、自分の持たないピースのうち、ピア全体でコピー数の少ないピースを優先します。そうすれば、全体でのピースの重複数のバランスが取れ、ダウンロード完了までの平均時間が短縮できます。また、ダウンロードに偏っているピアに対しては、一時的にアップロードしないChokingという罰が与えられます。これは、ダウンロードしかしないピアを排除するためのしっぺ返し戦略(tit for tat)で、ゲーム理論を学んだことのある方にはおなじみの戦略です。なお、完全にピースが揃ったピアは、今度はシードとなります。

図3 二段階のダウンロード(クリックで拡大)

図3 二段階のダウンロード

図4 ダウンロード用ソフトウェアの画面(BitTorrent)(クリックで拡大)

図4 ダウンロード用ソフトウェアの画面(BitTorrent)

図5 ピア間のピースのコピー(クリックで拡大)

図5 ピア間のピースのコピー


(3)BitTorrentシステムの構成要素

BitTorrentのシステムの構成を図6に示します。システムは次の要素から構成されています。

図6 BitTorrentシステムの構成要素(クリックで拡大)

図6 BitTorrentシステムの構成要素


①インデックスサーバ

インデックスサーバは、たくさんのトレントファイルを提供しています。トレントファイルは、CentOS-5.2-i386-bin-DVD.torrentのように、.torrentという属性を名前に持っています。ちなみに、このトレントファイルは、Linuxの代表的なバージョンであるCentOSをダウロードするためのもので、ファイル名を見ればすぐにわかるようになっています。このファイルの中に、図3で示しているような複数のトラッカーのURLやファイルの情報などが入っています。なお、インデックスサーバが次に説明するトラッカーを兼ねているサイトもあります。

②トラッカー(tracker)

トラッカーは、あるファイルの転送に関与するすべてのピアを管理します。どのピアがどのピースを持っているかは、各ピアからの定期的な報告によって把握します。また、各ピアは、ダウンロード可能なピアを定期的にトラッカーに尋ねます。これに対し、ランダムに選んだピアのリスト、および、それらのIPアドレスとポート番号を返します。これをもとに、各ピアは他のピアに接続することになります。トラッカーを経由することはありません。接続の際には、トレントファイル中に記されている各ピースに対する認証キー(ピースごとに計算したハッシュ値SHA1を利用)が一致しないと接続できません。ピースの転送はTCPプロトコルを使用して行われます。

もし、トラッカーがダウンすると、ファイルのダウンロードができなくなってしまいます。このため、最近では、中央に一つのトラッカーを配置するのではなく、安定した複数のピアが分担してトラッカーの役目を果たす分散型ハッシュテーブルDHT(Distributed Hash Tree)方式も使用できるようになってきています(注1、注2)

(注1)Designs and Evaluation of a Tracker in P2P Networks, Adele Lu JIA and Dah Ming CHIU, 2008
http://www.p2p08.org/program/sessions/12-short-papers-2/1%20-%20P2P08JIA.pdf/at_download/file

(注2)PPLive―A Practical P2P Live System with Huge Amount of Users, Gale Huang, 2007
http://www.sigcomm.org/sigcomm2007/p2p-tv/Keynote-P2PTV-GALE_PPLIVE.ppt


③ピア(peer)

ピアには、あるファイルを構成するピースを全部持ったシーダー(seeder)と、一部を持った、あるいは、まったくもたないリーチャー(lecher)とがあります。リーチャーがピースの収集を完了し、全部のピースを持った時点で、それはシーダーになります。なお、同じファイルをダウンロードしているピアの集合をスウォーム(swarm)と呼ぶこともあります。ピアはピースを受信するごとに、その完全性を検査します。

つまり、ピースに対してハッシュ関数を適用してハッシュ値を計算し、それと、トレントファイル中に記された各ピースに対するハッシュ値SHA1(Secure Hash Algorithm 160ビット版)とを比較します。値が異なれば、損傷を受けたものとして破棄します。

なお、ピアは、トラッカーからだけではなく、スウォーム内のピアからも、それが知っているピアのリストももらいます。これらと、トラッカーからもらったピアのリストをマージし、ピアのリストを充実させます。

〔3〕P2Pによる動画配信の仕組み

P2Pによる動画配信は、これまで説明してきたP2Pによるファイルダウンロードと大きく変わるものではありません。ただし、ピースの転送に動画の特性が考慮されています(注3)。また、トラッカーファイルの取得は動画プレーヤーが自動的に行うので、ファイル転送よりも利用者の手間が減っています。

(注3)Traffic analysis of P2P IPTV and comparision with BT-like application based on live measurement, Bing Li, Zhigang Jin, Maode Ma, WiCom '09. 5th International Conference onWireless Communications, Networking and Mobile Computing, 2009.


(1)動画転送までの手順

図7に動画転送までの手順を示します。まず、ユーザーが動画プレイヤーを起動すると、①このソフトウェアは番組表配信用ウェブサイト(チャネルリストサーバ)にアクセスし、番組リスト(チャネルリスト)を取得します。この番組表はプレーヤの画面にカテゴリ別や人気の順に表示されます。チャネルリストサーバは、インデックスサーバに相当します。

ユーザーはそれから好みの番組(チャネル)を選択して配信スタートボタンをクリックします。すると、②このソフトウェアは、トラッカーへアクセスし、自分をピアとして登録するとともに、選択したチャネルと同じチャネルを受信中のピアのリストを得ます。

そして、③プレーヤーは得られたリスト内のピアにアクセスして、それらのピアが持つピアリストをもらい、現在のピアのリストとマージします。映像を受信している間は、定期的にこのようなピアリストの更新を行い、同じチャネルの映像データを受信しているピアリストを最新のものに保ちます。なお、番組を配信するオリジナルのシーダー(スーパーシーダーとも呼ぶ。)もピアの一つになります。他のピアと異なる点は、シーダーは常に完全に揃ったピースを保持しているということです。

図7 動画転送までの手順(クリックで拡大)

図7 動画転送までの手順


(2)動画ピースの転送

ピア同士は、自分がどのピースを持っているかというバッファーマップを交換します。バッファーマップには、例えば、自分の持つ一番古いピースの識別番号(オフセット)、バッファーマップの長さ、どのピースを保持しているかというマップが含まれています。

ピアとバッファーマップの関係を図8に示します。バッファーマップでは、ピースを保持している部分は1に、まだ受信していない部分は0になっています。

これで、自分の持たないピースをどのピアが持っているのかがわかりますから、そのピアに転送を要求します。複数のピアから同時にピースを受信できるので、その分、早く欠落しているピースを得ることができます。なお、ピアは常に他のピアとピアリストを交換し、より良いピアを選択します。多数の人が見ているほど、すなわち、多数のピアがあればあるほど負荷は分散し、転送も安定して早くなります。

図8 ピースとバッファーマップとの関係(クリックで拡大)

図8 ピースとバッファーマップとの関係


リアルタイムで配信される動画の性質として、常に古いデータ(ピース)が消え、新しいデータ(ピース)が生成されているという点が挙げられます。どんどんピースが生成されるので、ファイルの場合と異なり、いつまでも保存(キャッシュ)しておくとメモリやディスクから溢れてしまいます。しかし、他のピアで再生しているピースがずれていることもあります。そこで、自分の再生が終わっても、すぐにピースを捨てず、しばらく保存しておきます。P2Pのソフトウェアにもよりますが、その量は数十メガバイト程度と推測されています。これは、300Kbps程度の映像ストリームを想定すると、一分前後の時間に相当すると考えられます(注4)

(注4)Insights into PPLive: A Measurement Study of a LargeScale P2P IPTV System, Xiaojun Hei†, Chao Liang‡, Jian Liang†, Yong Liu‡ and Keith W. Ross, 2006
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.7592&rep=rep1&type=pdf


P2Pの動画プレーヤーによっては、映像の再生機能を含んでおらず、表示にはすでにあるメディアプレーヤー(ウィンドウズメディアプレーヤやリアルプレーヤなどの映像再生ソフトウェア)を利用するものがあります。但し、表示部分はP2Pの動画プレーヤーのウインドウ内にあるので、第8回の(図3、4、5)に示したように見た目は一体化されています。この種のソフトウェアは、スタート後にある程度連続したピースがそろった時点でプレーヤー部分を起動することになります。そして、プレーヤー部分に対して、整ったデータを渡すことになります。これを図9に示します〔前出の(注4)参照〕。

このようなP2P動画プレーヤーの例として、すでにPPLiveとPPstreamなどを紹介しました。これらは、とても似たシステムなのですが、PPLiveがデータを主にUDPで転送しているのに対し、PPStreamはデータを主にTCPで転送しています(注5)

(注5)Survey and Problem Statement of P2P Streaming, Ning Zong, Huawei Technologies, 2008,
http://www.ietf.org/mail-archive/web/ppsp/current/pdfVFtKyRsjIt.pdf


また、バッファーはPPliveのほうが大きく、ピースの取得アルゴリズムが異なります。PPliveのほうは、順番に取得しますが、ピアが持っている数の少ないピースを優先的に取得します。一方、PPStreamのほうは、ランダムにピースを取得します。

図9 P2Pソフトウェアとプレーヤーとの関係(クリックで拡大)

図9 P2Pソフトウェアとプレーヤーとの関係


(3)アクセス制限

映像の再生時には、どの地域からアクセスしているかをチェックしており、インデックス(番組のリスト)やウェブは見られても、コンテンツによっては日本からは映像を見られない場合があります。例えば、動画を表示する部分が黒のままで変化がなかったり、“The clip has been blocked in your region.”、“土豆網無法対イ尓所在的区域地区提供服務 Tudou cannot provide service to your region and country.”(土豆網の場合)などのメッセージが表示されます。

これは中国からの動画配信に限ったことではなく、アメリカのサーバでも同様です。配信可能な地域のライセンスが限定されているために、地域外には配信されないようにIPアドレスのチェックが行われている場合があります。

(つづく)


関連記事
新刊情報
5G NR(新無線方式)と5Gコアを徹底解説! 本書は2018年9月に出版された『5G教科書』の続編です。5G NR(新無線方式)や5GC(コア・ネットワーク)などの5G技術とネットワークの進化、5...
攻撃者視点によるハッキング体験! 本書は、IoT機器の開発者や品質保証の担当者が、攻撃者の視点に立ってセキュリティ検証を実践するための手法を、事例とともに詳細に解説したものです。実際のサンプル機器に...
本書は、ブロックチェーン技術の電力・エネルギー分野での応用に焦点を当て、その基本的な概念から、世界と日本の応用事例(実証も含む)、法規制や標準化、ビジネスモデルまで、他書では解説されていないアプリケー...