...

日本語 - IPLab

by user

on
Category: Documents
10

views

Report

Comments

Transcript

日本語 - IPLab
2009/5/22
概要
 まずは簡単な復習
 アプリケーションモデル
 プレゼンテーション層
 P2Pって何?
 大規模サービスはどう作る?
アプリケーションプロトコル
情報ネットワーク論I 第12回
まずは復習:TCP/IP Protocol Suits
OSI
2
上位層プロトコル
 Session Layer以上を上位層プロトコル (Upper Layer
Protocol) と呼ぶ
TCP/IP
処理単位
Application
Message / Stream
Transport
Transport
Transport Packet
Port
Network
Internet
IP Datagram
IP address
Data Link
Network Interface
Frame
Datalink Address
Physical
Hardware
アドレス
– 各アプリケーション毎に定義される
– アプリケーションからの要求に強く拘束される
Application
Presentation
情報ネットワーク論I 第12回
1
Session
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
3
Session Layer
Presentation Layer
 セション層
 通信の意味的な単位の定義
 プレゼンテーション層
 データの表現形式
– Transaction
– Session
– システム・プラットフォームの差異無く、データが正しく表現・理解
されるための基盤
– 例
 通信の単位に対して、処理を定義
• 数値1の表現
– Transaction Logging & Roll-back operation
– Session Termination
– 何バイト使って表現するか
» 1, 2, 4, less than 1 byte (6 bits), ….
– バイトオーダーはどうするのか
» Little Endian / Big Endian
– 送信する場合のビットオーダーはどうするのか
» MSB first, LSB first
 アプリケーションから見た、通信の概念的な定義と基本
的な処理
情報ネットワーク論I 第12回
4
5
情報ネットワーク論I 第12回
6
1
2009/5/22
Application Layer
 アプリケーション層(応用層) (Layer 7)
 具体的なアプリケーションを構成するためのプロトコル
– 注意:アプリケーションそのものではない
– 電子メールの交換では SMTP (simple mail transfer protocol)
が定義されている
– しかしながら電子メール交換機能を持ったアプリケーションが数
多く存在
アプリケーションモデル
• MTA: sendmail, qmail, postfix, etc….
• MUA: Eudora, Mozilla Thunderbird, MS/Outlook, etc….
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
7
アプリケーションモデルの視点
8
通信モデル: client/server
 通信モデル
– Client / Server model
– Broadcast based parallelization
– Peer-to-Peer (P2P) model
server
client
Request/reply
 処理モデル
– 副作用有り / 無し
• Process semantics
– Atomic / checkpoint
client
 そもそもどんな機能を提供するのか
– End user services
– Network management
情報ネットワーク論I 第12回
9
情報ネットワーク論I 第12回
なぜ client / server から始まったのか
Client / server の限界
 機能的な分離がわかりやすい
 全ての処理ボトルネックはサーバ
– ユーザインタフェース: client
– 各種処理: server
10
– 大規模サービスを構築する場合に、サーバの大規模化が必要
– 良好なスケーラビリティ (scalability) 確保
– サービスの大規模化に対する様々な挑戦
• 機能集約と資源集中管理が実現できる
• 運用管理も実施しやすい構造
 双方向情報交換モデルに合わない
 サービス発見モデルが簡単だった
– 大多数のクライアントに対して、実質尐数のサーバ
– Well-known address (サーバ) + well-known port (サービスの
種類)によって、最初はサービスを発見していた
– 動的関係づけ (dynamic binding) は難しかった
– サーバにある情報を、クライアントが活用する
– クライアント側から情報を大量に注入するようなサービス、クライ
アント側の資源を積極的に利用しようとすると無理が多い
• 名前モデルも、管理モデルが決まらなかった
• スケーラビリティの維持が困難(大規模サービスが作りにくい)
• 現在は dynamic binding も広く行われている (Sun RPC bind etc.)
情報ネットワーク論I 第12回
11
情報ネットワーク論I 第12回
12
2
2009/5/22
通信モデル: parallelization using broadcast
なぜ、ブロードキャスト?
 ブロードキャスト型
 “up & running” 状態にあるホストに対して、UDPブロード
