...

WebRTC を利用したブラウザキャッシュ 共有による

by user

on
Category: Documents
3

views

Report

Comments

Transcript

WebRTC を利用したブラウザキャッシュ 共有による
平成 26 年度
学士学位論文
WebRTC を利用したブラウザキャッシュ
共有によるデータ配信システム
The data distribution system using browser cache
sharing and WebRTC
1150361
松下 和生
指導教員
植田 和憲
2015/02/27
高知工科大学 情報学群
要 旨
WebRTC を利用したブラウザキャッシュ共有によるデータ配信
システム
松下 和生
近年、インターネットへのブロードバンド接続環境が一般化し、動画をはじめとする大容
量コンテンツの配信トラフィックが急増している。
その問題を解決するための既存技術として P2P Web Proxy が存在する。しかし、P2P
Web Proxy にはコンテンツのダウンロード後もキャッシュを保持する問題や、外部に向け
てポートを開放しておく必要があるなど、クライアントにとって利用しづらい問題が存在
する。
本稿では、ブラウザのプラグイン技術と WebRTC を利用して前述の問題を解消したシス
テムを「WebRTC を利用したブラウザキャッシュ共有によるデータ配信システム」として
提案し実装、前述の問題が解決可能であることを示す。
キーワード
Web, HTTP, WebRTC, P2P
–i–
Abstract
The data distribution system using browser cache sharing
and WebRTC
Kazuki Matsushita
In recent years, broadband connections to the Internet environment have spread,
thus traffic delivery and the retrieval of large-volume content such as videos have soared.
P2P Web Proxy is present as an existing technique for solving the problem. However, it is difficult to use for client because it has two problems. It is a problem of
retaining the cache after download of the content, a problem that it is necessary to
open the port toward the outside.
In this paper, by using technologies of browser plug-in and WebRTC to propose a
system which solves the aforementioned problems. And implement as ”browser cache
sharing system using WebRTC”.
key words
Web, HTTP, WebRTC, P2P
– ii –
目次
第1章
研究の背景
1
第2章
既存技術
2
2.1
Web ブラウザのプラグイン . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.2
Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.3
P2P Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.4
WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
ブラウザキャッシュ共有によるデータ配信システム
5
3.1
システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2
想定する利用環境
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.3
キャッシュ共有の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
シグナリングサーバー . . . . . . . . . . . . . . . . . . . . . . . . .
7
通信プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
ブラウザキャッシュ共有によるデータ配信システムの実装
9
第3章
3.3.1
3.4
第4章
4.1
4.2
第5章
ブラウザプラグインの実装 . . . . . . . . . . . . . . . . . . . . . . . . . .
10
4.1.1
既存通信のリダイレクト処理 . . . . . . . . . . . . . . . . . . . . .
11
4.1.2
内部 Web サーバー . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.1.3
WebRTC による転送処理 . . . . . . . . . . . . . . . . . . . . . . .
12
シグナリングサーバーの実装
. . . . . . . . . . . . . . . . . . . . . . . .
総括
13
15
謝辞
16
– iii –
目次
参考文献
17
– iv –
図目次
2.1
P2P Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.1
ブラウザキャッシュ共有システムの全体図 . . . . . . . . . . . . . . . . . .
6
3.2
ブラウザキャッシュ共有システムでの通信の様子 . . . . . . . . . . . . . . .
7
4.1
ブラウザキャッシュ共有システム稼働時の様子 . . . . . . . . . . . . . . . .
9
4.2
ブラウザキャッシュ共有システムの動作
–v–
. . . . . . . . . . . . . . . . . . .
10
表目次
4.1
パケットの状態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
– vi –
13
第1章
研究の背景
近年、インターネットへのブロードバンド接続環境が一般化し [1]、動画をはじめとする
大容量コンテンツの配信トラフィックが急増している [2]。ネットワークトラフィック増加に
伴い、サーバーへの負荷集中も問題となっている。これらの通信の大部分は、HTTP プロ
トコルを代表とした、 クライアント・サーバー型通信が担っており、この通信モデルが通信
トラフィックの増加、サーバーへの負荷集中の原因である。
この問題を解決する既存技術として、P2P Web Proxy が存在する。P2P Web Proxy
は HTTP 通信を中継するソフトウェアであり、中継した際のデータをキャッシュし、その
キャッシュ P2P で交換するすることにより、ネットワークトラフィックを削減する技術で
ある。
しかし、既存の P2P Web Proxy では、コンテンツ取得後にそのキャッシュを P2P ネッ
トワーク上で共有するため、コンテンツのダウンロード後もアップロード帯域と記憶領域
を消費する問題がある。さらに、外部からの接続を待ち受けする必要があるため、セキュリ
ティ上の懸念が存在する。また、ブラウザとは別途ソフトウェアを必要とする問題もある。
そこで本稿では、この問題の解決案を提示する。コンテンツのダウンロード後もリソース
を消費する問題に対しては、協調ダウンロードと呼ばれる手段を用いる。外部から接続を待
ち受ける必要がある問題に対しては、通信の際のプロトコルとして WebRTC を用いたシス
テムを構築することで解決する。また、ソフトウェアの実装形態をブラウザのプラグインと
することで、ブラウザの他に別途ソフトウェアを必要とする問題を解決する。
本稿では、このような解決案をを用い、既存の P2P Web Proxy に存在する問題を解決
する。そして、問題を解決したデータ配信システムを実際に実装し、その結果を報告する。
–1–
第2章
既存技術
本稿で実装する「ブラウザキャッシュ共有によるデータ配信システム」では、クライアン
ト・サーバー型通信である Web 通信と P2P 型の通信を併用している。体面上、ユーザーは
従来通りブラウザを用いて通信を行う。そのため、Web の既存技術がそのまま利用できる。
本稿のシステムシステムは、Web ブラウザのプラグインとして実装する関係上、Web の
技術と相性よく、Web の既存技術を利用することで実装がとても容易になる。そのため、こ
れらの Web の技術を提案システムでは利用している。本稿のシステムで利用している P2P
型の通信には、Web ブラウザで実装されている WebRTC を利用している。これについて
も、本章で解説する。
2.1
Web ブラウザのプラグイン
Web ページを閲覧するときに用いる Web ブラウザの中には、プラグインを利用してアプ
リケーションの機能を拡張できるものが存在する。本稿で提案するシステムでは、Web ブ
ラウザのプラグイン技術を利用して Web ブラウザで行われている通信に干渉している。
2.2
Web Proxy
Web Proxy は HTTP で定められている規格であり、HTTP 通信を中継する役割を持
つ。Web Proxy には、大きく分けて二種類の役割がある。セキュリティを強化する役割と、
キャッシュを行う役割である。
Web Proxy を中継して通信を行うことで、クライアントは外部のネットワークに直接ア
–2–
2.3 P2P Web Proxy
クセスすることも、外部のネットワークからアクセスされることもない。そのため、Web
Proxy が稼働しているホストのセキュリティを高めることにより、ネットワーク全体のセ
キュリティを容易に向上させることができる。
また、Web Proxy を中継して通信を行うため、通信の内容を Web Proxy が知ることが
できる。これを利用して、Web Proxy でデータをキャッシュすることができる。それによっ
て、通信を高速化することができる。この技術は、本システムでも利用している。
2.3
P2P Web Proxy
P2P Web Proxy とは、2.2 で説明した Web Proxy のキャッシュを P2P ネットワーク
で共有することにより、多くのキャッシュを保有できるようにした Web Proxy である (図
2.1)。P2P Web Proxy は P2P ネットワークを使ってキャッシュを共有するため、P2P Web
Proxy 同士でキャッシュを交換するための通信が発生する。本研究では、既存の P2P Web
Proxy の問題を解決したシステムを実装する。
2.4
WebRTC
WebRTC (Web Real-Time Communication) は W3C (World Wide Web Consortium)
が規格化を進めているブラウザ間通信の規格である [3]。通信に WebRTC を利用した場合、
プラグインを用いずに音声や動画、バイナリデータの送受信を行うことができる。
WebRTC では、P2P 通信を行う際、明示的にポートを開けておく必要がない。また、
NAT 内部にクライアントが存在する場合でも、STUN プロトコルと UDP ホールパンチン
グを用いてクライアント同士で通信が確立できる仕様となっている。
WebRTC は、Google Chrome や Firefox などの標準的なブラウザでサポートされてお
り、本稿で提案する「ブラウザキャッシュ共有によるデータ配信システム」でも用いる。
–3–
2.4 WebRTC
Web サーバー
Web コンテンツ
P2P Web Proxy
P2P Web Proxy
P2P Web Proxy
P2P ネットワーク
Web ブラウザ
Web ブラウザ
図 2.1 P2P Web Proxy
–4–
第3章
ブラウザキャッシュ共有によるデー
タ配信システム
本稿では、2.3 章で説明した P2P Web Proxy をウェブブラウザのプラグインとして実装
した、データ配信システムを提案する。
本稿で提案するシステムは、中央のウェブサーバーとの通信と、他のピアとの P2P 通信
を並行して行う。ウェブサーバーとの通信には、従来の HTTP プロトコルを用いる。他の
ピアとの通信には、ブラウザ同士で P2P 通信を行う規格である WebRTC を用いる [3]。
3.1
システム構成
本システムは、コンテンツを提供するウェブサーバー、キャッシュを共有するピアの情報
を管理するシグナリングサーバー、及びクライアント PC のウェブラウザーとそのプラグイ
ンから構成される (図 3.1)。
本システムに対応したウェブサーバーは、HTTP ヘッダを用いて対応している旨をクラ
イアントに通知する。クライアントは、そのヘッダを検出し、本システムを利用したダウン
ロードに切り替える。そのため、従来の HTTP 通信と併用でき、既存のシステムに対して
容易に組み込むことが可能である。
ダウンロードしたデータは通信が終了した時点で破棄される。これにより、クライアント
がキャッシュを保持し続ける問題を解消している。
–5–
3.2 想定する利用環境
クライアント (A)
ウェブサーバー
クライアント (B)
クライアント (C)
シグナリングサーバー
図 3.1
3.2
ブラウザキャッシュ共有システムの全体図
想定する利用環境
本提案システムでは、Web ブラウザの通信に干渉し、Web サーバーからだけではなく、
他ピアからもデータを取得する。その関係上、Web サーバーから単にデータをダウンロー
ドするときよりもクライアント側の処理が増加する。そのため、非常に小さいサイズのファ
イル転送では、並列ダウンロードの恩恵よりオーバーヘッドの方が大きくなる。
よって、一定以上の大きさのファイルを転送する際に用いることで本提案システムの恩恵
を受けることができ、そのようなシーンでの利用が望ましい。
3.3
キャッシュ共有の流れ
本システムでは、同じファイルをダウンロードしている人同士で通信を行う。そのため、
本システムの利用者はファイルのダウンロード開始時に、そのことを後述のシグナリング
サーバーへ送信する。
その後、シグナリングサーバからピアの一覧を取得し、他ピアとの通信を行う。他ピアと
の通信には WebRTC を用いる。これにより、ポート開放などの作業が不要となり、導入が
容易になる [3]。
–6–
3.4 通信プロトコル
Google Chrome
ウェブサーバー シグナリングサーバ 他ピア
プラグイン
(1)
(2)
(3)
(4)
(5)
コンテンツ (HTTP)
コンテンツ (WebRTC)
シグナリング (HTTP)
図 3.2 ブラウザキャッシュ共有システムでの通信の様子
他ピアとの通信では、所有しているブロック情報の交換や、ブロックの送信要求、ブロッ
ク送信などが行われる。
3.3.1
シグナリングサーバー
本稿のシステムでは、Web サーバーが提供するファイルごとに、現在通信をしているピア
の情報を管理する。この役割を担うのがシグナリングサーバーである。本システムでは、シ
グナリングサーバーは Web サーバーでファイル配信を行っている側が提供する必要がある。
3.4
通信プロトコル
本稿のシステムでは、通信に HTTP と WebRTC を併用している。通信は、以下の手順
で行われる。
1. HTTP リクエストの送信 (図 3.2 (1))
まず、Web サーバーに対して HTTP でリクエストを送信する。これは、通常の Web
リクエストと同じように、ユーザーの操作によって送信される。リクエストヘッダに
は、クライアントが本稿のシステムに対応していることを示す、特別なヘッダを付加す
–7–
3.4 通信プロトコル
るこのヘッダは、ブラウザに導入されたプラグインによって自動的に付与される。レス
ポンスヘッダには、サーバー側が本稿のシステムに対応していることを示すヘッダと、
シグナリングサーバーの情報 (ホスト名、及びポート番号) が付与される。
2. リダイレクト処理 (図 3.2 (2))
次に、サーバー側が対本稿のシステムに対応している場合、プラグインによるキャッ
シュ共有を行うため、プラグインが提供する内部サーバーへリダイレクトを行う。ブラ
ウザはリダイレクト先へ HTTP リクエストを送信する。リダイレクトされたプラグイ
ンは、Web サーバーに対してコンテンツ長の取得を行う。コンテンツ長の取得が成功
した場合は、対応する長さのバッファを用意し、転送を開始する。
3. ピア一覧の取得 (図 3.2 (2))
次に (2) 並行して、シグナリングサーバーに対してピア一覧の取得を行う。この際、自
らのピアの情報もシグナリングサーバーに送信する。
4. Web サーバからのコンテンツ転送 (図 3.2 (4))
次に、メインの Web サーバーからの転送を開始する。Web サーバーからは、ブロック
ごとに前方からデータ取得を行う。ウェブサーバーから受信したデータは、ブロックが
揃い次第、ブラウザへ転送をする。
5. 他ピアとの通信 (図 3.2 (5))
最後に (4) と並行して WebRTC を利用して他ピアと通信を行う。この処理は、ダウン
ロードが完了するまで、他のピアが存在する限り繰り返される。この際、Web サーバー
から通信を行う際とは逆に、なるべく後方からブロックごとに転送を行う。これは、な
るべく多くのデータを他のピアから取得するためである。
–8–
ピア 2
ピア 1
中継終了
サーバーから
取得済
図 4.1
他ピアから
取得済
ブラウザキャッシュ共有システム稼働時の様子
第4章
ブラウザキャッシュ共有によるデー
タ配信システムの実装
本章では、本稿で提案したシステムを実際に実装し、動作させる。提案したシステムは、
ウェブブラウザのプラグインとして動作させるため、今回は Google Chrome をターゲット
のブラウザとし、Google Chrome 上で動作するプラグインを実装した (図 4.1)。
Google Chrome のプラグインは、実行環境に非依存な技術で構築されている。例えば、
オペレーティングシステムや CPU などが変わっても、動作させることができる。そのため、
環境を問わず、多くのクライアントで動作させることが可能だ。また、クライアントサイド
は対象とするブラウザが存在すれば、プラグイン単体で動作し、別途追加のソフトウェアを
要求としない。これによって、クライアントサイドでの利用が非常に容易となっている。
–9–
4.1 ブラウザプラグインの実装
クライアント
ブラウザ
サーバ
通常の HTTP 通信
ウェブページ
転送される通信
内部 HTTP
コネクション
Location ヘッダ
挿入による転送
内部 HTTP
サーバ
WebRTC による
他ピアとの通信
図 4.2
4.1
ブラウザキャッシュ共有システムの動作
ブラウザプラグインの実装
本システムのプラグインは Google Chrome で動作する。Google Chrome のプラグイン
は、JavaScript で記述され、Google Chrome 上に搭載された V8 JavaScript エンジンで動
作する。本システムのプラグインは、TypeScript で記述され JavaScript へ変換している。
本システムのプラグインでは、Web サーバーが本システムに対応していた場合、通常の
HTTP 通信から本システムによる通信へ切り替える (図 4.2)。切り替え後は、プラグイン
が提供する内部 Web サーバーを通じて通信を行う。
本システムのプラグインは、Google Chrome が提供する API を利用して実装されてい
る。本稿のシステムのプラグインでは、Web 通信の監視や、内部 Web サーバーの実装など
の部分に API を利用している。
– 10 –
4.1 ブラウザプラグインの実装
4.1.1
既存通信のリダイレクト処理
本稿のシステムでは、通常の Web 通信とキャッシュ共有システムが共存し、どちらも同
時に利用することが可能である。それを可能にしているのが、既存通信のリダイレクト処理
である。
通信処理のリダイレクトは、 HTTP ヘッダを利用して制御されている。本稿のシステム
を利用しているクライアントは、Web サーバーへリクエストを行う際に以下のヘッダが付
けられる。
ノード識別子としてヘッダに付与するプロパティ行
P2P: on
Web サーバーはこのヘッダを見て、クライアントに応じて処理を切り替えることが可能
である。もし、Web サーバーが本稿のキャッシュ共有システムに対応している場合、以下
P2P-WebRTC のヘッダが付与されている。
キャッシュ共有システムでサーバーが返すヘッダ
P2P-WebRTC: PeerJS peerjs api [email protected]:9000 localhost:1337
P2P-WebRTC ヘッダは 3 つの部分から構成されている。1 つ目はピア ID の種別であ
る。上記の P2P-WebRTC ヘッダでは、ピア ID として PeerJS の ID を使うことを示して
いる。
PeerJS は WebRTC を容易に扱うためのライブラリであり、ピアには IP アドレスとは
無関係なピア ID が振られる。ピア ID は PeerJS のシグナリングサーバーによって割り振
られる。この際に利用される情報がヘッダの 2 つ目の引数である。
3 つ目の引数は、本稿のシステムで用いるシグナリングサーバーの情報である。2 つ目の
引数のシグナリングサーバーは接続先 ID の解決に用いられるが、3 つ目の引数のシグナリ
ングサーバーは、ファイルのキャッシュデータを保持しているピアを解決するために用いる
ものである。
クライアントは、正常に P2P-WebRTC ヘッダが正常なフォーマットである場合、プラ
– 11 –
4.1 ブラウザプラグインの実装
グイン内部にある Web サーバーへリダイレクト処理を行う。
4.1.2
内部 Web サーバー
本システムでは、ブラウザのプラグインで内部向けの Web サーバーを構築している。こ
の内部 Web サーバーは、コンテンツ提供元の Web サーバからの受信データと、WebRTC
を用いて受信したデータを統合して利用するために用いる。
内部 Web サーバーでは、任意のタイミングで、任意のブロックのリクエストやレスポン
スが発生しても大丈夫なように受信バッファが設計されている。クライアントへは、受信
バッファの中で送信可能なブロックが受信され次第、送信される。
WebRTC を用いたピア間通信の際、ピアへの転送リクエストは行ったが、何らかの理由
でレスポンスが返ってこなかった場合は、コンテンツ提供元の Web サーバーへリクエスト
を行い、処理が続行される。
4.1.3
WebRTC による転送処理
本システムでは、WebRTC を用いてピア間の所有ブロックの情報交換やデータブロック
の転送を行う。対象のファイルに複数ピアが存在する場合、同時に複数のコネクションが張
られ、並列に処理が行われる。
ピア間の通信には、大きく分けて以下の 3 種類が存在する。
• 所有ブロックの情報交換
• 相手所有ブロックの転送リクエスト
• 所有ブロックの相手への転送
これらの通信処理は、同一形式のパケットで複数種類の処理が行えるようになっている。
パケットは JSON データをバイナリにシリアライズされた形式で交換される。パケット形
式は TypeScript のインターフェイスとして以下のように定義される。
– 12 –
4.2 シグナリングサーバーの実装
interface PeerjsDataConnectionMessage {
hadBlocks?: boolean[];
blockNumber?: number;
blockData?: ArrayBuffer;
}
通信内容はパケットの状態により判断される。どの状態にも当てはまらない場合、無効な
パケットとして無視される。
表 4.1 パケットの状態
4.2
hadBlocks
blockNumber
blockData
内容
あり
なし
なし
所有ブロック情報の送信
あり
あり
なし
ブロック要求
あり
あり
あり
ブロック送信
シグナリングサーバーの実装
シグナリングサーバーの API は REST (Representational State Transfer) API として
提供される。今回実装したシグナリングサーバーは Node.js で実装されているが、API の
み共通していれば実装形態は特に問わない。
本システムでは、以下の様な API を用意した。すべての API はリクエストメソッドに応
じた HTTP パラメータで値を送信し、結果を JSON で取得する。
• ピア情報の追加
自身のピアの情報をダウンロードするファイルの情報と共に送信し、シグナリングサー
バーに登録する。
• ピア一覧の取得
現在ファイルをダウンロードしているピアの一覧を取得する。
– 13 –
4.2 シグナリングサーバーの実装
• ピア情報の削除
自身のピアの情報をダウンロードするファイルの情報と共に送信し、シグナリングサー
バーから削除する。
– 14 –
第5章
総括
近年、インターネットへのブロードバンド接続環境が一般化し、動画をはじめとする大容
量コンテンツの配信トラフィックが急増、サーバーへの負荷集中も問題となっている。
それらの問題を解決するため、P2P Web Proxy と呼ばれる既存の技術が存在する。しか
し、P2P Web Proxy をクライアントが実際に利用するにはいくつかの壁があり、問題を解
決するには至っていない。本稿では、それらの問題を解決するための手段として、クライア
ントに対して利用し易い「WebRTC を利用したブラウザキャッシュ共有によるデータ配信
システム」を提案し、実際に実装した。
本システムは、Web ブラウザのプラグインの形で実装しているため、Web ブラウザ単体
で動作する。また、ピア同士の通信プロトコルには従来の HTTP に代わって WebRTC を
用いている。さらに、キャッシュの共有に、同じファイルをダウンロード中のピアのみで行
う「強調ダウンロード」を使っている。これによって、P2P Web Proxy 存在した 3 つの問
題を解消した。ブラウザの他に別途ソフトウェアが必要である問題は、ブラウザのプラグイ
ンとして実装することにより解決した。他ピアからの待ち受けが必要であり、セキュリティ
上の懸念となっていた点については、通信に WebRTC を使い、ペアリングにシグナリング
サーバーを用いることで解決した。また、キャッシュを継続保持していたため、ストレージ
を圧迫する問題があったが、これは強調ダウンロードによって解決した。
このように、本研究では既存システムに存在した 3 つの問題を解決、及びそのシステムが
実現可能であることを示した。
– 15 –
謝辞
本研究を行うにあたり、ご指導をいただきました植田和憲講師、副査を引き受けていただ
いた横山和俊教授,松崎公紀准教授に深く感謝いたします。
また、本研究の元となったシステムを考案・実装していただいた西峯誠志氏に深く感謝い
たします。本システムの基板となる考え方は、西峯誠志氏によって頂いたものです。西峯誠
志氏の研究が存在しなければ、本研究は存在し得ませんでした。
最後に、本研究で助言を頂きました小柳翔氏, 菅谷和馬氏, 冨田涼太氏, 柳瀬仁志氏, 入本
静哉氏、お世話になりました高知工科大学の教職員の方々に厚く御礼申し上げます。
– 16 –
参考文献
[1] 総 務 省, “平 成 25 年 版 情 報 通 信 白 書,” 2013. http://www.soumu.go.jp/
johotsusintokei/whitepaper/ja/h25/Z.
[2] Cisco System, “Cisco visual networking index:予 測 と 方 法 論 、2012 ∼ 2017
年,” 2013. http://www.cisco.com/web/JP/solution/isp/ipngn/literature/
pdf/white_paper_c11-481360.pdf.
[3] Alan B. Johnston, Daniel C. Burnett, 内田直樹, “WebRTC ブラウザベースの P2P
技術,” リックテレコム,2014.
– 17 –
Fly UP