一対多通信における ネットワーク障害物対応方法選択プロトコルの設計

Presentation on theme: "一対多通信における ネットワーク障害物対応方法選択プロトコルの設計"— Presentation transcript:

1 一対多通信における ネットワーク障害物対応方法選択プロトコルの設計
広島市立大学 情報科学部情報メディア工学科 インターネット工学研究室 ０４２１０３７ 日山雅之 広島市立大学インターネット工学研究室の日山です。 今回は一対多通信でネットワーク障害物の対応方法を選択するプロトコルについて提案させていただきます。

2 発表概要 １．研究背景 ２．提案プロトコルについて ３．提案プロトコルを実装したプロトタイプ ４．おわりに
今回の発表はこのような流れで行っていきます。

3 研究背景 遠隔プレゼンテーションシステム”GOZARU”を使用して、離れた３大学(慶応SFC、京大)での合同講義を行っている 問題点
ネットワーク障害物(NAT, ファイアウォール等)が原因となりIPv4での利用ができない場合があって、他組織に展開するにあたって普及の妨げとなっている そのため、IPv4のネットワーク障害物が介在する場合でも通信可能な”GOZARU”の作成を開始 それにあたり、ネットワーク障害物に応じて対応方法を決定するプロトコルを提案、作成する 今回提案するプロトコルを作成するにあたった背景を説明します。 僕たち大学では遠隔プレゼンテーションシステムGOZARUを使って、京都大学と慶応義塾大学と3大学合同で講義を行っています。 僕たちの研究室ではそれをお手伝いさせていただいています。 GOZARUとは講演者のパワーポイントファイルでの動作を受講者のPCでオンデマンドで再現する、つまり講演者のPCでのパワーポイントの動作と受講者のPCでのパワーポイントの動作を同期させることができるシステムです。 しかしGOZARUはNATやファイアウォールなどのネットワーク障害物が原因で動作しない場合があります。 教育機関のPCはだいたいネットワーク障害物の内部にあるため、他の教育機関で使ってもらうにあたってこれは大きな問題点となっています。 そのため、ネットワーク障害物に対応できるGOZARUを作成することになり、 それにあたって、ネットワーク障害物に応じて対応方法を決定するプロトコルを提案し、作成しています。

4 GOZARUとその問題 NAT Traversal技術を使って 同期を可能にする [ GOZARUとは ]
複数拠点でのPowerPointファイルのページ遷移と操作の 同期を実現することができる、遠隔プレゼンテーションシステム NAT・NAPT内部のネットワークであるとプライベートアドレスが割り当てられ、講演者は一意に特定できない 受信した制御情報通りの動作を実行 講演者が実行した制御情報を受講者へ送信 講演者と同期 制御情報が送れない 同期ができない N A T ・ P 制御情報 プライベートアドレス がんばって説明(UDPを使って制御情報を送信) NAT Traversal技術を使って 同期を可能にする

5 NAT Traversal技術 UDP Hole Punching Relaying (利点)通信開始後は、双方のノードのみで直接通信を行う
(欠点)一方がSymmetric NAT内部であると実行できない Relaying (利点)ほとんどのネットワーク環境で実行できる (欠点)Relayingによるオーバーヘッドで遅延が発生する 　Relayサーバーに負荷が集中する 今プロトコルで使用するNAT Traversal技術としてUDP Hole PunchingとRelayingがあります。 UDP Hole Punchingとは両端のノードがNAT内部にも関わらず、直接通信を可能にする技術です。 しかしこれは一方がSymmetricNATという種類のNATの配下であると実行することができません。 Relayingは、グローバルアドレスを持つ第三のノードを経由してデータ送信を行う技術です。 これはほとんどのネットワーク環境で実行することができるのですが、 Relayingによるオーバーヘッドで遅延が発生してしまったり、 Relayサーバーに負荷が集中するなどといった欠点があります。 これらの特性を基に、ネットワーク環境に応じて使用するNAT Traversal技術を選択するプロトコルを設計しました。 これらの特性を考慮して、ネットワーク環境に応じて NAT Traversal技術を選択するプロトコルを設計