キャストを使ってコマンドを送り込む
– 定期的に情報を同報通信 (broadcast) によって交換
– すべてのプロセスで情報を共有
– アクティブなホストを見つけることができる
– 同じ port に関係づけられているホスト上のプロセスは、同じ処理
をする→並列処理を駆動するブロードキャスト
– 同じネットワークセグメント上に存在するホストを活用
– 例) rwhod
 TCPで構成すれば、同一セグメント上という問題を解決
できる
– Server federation の基本的なアイディアは、この辺りから生ま
れてきている
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
13
通信モデル:サーバ連携型
14
通信モデル: Peer-to-Peer (P2P)
 ユーザが持つ資源同士が直接情報交換を行う
– どのシステムもサーバでありクライアントである
server
 最近大流行
– Gnutella, Winny, …..
server
client
 情報の発見とシステム全体としての安定性確保が課題
Request/reply
server
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
15
Overlay network
副作用問題(1)
 P2P型サービスの展開によって広く認知
 実ネットワーク構造とは違うネットワーク構造を、アプリ
ケーション層で作り上げる
 通信は失敗する
16
– Packet loss (喪失)
– Packet duplication (重複)
– Retransmission (再送)による複雑な処理
– ネットワーク構造の仮想化
 処理の副作用
– 同一の処理要求が来たときに、同一実行性をどのように保つの
かが一つの処理として真面目に考える必要がある
– Identification について正しい理解
– 実行の意味
IP層
• Exactly once semantics
• At least once semantics (エラーを許容)
• At most once semantics (再送を許容)
情報ネットワーク論I 第12回
17
情報ネットワーク論I 第12回
18
3
2009/5/22
副作用問題(2)
副作用問題を考えると….
 “idempotent”
 Idempotent な処理は並列化が簡単
 サーバの内部構造を分解することで、大規模処理が可
能
– サーバに対して複数の同一処理リクエストが到着し、処理されて
も、毎回同じ結果が得られる
– このような処理系を作る事によって、再送処理の構成をシンプル
に構築することができる
全体で一つのサーバに見える
• しかし状態を変更する処理には注意が必要
The Internet
Idempotentな処理
• ロードバランサの利用
• いわゆるクラスタを形成
• 負荷分散・障害管理に有効
情報ネットワーク論I 第12回
副作用有り処理
• 処理集約を実現
• DB等が対象
情報ネットワーク論I 第12回
19
20
これまでの技術
 Non structured
– Binary
– ASCII
プレゼンテーション層
 Structured
– TLV: Type, Length, Value
– ASN.1
– XML
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
21
Trade-off
22
Binary & ASCII
取扱いの容易さ/表現能力の高さ
 Binary
 ASCII
– IP header (RFC791), TCP
header (RFC793)
– ホスト・ビットオーダ (host bit
order) とネット・ビットオーダ
(network bit order) の違いを
明確に定義
– 数値(整数値)の取扱いの適
正化
XML
ASN.1
ASCII
– FTP (RFC959)
– SMTP (RFC2821)
– POP3 (RFC1939) 等
– 8bit clean でない通信路でも
正しいデータ転送を保証
TLV
binary
帯域使用効率
情報ネットワーク論I 第12回
23
情報ネットワーク論I 第12回
24
4
2009/5/22
FTP
SMTP
001.204.01754: 220 ftp.isi.edu NcFTPd Server (free educational license) ready.
176.020.00021: USER anonymous
001.204.01754: 331 Guest login ok, send your complete e-mail address as password.
176.020.00021: PASS -wget@
001.204.01754: 230 Logged in anonymously.
176.020.00021: SYST
001.204.01754: 215 UNIX Type: L8
176.020.00021: PWD
001.204.01754: 257 "/" is cwd.
176.020.00021: TYPE I
001.204.01754: 200 Type okay.
176.020.00021: CWD /in-notes
001.204.01754: 250 "/in-notes" is new cwd.
情報ネットワーク論I 第12回
1758: 220 ns.ixj-mc.com ESMTP Sendmail 8.9.3p2+3.1W/3.7W/ns; Fri, 30 May
2003 00:15:43 +09
0025: EHLO mf.aist-nara.ac.jp
1758: 250 ns.ixj-mc.com Hello 168.pool3.ftthtokyo.att.ne.jp [165.76.67.168], pleased
to meet you
0025: MAIL FROM:<[email protected]> SIZE=1524
1758: 250 <[email protected]>... Sender ok
0025: RCPT TO:<[email protected]>
1758: 250 <[email protected]>... Recipient ok
0025: DATA
1758: 354 Enter mail, end with "." on a line by itself
0025: Received: from mf.aist-nara.ac.jp (localhost [127.0.0.1])
3 +0900 (JST)
情報ネットワーク論I 第12回
25
TLV
本格的なプレゼンテーション層技術の登場
 Type, Length, Value
 OSPF (RFC2328)
 RADIUS (RFC2138)
 XDR (eXtended Data Representation) for Sun
