250 likes | 386 Views
一対多通信における ネットワーク障害物対応方法選択プロトコルの設計. 広島市立大学 情報科学部情報メディア工学科 インターネット工学研究室 0421037 日山雅之. 発表概要. 1.研究背景 2.提案プロトコルについて 3.提案プロトコルを実装したプロトタイプ 4.おわりに. 研究背景. 遠隔プレゼンテーションシステム ” GOZARU” を使用して、離れた3大学 ( 慶応 SFC 、京大 ) での合同講義を行っている. 問題点.
E N D
一対多通信におけるネットワーク障害物対応方法選択プロトコルの設計一対多通信におけるネットワーク障害物対応方法選択プロトコルの設計 広島市立大学 情報科学部情報メディア工学科 インターネット工学研究室 0421037 日山雅之
発表概要 1.研究背景 2.提案プロトコルについて 3.提案プロトコルを実装したプロトタイプ 4.おわりに
研究背景 • 遠隔プレゼンテーションシステム”GOZARU”を使用して、離れた3大学(慶応SFC、京大)での合同講義を行っている 問題点 ネットワーク障害物(NAT, ファイアウォール等)が原因となりIPv4での利用ができない場合があって、他組織に展開するにあたって普及の妨げとなっている • そのため、IPv4のネットワーク障害物が介在する場合でも通信可能な”GOZARU”の作成を開始 それにあたり、ネットワーク障害物に応じて対応方法を決定するプロトコルを提案、作成する
GOZARUとその問題 [ GOZARUとは ] 複数拠点でのPowerPointファイルのページ遷移と操作の 同期を実現することができる、遠隔プレゼンテーションシステム NAT・NAPT内部のネットワークであるとプライベートアドレスが割り当てられ、講演者は一意に特定できない 受信した制御情報通りの動作を実行 講演者が実行した制御情報を受講者へ送信 講演者と同期 制御情報が送れない 同期ができない N A T ・ N A P T 制御情報 プライベートアドレス NAT Traversal技術を使って 同期を可能にする
NAT Traversal技術 • UDP Hole Punching (利点)通信開始後は、双方のノードのみで直接通信を行う (欠点)一方がSymmetric NAT内部であると実行できない • Relaying (利点)ほとんどのネットワーク環境で実行できる (欠点)Relayingによるオーバーヘッドで遅延が発生する Relayサーバーに負荷が集中する これらの特性を考慮して、ネットワーク環境に応じて NAT Traversal技術を選択するプロトコルを設計
提案プロトコルについて • 「ネットワーク障害物対応方法選択プロトコル」 講演者(Sender)と受講者(Receiver)の双方のネットワーク環境に応じて、対応方法を決定するプロトコル 対応のための戦略を次の4つを順に試す 1 直接接続 2NAT内部ノードからNAT外部ノードへ接続開始 3UDP Hole Punching 4 Relaying 直接 (通信確立までの処理が複雑) 間接 (第三のノードを使用してしまう)
対応方法決定の組み合わせ • SenderおよびReceiverのネットワーク環境に応じて決められる、対応方法の組み合わせ 通信相手が変わっても同じポート番号が使用される セッション毎に新たなポート番号が使用される Receiver Sender
対応方法決定までの流れ STUNサーバーとは 問い合わせがあったクライアントのネット ワーク環境にNATがあるかないか、あった 場合はそのNATの種類と変換後のアドレスを クライアントへ通知する Brokerが対応方法決定の組み合わせにしたがって対応方法を決定 Sender, Receiverが自ネットワークのネットワーク情報をBrokerに通知 STUNサーバーは要請があったクライアントのネットワーク情報を通知 Sender, Receiverが自ネットワークの情報をSTUNサーバーに要請 BrokerがSender, Receiverに対応方法を通知 通知された対応方法を実行
提案プロトコルを実装したプロトタイプ • 提案プロトコルを実装したプロトタイプ”GOZARU+”を現在実装中 • Sender+/Receiver+ • GOZARUからBroker通信部分、TCPで制御情報の送受信を行う部分を追加 • Windows上で、C#で開発 • Broker • 現在、Linux上にてPerlで開発したプロトタイプの動作を確認済み • 今後は、パフォーマンス向上のためにC言語へ移植予定 • Relayingのみ動作確認済み
おわりに • まとめ • IPv4環境でGOZARUを展開するためにネットワーク障害物を回避する方式を提案 • そのプロトコルを実装したGOZARU+を現在開発中 • Relayingの動作を確認 • 今後の課題 • プロトタイプの完成、動作確認 • 選択方法の性能の評価
NAT (Network Address Translator) • プライベートアドレスとグローバルアドレスを変換する技術 • IPアドレスにプライベートアドレスが割り当てられたノードが、インターネットへ接続をするときだけグローバルアドレスに変換して通信を行うことで、グローバルアドレスを節約することが可能となる
NATの利点・欠点 • 利点 • ひとつのグローバルアドレスで複数のノードがインターネットに接続することができる • グローバルアドレスに変換されなければインターネットに接続していないも同然であるため、セキュリティ面が向上する • 欠点 • プライベートアドレスが割り当ててあるため、外部から接続を行ったり、データを送ることができない • 変換によるオーバーヘッドで遅延を起こしてしまう
NAPT (Network Address Port Translator) • アドレスのみでなく、ポート番号も含めて変換を行う。これにより、単一のグローバルアドレスを多数のプライベートアドレスに変換できる • 変換例 192.168.1.100:7800 ⇔ 165.242.42.220:7801 192.168.1.101:8900 ⇔ 165.242.42.220:7802 • NATの場合 192.168.1.102:9700 ⇔ 165.242.42.220 変換後のアドレスは同一であるが、ポート番号が異なるため、変換前のアドレスを区別することができる
NATの種類 • Cone NAT • Full Cone NAT • Restricted Cone NAT • Port Restricted Cone NAT • Symmetric NAT
Full Cone NAT Server A NAT Client Server B
Restricted Cone NAT Server A NAT Client Server B
Port Restricted Cone NAT Server A NAT Client Server B
Symmetric NAT Server A NAT Client Server B
UDP Hole Punching [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テーブルの宛先に登録されたアドレスからのパケットでないため通さない
なぜSymmetric NATが原因でUDP Hole Punchingができないのか? [NAT テーブル] ◆ 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 インターネット
参考文献 • 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. 179-191 (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)