6 提案プロトコルについて 「ネットワーク障害物対応方法選択プロトコル」
講演者(Sender)と受講者(Receiver)の双方のネットワーク環境に応じて、対応方法を決定するプロトコル 対応のための戦略を次の４つを順に試す １ 直接接続 ２ NAT内部ノードからNAT外部ノードへ接続開始 ３ UDP Hole Punching ４ Relaying 直接 そのプロトコルは「ネットワーク障害物対応方法選択プロトコル」と名づけています。 対応方法は対応不要、NAT内部ノードからNAT外部ノードへ接続開始、UDP Hole Punching、Relayingの４つです。 対応方法は上から順に実行できるかどうかを判断し、できるなら実行します。 対応方法には直接通信を可能にする方法と、間接通信でデータ送信を行うものの２つに分けられます。 唯一の間接通信であるRelayingは第三のノードを使用してしまうため、できれば直接通信を、そして直接通信のなかでも通信確立までの処理が簡単なものから選択しています。 直接通信ができない場合は、間接通信、つまりRelayingを行います。 (通信確立までの処理が複雑) 間接 (第三のノードを使用してしまう)

7 対応方法決定の組み合わせ SenderおよびReceiverのネットワーク環境に応じて決められる、対応方法の組み合わせ
通信相手が変わっても同じポート番号が使用される セッション毎に新たなポート番号が使用される NATなし Cone NAT Symmetric NAT 直接接続 NAT内部ノードからNAT外部ノードへ 接続開始 Cone NAT UDP Hole Punching Relaying Symmetric Receiver Sender 対応方法決定プロトコルを実装したGOZARUではSenderとReceiverのネットワーク環境からこのような組み合わせで対応方法を決めています ここでのネットワーク環境としてNATがない場合、Cone NATという種類のNATの配下である場合、Symmetric NATという種類のNATの配下である場合の３つです。 Cone NATとは～ それに対してSymmetric NATとは～ この組み合わせはGOZARUで使用する場合での組み合わせなので、 他のプログラムに実装する場合は、そのプログラムに合わせて組み合わせを変更してください。

8 ワーク環境にNATがあるかないか、あった 場合はそのNATの種類と変換後のアドレスを
対応方法決定までの流れ STUNサーバーとは 問い合わせがあったクライアントのネット ワーク環境にNATがあるかないか、あった 場合はそのNATの種類と変換後のアドレスを クライアントへ通知する Brokerが対応方法決定の組み合わせにしたがって対応方法を決定 Sender, Receiverが自ネットワークのネットワーク情報をBrokerに通知 STUNサーバーは要請があったクライアントのネットワーク情報を通知 Sender, Receiverが自ネットワークの情報をSTUNサーバーに要請 BrokerがSender, Receiverに対応方法を通知 通知された対応方法を実行 がんばってせつめい

9 提案プロトコルを実装したプロトタイプ 提案プロトコルを実装したプロトタイプ”GOZARU+”を現在実装中 Sender+/Receiver+
GOZARUからBroker通信部分、TCPで制御情報の送受信を行う部分を追加 Windows上で、C#で開発 Broker 現在、Linux上にてPerlで開発したプロトタイプの動作を確認済み 今後は、パフォーマンス向上のためにC言語へ移植予定 Relayingのみ動作確認済み 提案したプロトコルを実装したプロトタイプ、 すなわちネットワーク障害物に対応できるGOZARUである、GOZARU+を現在開発中です。 講演者と受講者のプログラムであるSender+とReceiver+は 前のGOZARUからBrokerとの通信部分と、RelayingのためにTCPで制御情報の送受信を行う部分を追加しました。 開発言語はC#です。 BrokerはLinuxで、現在はPerlで開発したプロトタイプで動作を確認していましたが、 今後はパフォーマンス向上のためにC言語に移植する予定です。 全体の進行具合としてはRelayingのみ動作確認済みです。