RPC/NFS (1980’s)
 ASN.1 (1980’s)
 XML (1990’s)
 構造化した情報表現
 求められる特性
26
– 帯域使用効率 (wire efficiency)
– 取り扱いの容易さ
– 記述性
– Typeによって処理を駆動
– Lengthを入れた事で可変長データを扱えるようになる
– Valueは、それぞれ表現形式を定義する
• データ型(static typing), 名前空間の管理 (name space)
• データの自己説明性
– ツール、ライブラリの充実
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
27
ASN.1 (BER encoding)
SNMPで用いられる Object Identifier
 (tag, length, value)
 Iso(1).org(3).dod(6).internet(1)
– Tag: ASN.1 type
– Length: size of the ASN.1 value
– Value: ASN.1 value
28
– Mgmt (2)
– Experimental (3)
– Private (4)
 1.3.6.1.2.1….
– SNMPで用いられるデータ構造を定義
– MIB-II (RFC1214),
– Structure of Management Information version 2 (SMIv2)
(RFC2578)
 ASN.1の型
–
–
–
–
INTEGER
OCTET STRING
OBJECT IDENTIFIER
SEQUENCE (配列)
情報ネットワーク論I 第12回
29
情報ネットワーク論I 第12回
30
5
2009/5/22
XML
XML namespace
 <?xml version = "1.0"?>
 <tag attribute="value">
 <another-tag another-attribute="value" />
 </tag attribute="value">
<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/1999/XMLSchema'
xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/'
soap:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>
<soap:Body>
<n:getQuoteResponse xmlns:n='urn:xmethods-delayed-quotes'>
<Result xsi:type='xsd:float'>7.92</Result>
</n:getQuoteResponse>
</soap:Body>
</soap:Envelope>
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
31
XMLにおけるデータ型:XML Schema
XML:その他の特徴
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/1999/XMLSchema“
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<namesp1:getQuote xmlns:namesp1="urn:xmethods-delayed-quotes">
<symbol xsi:type="xsd:string">AKAM</symbol>
</namesp1:getQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 データの自己説明性: RDF
 ツールの充実: XPath, XSLT,
 APIの充実: DOM, SAX, etc.
 一部分の署名、暗号化
情報ネットワーク論I 第12回
32
– XML Digital Signature
– XML Encryption
33
情報ネットワーク論I 第12回
34
情報ネットワーク論I 第12回
36
XMLはとても重要
 XMLを用いたシステムが広く使われるようになっている
– XMLでの表現
– XML処理系
 ネットワーク関わるサービスシステムを構築する場合に
は、XMLを用いるのが常識となっている
–
–
–
–
P2Pとは何か
XMLは必須科目
他のソフトウェアでもデータ表現にXMLを使うことが増えている
そろそろ標準的な手法に発展しそうだ
プログラミング言語+XML
情報ネットワーク論I 第12回
35
6
2009/5/22
ファイル交換の変遷
P2P/交換から共有へ ~ Winnyの登場まで
クライアントサーバ
 Warez交換・配布
ハイブリッドP2P
ピュアP2P
– ftp, WWW, Netnewsを利用した違法ファイルの交換・配布
– 規模が小さく注目を集めるには至らなかった
中心
: Server
 ファイル交換アプリケーションの登場
