Comments
Description
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 – システム・プラットフォームの差異無く、データが正しく表現・理解 されるための基盤 – 例 通信の単位に対して、処理を定義 • 数値１の表現 – 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 副作用問題（１） 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 副作用問題（２） 副作用問題を考えると…. “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流通網への期待 – 適切な価格と利便性によってはコンテンツ購入の顧客となりうる 層が存在することを証明した ユーザーによる自主的な流通網の構築 – コンテンツ流通における最大のコスト要因である流通網の整備 に対しての新しい解が存在することを示した 流通の中抜きによる価格引下げ 著作者からユーザーへの直接的な流通の可能性 コスト問題から無視されてきたマイナー著作物の流通整備 参入コストの低さによる様々な著作物の流通市場の整備 P２P流通網の整備に必要とされる技術例 – – – – → 適切な技術導入による情報流通基盤としての可能性 情報ネットワーク論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