10 おわりに まとめ 今後の課題 IPv4環境でGOZARUを展開するためにネットワーク障害物を回避する方式を提案
Relayingの動作を確認 今後の課題 プロトタイプの完成、動作確認 選択方法の性能の評価 最後にまとめと今後の課題を説明します。 今回の発表内容をまとめると、 （項目を口で言う） 今後の課題は、まずプロトタイプを完成させ、動作確認を行い、問題なく動かしたいと思っています。 その後に、今回提案した選択方法の性能の評価していきたいと思います。 以上で発表を終わります。 御清聴ありがとうございます。

11

12 NAT (Network Address Translator)
プライベートアドレスとグローバルアドレスを変換する技術 IPアドレスにプライベートアドレスが割り当てられたノードが、インターネットへ接続をするときだけグローバルアドレスに変換して通信を行うことで、グローバルアドレスを節約することが可能となる

13 NATの利点・欠点 利点 欠点 ひとつのグローバルアドレスで複数のノードがインターネットに接続することができる
グローバルアドレスに変換されなければインターネットに接続していないも同然であるため、セキュリティ面が向上する 欠点 プライベートアドレスが割り当ててあるため、外部から接続を行ったり、データを送ることができない 変換によるオーバーヘッドで遅延を起こしてしまう

14 NAPT (Network Address Port Translator)
アドレスのみでなく、ポート番号も含めて変換を行う。これにより、単一のグローバルアドレスを多数のプライベートアドレスに変換できる 変換例 :7800 ⇔ :7801 :8900 ⇔ :7802 NATの場合 :9700 ⇔ 変換後のアドレスは同一であるが、ポート番号が異なるため、変換前のアドレスを区別することができる

15 NATの種類 Cone NAT Symmetric NAT Full Cone NAT Restricted Cone NAT
Port Restricted Cone NAT Symmetric NAT

16 Full Cone NAT Server A NAT Client Server B

17 Restricted Cone NAT Server A NAT Client Server B

18 Port Restricted Cone NAT
Server A NAT Client Server B

19 Symmetric NAT Server A NAT Client Server B

20 NAT内部ノードからNAT外部ノードへ接続
どこ？

21 UDP Hole Punching Global B : Port B [宛先]Global C : Port C [NAT テーブル]
◆Private A : Port A’ ⇔ Global A : Port A : [宛先]Global C : Port C [NAT テーブル] ◆Private A : Port A’ ⇔ Global A : Port A : [宛先]Global C : Port C : [宛先]Global B : Port B [NAT テーブル] ◆Private B : Port B’ ⇔ Global B : Port B : [宛先]Global C : Port C : [宛先]Global A : Port A NAT対応ルーターAと NAT対応ルーターBの アドレス(ポート番号)を取得 [NAT テーブル] ◆Private B : Port B ⇔ Global B : Port B [宛先]Global C : Port C NAT対応ルーターAにパケットを送信 STUN Serverと通信を行う NAT対応ルーターBのアドレス(ポート番号)を通知 STUN Serverと通信を行う NAT対応ルーターAのアドレス(ポート番号)を通知 NAT対応ルーターBにパケッ トを送信 NATテーブルの宛先に登録されたアドレスからのパケットでないため通さない

22 なぜSymmetric NATが原因で UDP Hole Punchingができないのか？
◆ Private A : Port A0 ⇔ Global A : Port A2 [宛先] Global B : Global B1 [NAT テーブル] ◆ Private B : Port B0 ⇔ Global B : Port B2 [宛先] Global A : Global A1 Global B : Port B1 Global A : Port A1 インターネット

23 Relaying

24 対応方法と使用する通信プロトコル TCP/UDP UDP TCP 対応不要 NAT内部ノードからNAT外部ノードへ接続開始
UDP Hole Punching UDP Relaying TCP

25 参考文献 B.Carpenter, “Internet Transparency”, RFC2775, IETF,(2000).
B. Ford, P. Srisuresh, and D. Kegel, “Peer-to-peer communications across network address translations”, In the 2005 USENIX Annual Technical Conference, USENIX, pp (2005). J. Rosenberg, R. Mahy, and C. Huitema,”Traversal using relay NAT (TURN)”, Internet-Draft, IETF (2005). J.Rosenberg, J. Weinberger, “STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)”, RFC3489, IETF, (2003)