– 初期: Gnutella, NapsterによるP2Pアプリケーションの登場
– 中後期: WinMX ()、KaZaa ()としてより洗練された形へ
– ハイブリッド型P2P
ピア
 ファイル共有へと変化
– Winny (2002)の登場
– ピュアP2Pへ
– ブロードバンド化の後押しによる、より効率のいい流通形態
情報ネットワーク論I 第12回
中心
: Server
ピア
ピア
ランデブーも通信も中心で
行う
ランデブーを中心で行い、
通信をピア同士で行う
ランデブーも通信もピア同
士で行う
FTPやWWWを利用した
ファイル交換
WinMX, KaZaa
Gnutella, Freenet,
Winny
情報ネットワーク論I 第12回
37
P2Pファイル交換アプリケーションの普及
Napster
 Napster
 Gnutella
 Winny
 WinMX
 LimeWire
 Share
 BitTorrent
 Cabos
 特徴
38
– 所有する音楽ファイル(mp3)のリストを共有し、ファイル取得を可能とし
たソフトウェア
– ハイブリッド型P2Pとして実現されていた
– チャット機能が実装されており、ファイル共有を目的としたコミュニケー
ションツールとしても機能していた
 略歴
– Northeastern University(米マサチューセッツ州ボストン)の学生 シャウ
ン・ファニング(Shawn Fanning)氏が1999年1月に開発
– 2000年7月 RIAAより提訴され敗訴、ネットワークを停止
– 2003年10月より、音楽配信サービスとして再生
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
39
Gnutella
Winny (1)
 特徴
 Winnyとは
40
– WinMXの後継として日本人が開発したファイル共有のためのアプリ
ケーション
– ピュアP2P型によるファイル共有ネットワーク構築ソフトウェア
– 国産であることと手軽に利用可能だったことから大流行し、ファイル共有
ネットワークが構成された
– mp3ファイルに限らないさまざまなファイル形式の公開を可能と
したソフトウェア
– 管理中心となるサーバが存在せず管理主体も存在しない
– ピュアP2P型の実装
– その後のP2Pファイル交換ソフトウェアの参照モデルとなった
 略歴
 Winnyの略歴
– 2000年2月 米Nullsoft社の開発者から公開
– 2000年3月 公開、しかし公開元のAOL社の判断によって24時間
で公開停止
– さまざまなクローン版が登場している
情報ネットワーク論I 第12回
41
– 2002年5月6日 β版公開
– 2003年5月5日 2.0β版公開
– 2003年11月28日 Winny利用者の逮捕、開発者家宅捜索、開発の停止
(2.0β7.1)
– 2004年5月31日 京都地検が開発者を起訴、著作権法違反(公衆送信権の侵害)
の幇助罪
– 2004年6月1日 開発者保釈
– 2006年12月13日 京都地裁にて判決「有罪(罰金刑)、即日控訴
情報ネットワーク論I 第12回
42
7
2009/5/22
Winny (2)
Winnyをめぐる問題
 2003年時点で20万人(ネットワーク社調べ)~200万人
(ACCS調べ)のユーザーが存在と推定される
 2004年11月の逮捕者が発生以前以後で、国内トラフィッ
クの1/6近くが低減した (Winnyの利用減尐分?)
 2006年7月の報道では、175万人の利用者と推定
 流通する情報の質への問題
– 他人の著作物の違法流通
– 偽造ファイルや詐称ファイルの流通
– ウィルスの蔓延
 ファイルの取り扱い方法に原因
– ファイルという情報単位を用いたことが全ての原因
•
•
•
•
誰もが自由にファイル発信ができる
発信ファイルの取り消しができない
ファイル発信元の特定が不可能
目的とするファイルを正しく知る方法がない
– より構造化された情報が交換される必要がある
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
43
Winnyからわかったこと
P2P流通網の可能性
 潜在顧客の存在
 P2P流通網への期待
– 適切な価格と利便性によってはコンテンツ購入の顧客となりうる
層が存在することを証明した
 ユーザーによる自主的な流通網の構築
– コンテンツ流通における最大のコスト要因である流通網の整備
に対しての新しい解が存在することを示した
流通の中抜きによる価格引下げ
著作者からユーザーへの直接的な流通の可能性
コスト問題から無視されてきたマイナー著作物の流通整備
参入コストの低さによる様々な著作物の流通市場の整備
 P2P流通網の整備に必要とされる技術例
–
–
–
–
→ 適切な技術導入による情報流通基盤としての可能性
情報ネットワーク論I 第12回
–
–
–
–
44
45
ファイル保護
ユーザー保護
課金
ファイルの追跡保証
情報ネットワーク論I 第12回
46
よいところを取り出そうという試み
 P2Pネットワークの積極的利用
– 2005年10月に、タワーレコードと米Napster社が提携しNapster
ジャパンを設立
– 米Kazaa社は、プロモーションファイルの配布、有料ファイル配信、
広告などによる収益モデルを確立
大規模サービス構築
 Skype
– Gnutella の技術を活用した、音声通信サービス
– 全世界的に大規模に展開中
情報ネットワーク論I 第12回
47
情報ネットワーク論I 第12回
48
8
2009/5/22
なぜ大規模化が必要なのか
負荷分散がキー
 大多数のクライアントに、尐数のサーバ
 負荷分散 (load balance) を実現する機構が必須
 ロードバランサ (LB; Load Balancer) を広く活用
 動作原理
全体で一つのサーバに見える
– TCPコネクションの終端点をLBが管理
The Internet
Server1: 192.168.20.1
Client: 163.221.50.15
仮想サーバ: 202.247.15.1
Server2: 192.168.20.2
The Internet
Idempotentな処理
• ロードバランサの利用
• いわゆるクラスタを形成
• 負荷分散・障害管理に有効
副作用有り処理
Forwarding Table
Src: 163.221.50.15
Dst: 192.168.20.[1-3]
• 処理集約を実現
• DB等が対象
情報ネットワーク論I 第12回
Server3: 192.168.20.3
情報ネットワーク論I 第12回
49
50
終端点管理
さらに発展系
 どのサーバにコネクションを終端させるか
 サーバは同一ネットワーク内に無くても大丈夫
– ラウンドロビン方式、最小接続方式、性能観測方式などの様々な
手法が考案・実装されている
– 障害管理も重要
• Server down をどのように知るか
– トンネリングを使って、インターネット上にバラバラにあるサーバ
を一つのサーバに見せることもできる
– Sever federation という呼ばれ方をすることも
 CDN (Contents Delivery Network)
 サーバのアドレスの違いをどのように隠蔽するか
– サーバ側でプライベートIPを使っている場合には、その影響を通
信の中で書き換える必要がある
– 単純なNAT型ではダメ
– さらに ISP で積極的に負荷分散をする方式が一般的になった
– CDNと呼ばれる
– Akamai.com が商業サービスでのパイオニア
• Cookie, HTTPのペイロードにもアドレス情報が埋め込まれているこ
とがある
• アプリケーションプロトコルによっては副作用がある
情報ネットワーク論I 第12回
情報ネットワーク論I 第12回
51
Providing Service at your site….
52
Contents Delivery Network
センターサーバからの最
新のコンテンツの供給
(freshness control)
server
Data Center
IX
clients
clients
情報ネットワーク論I 第12回
53
各ISPに設置されたCD用の
サーバから、自己のISPの顧
客にサービス提供を行う
(well-managed access)
情報ネットワーク論I 第12回
54
9
2009/5/22
別の発展系: anycast の利用
Anycast とは
 経路制御情報を巧みに使うことによって、負荷分散もで
きる
 Root DNS サーバがその典型例
2001::1
HOST
HOST
HOST
HOST
2001::1
2001::1
情報ネットワーク論I 第12回
55
情報ネットワーク論I 第12回
56
Geographical distribution using “Anycast”
 F root DNS
– Originally at ISC in Silicon
Valley, Calif.
– Currently, Hong Kong &
Amsterdam
?
? ?
クライアントからの問い合
わせは、ネットワークの経
路制御に依存して最短の
サーバにたどり着く
Hong Kong, CN
各サーバは同じアドレスを使
いながら、経路情報をそれぞ
れのところから流し込む
Silicon Valley, Calif.
Amsterdam, NL
情報ネットワーク論I 第12回
57
10
Fly UP