サーバー - みる会図書館

1. UNIX MAGAZINE 1998年3月号

連載 / UN Ⅸマルチメディアーの HTTP との違い (Video Conference) について義しており、蓄積型の VoD のようなものにはさはど関心を示す様子はありませ RTSP の draft は HTTP とよく似ており ( そこかしんでした。しかし、 RTSP の登場により、オンデマンドこで HTTPI.1 を参照しているほどです ) 、 HTTP を拡型もグループの議論の対象になってきました 3 。その後、張するかたちで作られています。ただし、 HTTP とは下 RTP の著者としても知られるコロンピア大学の Henning 己の点が異なります。 Schulzrinne 氏が RTSP のいくっかの問題点を孑商し、・サーバーとクライアントの双方で状態を系早しなけれはそれらを改善した、、 RTSP ' " を提案しました。最糸勺に両ならない。者は協力することになり、プロトコルか整理統合されて・ HTTP にはない、いくつかのメソッドがある。 lnternet-draft の標準化への道が大きく開かれることに・クライアント側からだけではなく、サーバー側からもリなりました 4 クエストを送れる。 RTSP とは何か・缶膽卩とデータの流れカ院全にう隹されている。朋大の Web による VoD の限界を破すべく登場した RTSP のメソッド RTSP は、次のような機能を実現しています。・クライアント間現在のところ、 RTSP ではサー・映像や音声などの連続メディアの再生に必要な情報をでやりとりする 11 不鶤頁のメソッドカ症義されています 6 。 ( サーバーの位置も含めて ) クライアントに提供する。それぞれの役割をざっと説明しておきましよう。・連続メディアを再生する際のクライアント側の重川条件セッションの開始と終了などをサーバーに伝える。・クライアントからマルチメディア情報の再生、停止、録 RTSP のセッションは、 SETUP て始まり、 PLAY 、音 / 録画などの缶衂が可育 RECORD 、 PAUSE などを経て TEARDOWN て終り・蓄積されたテマンド型の情報だけではなく、ライプメデます。ィアに関する情報も提供できる。 SETUP では、サーバー・クライアント間でのポート・ SMPTE (Society of Motion Picture and TeIevi- 番号などのやりとり、トランスポート・メソッド (UDP sion Engineers) をはしめとするさまざまな時間情報や TCP など ) の決定などをおこないます。 PLAY では、を言に取り込むことかて、きる。 SCALE や SPEED といった修飾子を付けることによって逆再生や早送りも指定できます。また、 RANGE を指これにより、 RTSP に対応したメディアサーバーには、定して一 - だけを再生することも可能です。多種多様なクライアントからアクセスすることかできるようになります 5 。一方、クライアント側もサーバーを制御サーパー・クライアント間でのセッション情報の交換する手順の一本化によって単純化することができます。クライアントは、 DESCRIBE メソッドによって URI とはいえ、別々のべンダーが開発したサーバーに 1 つ (Universal Resources ldentifier) で孑日疋されたオプジのクライアントで対応できるようになるとはとても思えまェクトのセッション情報をサーバーに問い合わせることがせん。しかし、たとえは、アクセスしたサーバーの方式にできます。これとは逆に、 ANNOUNCE はサーバーや応して専用のアプリケーションをプラウサイ則のプラグインクライアントから現在の、、セッション情報 " を積極的に知として起重丿庁るといったことが、いまよりすこしは簡単にらせるために利用します。セッション情報は、セッショなりそうです。ンを構成する ( コンポジット ) メディアの言当 ( たとえは、 3 というより、 IETF のグループが自分たちの得意なう日こ巻き込ん・だという印象があります。オプジェクトの記に SDP ( 後をちゃっか 6 ただし、すべてのメソッドの寒見を要求しているわけではありません。り使っていたりして・・最低限要求されているのは、クライアント側では SETUP 、 TEAR- 4 責黴は、 1998 年 1 月 15 日に出さオけこ 0.8 てす。 DOWN と PLAY ( または RECORD) 、サーバー但にゴま SETUP 、 TEARDOWN 、 OPTIONS と PLAY ( または RECORD) で 5 個々のクライアントが、 MPEG や H. 261 などの各種のメディア・フォーマットに圸芯するのは別の話です。す。一三ロ 87 UNIX MAGAZINE 1998.3

2. UNIX MAGAZINE 1998年3月号

RFC2224 では、 URL で NFS 資源を表現するために、新しく、、 nfs " というスキームを定義している。このスキームは、 RFC2054 および RFC2055 で、、 WebNFS" として定義されている「ノ・リックファイル・ハンドル」および「マルチコンポーネント参照」をサポートしており、プロトコル上のオーバーヘッドを最小限に抑えるようになっている。新しく定義された nfs スキームは URL ( RFC1738 ) の表記に従っており、 nfs : // く host> : く port> く url¯path> という書式て表現される。 RFC2226 Ⅲ Broadcast over ATM Networks ATM ネットワーク上ての旧プロードキャスト PS. 、 G. Armitage 他 IP マルチキャスト・サービスにおける IP プロードキャストの利用について石当主している。現在の状態は、、標準化へ窈是唱 " である。 1997 年 10 月 28 日に公開された。 ATM を利用して IP を伝送するために最初に IETF でおこなわれたことは「 Classical IP and ARP over ATM 」 ( RFC1577 ) にロ当されている。 RFC1577 では、 LISs (Logical IP Subnets) 内にあるホストおよびルータ間でのユニキャスト伝送と、集中型の ATM ARP (Address Resolution protocol) サーバーによる LIS 内のホストに対する IP アドレスから ATM アドレスの解決サーピスを定義している。しかし、こではマルチキャストおよひプロードキャスト伝送については触れられておらす、マルチキャストに関してはバケットを複送ることでしか対応できなかった。マルチキャストをサポートするために、「 Support for Multicast over UNI 3.0 / 3.1 based ATM Net- works 」 ( RFC2022 ) が公開された。 RFC2022 では、 RFC1577 で定義された ARP サーバーの代わりとして MARS4 (MuIticast Address Resolution Server) を定義している。また、マルチキャスト・グルーフ。へバケットを送る際に、 MARS から得られた情報を利用して、ポイントツー・マルチボイント VC の確立と管理をおこなう手法に関しても規定されている。 4 M ARS は IP マルチキャスト・アドレスから、 AT M ュニキャスト・アドレスによるマルチキャスト・グルーフべの対ルこ関する情報の登求と、問合をに関する夬をおこなうための集中型のサーバーである。 164 RFC2226 では、 LIS 内での IP プロードキャストを実現する際に RFC2022 をどのように利用するかを述べこて提案されているのは、プロードキャストをている。マルチキャストの特別な形式として実現する手法である。効率的なものではないため、プロードキャスト手法を従来のポイントツー・ポイントによる伝送と同列に扱っていない。あくまでも、プロードキャストを必喫とする、プロードキャストを利用してサーバーを探すクライアント - サー・アプリケーションや、経路制笹ワ。ロトコルでの利用を想定した提案である。 RFC2227 Simple Hit-Metering and Usage-Limiting for HTTP HTTP における簡単な参照計則と利用制限のための拡張 PS. 、 P. Leach 他利用率の計測やその情報を利用した利用制限をおこなうための HTTP 拡張について述べている。現在の状態は、、標準化 , 、、ク是唱 " である。 1997 年 10 月 28 日に公開された。コンテンツを提供する人びとは、「自分の提供している情報がどのくらいの頻度で参照されているのか ? 」という疑問に対する日寉な情報を欲している。現在ではコンテンツがキャッシュされてしまうと、それ以降の情報を知る方法がないため、、、 cache-busting ( キャッシュを無効化する方 ~ ー一般に対する名称 ) " という手法が用いられている。このような去は、内容の一貫性のイ尉寺やセキュリティ上の目的ではなく、たんにアクセス情報を知るためだけに用いられたり、毎回別の広告イメージを送るために用いられているのカ哥堋大である。 RFC2227 て提案されている方法は、実際に出版業界でおこなわれているガ去とよく似ている。出版業界では、出版物の発行者は自分の広告主に、発行物か何回繰り返して読まれたかではなく、どのくらいの人びとが発行物を一度以 - E 読んだのかを報告することが一搬的である。そこで、発行された部数を則し、 1 冊の本が何人に読まれるのかを見積もることで、全体の人数を一予測するというガ去が用いられている。このガ去による結果は正確さという点では劣るが非常に有用である。 RFC2227 では HTTP に新しく、、 Meter" ヘッダを定義し、キャッシュからオリジナル情報を一尉寺しているサー UNIX MAGAZINE 1998.3

3. UNIX MAGAZINE 1998年3月号

連載 /NET WORTH—O アントに応答を返す前に、ファイル書込みバケットをディスクに書き込む必要があった。 NFS version 3 は、 version 2 のいくつかの欠点を解消するために、 Sun 、 IBM 、 DEC カ哄同で発した。性能改善と大きなファイルシステムへの対応 (NFS version 2 の 32 ピットに対して、 version 3 では 64 ビットのファイルサイズとオフセットが使われている ) などの拡張か施されている。 NFS version 3 のプロトコル仕様は、 1995 年 6 月に IETF から RFC として公開された。 1996 年 8 月には、 NFS version 3 の仕様と補助的なプロトコルが X/Open により正式に刊行された [ 1 ] 。 NFS version 3 では転送プロトコルのネゴシェーションが可能で、 UDP と TCP の両方を使うことができる。 NFS を TCP で使うと、 NFS / ヾケットの最大イ直を 64KB までに増やせる。 NFS version 3 は典型的な要求一応答タイフ。のプロトコルとして設言されたので、クライアントとサーバー間の通信回数および頻度はバケットサイズによって決まる。信頼のあるネットワークにおける NFS の性能は、一般にバケットサイズに比例して上がる。 NFS version 3 では、 version 2 よりもかなり効率のよいファイル書込みができる。 NFS クライアントは、オプションを付けることで一漣のファイル書込み要求を送れる。このオプションは、書込みバケットがサーバーでキャッシュできることを示す。これらのバケットか物理的にディスクに書き込まれるのは、 NFS クライアントか書込み完了要求を送ったときだけである。 Sun 、 IBM 、 DEC などのべンダーは積極的に NFS version 3 をサポートしたが、他のべンダー ()P など ) の NFS 製品における対応はかなり遅かった。ファイルサーバーの言羽面には SPEC の開発した NFS べンチマークが使われることが多かったので、主要 UNIX べンダーは自社の NFS と TCP/IP の実装のチュニングおよび性能矼 E に強い関心を示した。各べンダーは、 NFS の仕様に沿うだけでなく、速度向 . 上を求めてさまざまなディレクトリ・キャッシュやその他刎支術を開発した。 NFS のセキュリティ速度が最優先される竟もあるかもしれないが、障害回復の自ヒセキュリティの強化クライアント・サー UNIX MAGAZINE 1998.3 間の認証の改善、管理の簡略化、より細かなアクセス制御といった機能も重要な検言寸事項だろう。たとえは、 Solaris 2.5 の NFS では、 Sun か開発した NFS ACL (Access Control List) フロトコルを用いた ACL をサホートしている。ネットワーク ACL を利用するには、 SoIaris ファイルシステムを ACL 対応にする必要があった。 ACL を使えるように拡張された NFS は、現在のところ Solaris の NFS クライアントとサーバー間でしか動作しない。 So- laris の ACL は POSIX 1003.6 の仕様に準拠している。 ACL は、 DCE (Distributed Computing Environ- ment) の分散ファイルサービスでもサポートされている。 DCE と分散ファイルサーヒ、スは、主要な UNIX システムや他の工竟用のオプション製品として入手できる。分散ファイルサービスでファイルシステム ACL を利用するには、 OS に多くの DCE コンポーネントを追加する必喫がある。これらのコンポーネントはサイズが大きく、ファイルシステムやネットワーク操作用の多くのコードが追加されるため、結果としてかなりの速度低下を招く。これに対し、 Sun の NFS ACL プロトコルは分散ファイルサービス本の生能にあまり大きな景をケえないようだ。 ACL をファイルシステム API の一部として用いるように POSIX 標準を拡張する研究か進められている。しかし、研究が始まってから 3 年以上か経過したが、この成果カ鰾準になる安己はない。 Solaris ではセキュリティ強化のために、 Secure RPC を用いた Secure NFS 方式もサポートしている。認証や鍵交換には Kerberos や Diffie-Hillman 方式を使うことができ、 NFS バケット ( 音号化される。 Secure NFS でセキュリティを強化すると、分散ファイルへのアクセスにかなりのオーバーヘッドか加わり、結果的に性能低下を招ごく当然のこととして、バケットの暗号化や復号化に使われるアルゴリズムをソフトウェアで実装すれば、多くの CPU による処理が必要になる。分散ファイルサーピスでは、速度かセキュリティを尺できるが、両立させることはできない。分散ファイルシステムの今後 NFS version 4 に関する研究は、 1996 年後半から本ヒしている。おもな機能として、国ヒインターネッ 109

4. UNIX MAGAZINE 1998年3月号

連載 /NET WORTH—O ファイルアクセス・プロトコルを UNIX 上で動かすサー・ソフトウェアがある。これらの PC プロトコルで普及しているものとしては、 Macintosh や PowerPC マシンで使われる AFS (AppIeTaIk File Sharing) プロトコル、 PC NetWare クライアントおよびサーバー間で使われる NetWare フロトコル、 Microsoft (LAN Man- ager 、 DOS 、 Windows 3. x / 95 / NT ) と IBM (LAN Server 、 OS/2 Warp) のクライアントおよびサーバー間で使われる NetBIOS/SMB プロトコルなどが挙げられる。 PC 中心のクライアント側から考えると、すべてのデスクトップ・クライアントに PCNFS プロトコルを追加するよりも、少数の UNIX サーバーに PC 本来のネットワーク・プロトコルを加えるほうカ子都合だ。このカ試なら、大部分の環境では多数のデスクトップ PC のソフトウェア変更かイ腰である。しかし、サーバーの管理や匪能の点から考えると、サーバーの OS にもともと組み込まれているネットワーク・プロトコルをデスクトップ・クライアントでイ吏うはうが合理的だ。 UNIX べンダーは、何年にもわたって NFS や TCP/IP を UNIX 上で開発し、その性能向 - に努めてきた。したがって、う攵ファイルサーノヾーが UNIX マシンであるなら、それは多数のデスクトップ・マシンに PC- NFS を追加することを意未する。このような不幸な状況を招いているのは、デスクトップ業界を支配するべンダーと主要な UNIX サーバーベンダーという 2 つの陣営の思惑か競合し、主を握ろうとして、互いに相手が使うネットワーク・プロトコル ( およびその製品 ) を認めないからである。インターネットの発展にともない、デスクトップ・べンダーは TCP / IP を採用せざるをえなくなった。しかしデスクトップに関していえは、 Microsoft 、 IBM 、 Apple が OS で NFS をサポートするつもりがないことは確実なようだ。このような私利私欲のおかげで、サードバーティー・べンダーは、利益の見込めるデスクトップ TCP/IP ソフトウェアの市場て繁栄を続けられた。たとえ Windows 98 や Windows NT 5.0 で PCNFS がすぐに対応可能だとしても、 Microsoft に方針変更を期待してはならない。同様に、主要な UNIX べンダーは、副業すなわち別売りのソフトウェアとしてしか、 PC プロトコルへの対応に 108 関心を示さなかった。進んで OS に PC プロトコルを組み込もうという UNIX べンダーはないようだ。しかし、いすれはこの難題も鮹夬するだろうと期待している。主要な UNIX べンダーの 1 つか低価格または無科でいすれかの PC プロトコルを OS に組み込む方針を打ち出せは、他のべンダーが追従せざるをえないのは明らかだからである。いまやデスクトップには最初から TCP/IP が組み込まれているので、 Windows 95/NT でのファイルサービスに用いられるプロトコルは、 NetBIOS over TCP で動く SMB が石充である。同様に、現在 Novell は、 Net- Ware ファイルおよひフ。リントサーバー・プロトコルを NetWare/IP 上で動かせるようにしている。このような変崟のおかげで、 UNIX べンダーは、さはど苦労しなくても UNIX システムに Microsoft の SMB や Novell のファイルおよひプリントサービスを追加することができる。 Sun は、 Solaris を載せた新しい Netra サーバーのいくつかで、 SMB 、 NetWare 、 AppleTalk を用いたデスクトップ PC のファイルおよひプリントサーピスにオプションで対応することを決定した 1 。 IBM は、 syntax の製品をもとにしたいくつかのサーバーに同様の機能を組み込んでいる。 SCO (Santa Cruz Operation) は、現在 VisionFS と Advanced Server for UNIX の 2 つの SMB サーバー製品を販売している。日判りの経過とともに、どの程度この方式での対応が本気なのか、そして UNIX べンダーが本当に変化するきっかけなのか、それとも PC 用プロトコルをサポートするための 1 つのイ去にすぎないのかが分かるだろう。さまざまな NFS 1980 年代半ばに Sun から登場した NFS version 2 は、すみやかに UNIX における分散ファイルシステムの事実 - E の標準になった。他のべンダーは、すぐに PC や IBM メインフレームといった各種のコンピュータで NFS をサポートした。 NFS version 2 ではネットワーク転送に TCP/IP の UDP が使われており、 NFS バケットの最大値は 8KB に制限されていた。 NFS は状態をもたないプロトコルで、 NFS version 2 では、サーバーはクライ 1 主 : SoIaris 2.6 のサーバー・パッケージには、 Syntax カ鯛発した SMB サーノヾー Total Advanced Server ( 1 クライアント・ライセンス付き ) が含まれている。 UNIX MAGAZINE 1998.3

5. UNIX MAGAZINE 1998年3月号

NET WORTH 丘 om UNIX REVIEW M. Steven Baker UN Ⅸ上の NFS とネットワーク性能時間のかかる、昔ながらの書面による通信や商取引は Federal Express の翌日酉当土便に、そして FAX や電子メール、現在ではインターネットを利用した清報の医へと進歩している。速さが必須条 f 牛という状兄もあるが、多くの場合、費用や利イ叫生、信頼性、互拠性、管理のしやすさ、セキュリティといった要因のはうが重視されるだろう。こ数回は、リモートの UNIX システム上の資源にアクセスするカ去として、 NFS と SMB (Server Message BIock) プロトコルをとりあげてきた。そのなかで、おもにデスクトップの PC クライアントから UNIX のネットワーク・ファイルサーバーへのアクセスについて述べた。今回は視点を逆にして、 UNIX 側からみたう攵ファイルアクセスやネットワーク性能について述べよう。分散ファイルサービスの性能改善はとんどのネットワークサーバー・アプリケーションは、ネットワークとファイルの双方に対する操作をおこなう。 NFS に代表される分散ファイルサーピスでは、ネットワーク経由での大量のディスクアクセスのように、ディスクとネットワークか最悪の状況であっても対応しなけれはならない。効率的で整缶生のあるファイル処理やレコードのロックが必要な場合 ( 複数のユーサーによるアクセスなど ) には、事態はさらに複雑になる。ディスクに置かれたファイルの読出しカ立 - 勺な Web サーバーや anonymous FTP サービスにくらべて、分散ファイルサーピスのディスク I / O ではかなりのディスク書込みが必要である。典型的なディスク書込みでは、 3 ~ 4 回のシークが必要だろう。ファイルデータのディスクへ 106 の書込みに 1 回、更新されたファイルシステムのメタデータ ( 日イ寸、サイズ、属蹶ディレクトリ情報、プロックポインタなど ) の読み書きに数回である。メモリを多く搭載できるシステムなら、ディスク読出しをキャッシュして、同じファイルの複数回の読出しを抑えるガ去カ彳殳立つ。このガ去は、人気の高いページや画像ファイルがある Web サーバーでよく用いられている。メモリのディスク・キャッシュを多くとるガ去は、 CGI (Common Gateway lnterface) スクリプトを使用する Web サーバーでも有効だ。これらのスクリプト・ファイルはメモリ内に残り、ディスクから繰り返し読み出されることはない。現在のメモリイ耐各を考えると、ネットワーク・アプリケーションを動かすコンピュータにメモサーリを増設するのは魅力的な尺肢である。 CGI は、プロセッサのコンテキスト・スイッチを生にして柔性を提供している。これこそまさに、いつも混雑している web サーバーのいくっかでさえ、いまだに CGI を使っている理由である。いわゆる業界の専門家といわれる人びとは、しばしばこの点を見落としている。彼らは CGI スクリプトの利用を非難し、 Web サーバー専用 API (Netscape の NSAPI や Microsoft の ISAPI など ) を使うように勧める。専用 API を使うと、処理が速くなる代わりに Web サーバーの移植性や強度か犠牲になる。これらの専用 API を用いた実装は、 Web サーバーの拡張として重川する。そのため、独自に羽長した API にバグがあれは、 web サーピス全体の信頼度は下がり、性能低下を招くことさえある。 API 拡張による速度面の利点は、一殳にせいぜい 1 つのスレッドスイッチしか必要とせす、プロセッサによる完全なコンテキスト・スイッチよりも使用する資源やスイッチの切替え回数が少なくなる UNIX MAGAZINE 1998.3

6. UNIX MAGAZINE 1998年3月号

EMC 発。 NFS ファイルサ「超点 1 'Celerra NFS ファイルサーバも、 MC が創る第うなる。業界最高速レベルを達成して、 cel 。を場。さまざまな技術データを訛もが欲しい屬に、よけ ) 亜ん工するために CAI) 、 CAE など最先端部ドリでは、 tJN ー X にることなく ) 衂墓に処理できる INFST' イルサ← - ・ 1 バの冫人が進められています、、 rra は、この最新トレンドに応えて一 "l' の世界リーーダ第第朝 0 か開発した高速大容量 NFS ファイルサーバ、まさに「エンタープライズ仕様」 ' 呼ぶにふさわしい性能、可 ? ー、スケーーーラピリティを実現しました特に処川 ! 度は、べンチ々をク。において塚 053 SI'EC ⅲ、 A 碑 = 門/s。、。@21.2 、という業界最高速レベルを達成。これ以の NFS ソリ亠冖ツ 0 よありません、 , 17 ; 053 SPECnfs—A93! Ops/Sec 高速大容量 NFS ファイルサーバ

7. UNIX MAGAZINE 1998年3月号

Windows 95 、 Windows NT 対応 PC X サーバ XVision EcIipse e れ 7 XVision EcIipse Ve 「 .7 は、 PC X サーバのグローバル・スタンタードとして、ここにまた数々の革新的な先進機能を搭載 PC X サーバの進化は、つねに XVision EcIipse から始まります UN Ⅸホスト上の x セッションを管理する革新的なセッション管理システム「 Vision Resume 」・ UN Ⅸアプリケーションの起動や登録を Windows の「ウイザード」形式で実行可能などを搭載。 Windows との高い親和性を実現。複数の X サーバが同時に起動でき、しかも複数の X サーバのプロファイルを各サーバごと・ホスト工クスプローラを使ってネットワーク上の UN Ⅸマシンを一覧し、 Windows と同じに設定可能。ファイル操作で UN Ⅸファイルを操作可能。 web ブラウザと統合して、 UN Ⅸアプリケーションを Web ブラウザから起動可能。標準小売価格 32 ビット OS 上で完全に最適化され、屈指のハイパフォーマンスを実現。 XVision EcI ipse 1 -User Base Pack \ 78 , 000 * マルチューザライセンスもご用意しています。 Windows 標準の日本語入力システムから X アプリケーションへ日本語入力が可能。「 XVision EcIipse Ve 「 .7 」と「 Vision Resume 」、「 VisionFS Ve 「 2.0 」とをセットにした SCO 製品の統合ソフトウェア「 Vision 97 」もご用意しております。 \ 98 , 000 ~ XVision Eclipse 評価版 XVision Eclipse ver. 7 評価版無償ダウンロードサービスを実施しています。 XVision Eclipse 評価版は、 30 日間無償で評価いただけるものです。無ダウンロードサービス実施中評価後のご購入の際には、弊社代理店より正規ライセンスをお求めください。 Just 00 wnload! http://www.csk.co.jp/bssp/jis/xve/ または http://www.sco.co.jp/ *VlSjon Ræume は、別売です。詳しくは、お問い合わせください。※ UNIX は、米国刈 0 n Company L 協 . がライセンスしている米国および他の国における登録商標です。その他、記載されている会社名、製品名は各社の商標または登録商標です。販売代理店日本語版開発元・技術サポート CSK 株式会社 SCO 株式会社システムインテグレーション事業本部〒 108-8510 東京都港区港南 1 -8-27 日新ビル〒 170-0013 東京都豊島区東池袋 3-22-17 TEL. 03-5462-9678 FAX. 03-5462-9687 TEL. 03-5956-9360 FAX. 03-3986-7239 0 URL http•J/www.sco.co.jp URL:http://www.csk.co.jp/bSsp/jis/xve/ E-maiI:info@sco. CO. jp E-mail :vision@pi.csk. CO. jp 資料請求 No. 047

8. UNIX MAGAZINE 1998年3月号

連載 / UN Ⅸマルチメディア図 2 VOD 士組み Web サーバーメディアサーバー 1 . 初期情報の提供 2. 起動情報の提供 4. コンテンツの要求 5. コンテンツの提供 girls/spiceworld/o-video/media/film. ram にリンクされています。 ReaISystem の場合、 . ram " という孑広張子のファイルはビデオや音声がどこにあるかを示しており、この例の場合も実体は pnm://reall. vmg. co. uk/ spicegirls/spiceworld/film. rm です。つまり、映像をクライアントに送り届けるのは、 Web サーバーではなく ReaISystem のサーバー ( 以ード、これを、、メディアサー " と呼びます ) なのです ( 図 2 ) 。ーは、映像などの連続メディアをクラメディアサーイアントに対して連続的に送信します。 RealSystem をインストールすると、 . rm 、 . ra 、 . ram などの才脣子をもつファイルの Helper Application は、、 ReaIPlayer ' に設定されます。つまり、次のような手続きを踏んで映像が再生されるわけです。 1. Web プラウサでリンクをクリックする。 2.. ram ファイルが送られてくる。 3. Content-type から、クライアントは Helper AppIi- cation として RealPlayer を起重力する。 4. RealPlayer は . ram ファイルの中身からメディアサーーの位置を知り、メディアサーバーに対して映像の送信を要求する。 5. 映像が送られてくる。 6. 映像を Web プラウザに表示する。このように、ひどくややこしい手順です。しかし web をうまく使おうとすると、どうしてもこういうガ去をとらざるをえません。何が周題かそれでは、現在のところ何か凋題になっているのでしょうか。じつは、十記の重川乍をさせるためには、次のような情報のやりとりが必要になるのです。 86 Web クライアント 3. VoD クライアントの起動 6. コンテンツの表示・ Web サーバーとは別の場所に置かれた連続メディア情報の位置情報を教える。・ 1 つのマルチメディア情報は、関連する映像や音声、スライドなどの複数の連続メディアから構成されている ( コンポジット・メディア ) ことがある。これらのコンポジット・メディアの手文情報などを記しなければならす、さらに、それを要求したり、伝えたりする必要もある。ーとクライアントとのあいだで、情報を送ったり、受けたりするポート番号や RTP のセッション番号などをやりとりする必喫がある。ーとクライアントとのあいだで、帯域などの青勺な情報をやりとりする必要がある。・メディアを再生したり、停止したりといった制御をし VoD クライアントなけれはならない。 RTSP の目標は、す。 RTSP の登場これらのやりとりの標準化にありま RTSP か提案された背景には、 VOD に必要な機能がまったく標準化されてこなかったという状況があります。このような状況を打開すべく、 Netscape Communica- tions の Anup Rao 氏と RealAudio の開発兀である Progressive Networks のグループが共同で IETF の MMUSIC WG に提案したのが RTSP の lnternet- draft です 2 [ 1 ] 。それまで、 MMUSIC WG ではもつばら遠隔会議 2 それにしても、 AVT (Audio/Video Transport) グループは、 Real Time という言葉を安易につかうので誤解を招きます。 RTP もそうてすが、けして寒川処理を寒見するものではなく、タイムスタンプなどク刈判Ⅲこ関するをプロトコルに導入しただけです。 UNIX MAGAZINE 1998.3

9. UNIX MAGAZINE 1998年3月号

ロ連載倉敷芸術科学大学のネットワーク構築ー・写真 3 Smart-UPS 1400RA4 写真 2 MasterView CS -104 この製品には、ラックマウント専用のキットもオプション心配だとかいろいろとコメントをいただきました。実際はで用意されています。どうかというと、我か家の DHCP サーバーはすでに 1 昨年までは高価で、この価格帯にはとうてい含められ年数カ月にわたり、トラブルもなく動き続けています。倉なかった Ethernet スイッチも、この値段で買えるよ敷芸科大の学内ネットワークでも、すくなくとも 6 台はうになりました。どうせなら、 10 / 100B e T を自動 Libretto の DHCP サーバーが設置されています。持ち的に識別するスイッチを・・・・ということで、イチ押しは歩いて利用することにくらべれば、ノート PC にとって Bay Networks の NetGear シリーズ「 FS104 」です。置きっ放しの環竟は、楽勝 " なのでしようか。 10 / 100Base T 自動識別の Ethernet スイッチ ( 4 ポート ) で、市場価格では 7 万円前後です。残念ながら、 8 ポ 20 万円コースートや 16 ポートのものは 10 万円をすこし超える価格で、 20 万円をすこし切る程度の予算なら、いまのところは手を出しにくい状況です。無停電電源装置面なスイッチは、ネットワークの状況によっては正常に動かない場合もあります。ここで紹介したスイッチでか購入できます。も起こりうる現象なので、注意が必喫です。コンピュータやネットワークなどの整備をする際、予 10 / 100 混在のネットワークなどで、 100Mbps に接算との関係から軽視されがちな UPS (Uninterruptible 続されているホストから 10Mbps に接続されている Power Supply : 無停電原装置 ) ですが、電源系の障害ホストへトラフィックが集中しているときなどは、俗の多くを防止してくれるたいへん重要な装置です。電源系に "HeadOfLineBlocking" と呼ばれる現象 ( 先頭のパの代表的な害には、停電、瞬停、匍王降下、サージ、スケットが詰まると、後続のバケットも自勺に詰まってパイクなどがあり、場合によってはハードウェア障害やしまう ) か起き、ほかのポートがハングアップしたようなデータの損失といった事態を招きます。これらの障害の大状態に陥ることがあります。もちろん、原因ははかにもあ半は UPS の導入により防止できます。るでしようが、ハプにくらべると障害の特定か格段に難しネットワークの観点からみると、電源系の障害をいのがスイッチの最大の問題点かもしれません。 SNMP で監視できたり、ネットワーク経由で電源の DHCP サーピスを提供するもっとも安易な方法は、 ON/OFF ができるような製品か望まれます。サーバーの ISDN ルータを DHCP 専用サーバーに仕立てあげること運用面では、すくなくとも電源↓章售時に自重加勺にシャットです。さすがに、 DHCP サーバー専用機なるものにはまダウンしてくれる機能か求められています。通常原からだお目にかかったことはありませんが、 DHCP サーバー給電できるものと、特殊な電源エ事が必な ( コンセントとしての機能が組み込まれた低価格の ISDN ルータもあの形状か特殊だとか ) ものがあるので、 UPS であればなります ( おそらく、専用機より ISDN ルータのはうが安いんでもいいわけではありません。ネットワーク環竟におけでしよう ) 。昨年 12 月に京都で翩崔された COP3 け厩る UPS のメーカーとして、業界でもっとも有名なの暖イび方止 . 京都会言では、ヤマハの「 RT80i 」が DHCP が APC (American power Conversion) です。倉敷芸サーバーとして活躍しました。科大でも、同社の UPS を数多く使っています。私たちが使う UPS には、 19 インチ・ラックにマウ昨年は迎未に走って、 Librett020 による DHCP サーントするタイプと床や机に設置する据置きタイプがありーを紹介しましたが、ディスクが不安だとか、放熱が 45 UNIX MAGAZINE 1998.3 ル

10. UNIX MAGAZINE 1998年3月号

連載 /UNIX Communication Notes—O 結果としてネットワーク全体に求められる性能を系隊の企業内ネットワーク (enterprise network) 、あるいはする ) 流行の言葉でいえばイントラネット、工クストラネットで・必要に応してユーサーに課金し、その処理に必要な竹喋は、電子メールサービスと Web サービスの一 f ・分な管理はを実施必要不可欠である。 ( 5 ) セキュリティ里 (security management) ( 8 ) 複染自ヒするセキュリティ里ネットワーク竟におけるセキュリティ保全にかかわる前項で触れたセキュリティ管理は、きわめて曖昧かっ広すべての作業である。具ー勺には、次のようなものがある。義のセキュリティ対策である。しかし、現在のネットワーク運用では、ネットワーク機能だけでなく、システム管理矍すべき情報ク井芋定とも叫秀したセキュリティ対策カ球められている。具イ勺・その情報に対するアクセスポイントの同定には、次のような作業か含まれるようになってきた。・アクセスポイントの保全と制限・安全な通信路の確保新たに考えなければならない管理作業最近、普及し始めた VPN (Virtual Private Net- 前項で述べた 5 つの分類は、ネットワークだけを管理 work) のように、ネットワーク層プロトコルでの暗号する場合には正しいか現在のネットワーク竟を考えると化トンネリング技術などを用いて盜聴対策を施した安全不十分といわざるをえない。とくに、システムに密着したな通イ各を砠呆する作業である。データリンク層での暗管理作業は避けてとおれない。具イ勺には、次のような作号機能をもつモデムの利用、あるいは、 SSL (Secure 業があるだろう。 Socket Layer) のようなアプリケーション・レベルで凾信の暗号化機能をもつサービスの実施などが含まれる。 ( 6 ) 資源の里・ファイアウォール (firewall) の実装ネ、 , トワーク鬻おける共有資源は数多 0 、。たとえは、ファイアウォールとは、外部ネットワークからのアク NFS サーバーて提供されているディスク領域もその 1 っセスを制限し、安全な通信だけを通過させる、セキュリで、アクセス制坤バックアップ、領域管理などが必喫でティ対策を施したゲートウェイである。インターネットある。それ以外にも、プリンタやスキャナなどの入出力機に接続されている組織においては、ファイアウォールの器、あるいはモデムや FAX などの通信機器などがあり、実装と管理・運用は重要な業務である。それらを共有する環竟の整備や、場合によってはアクセス盗聴に強いアカウント管理の排他制御の実装なども必要になる。現在のインターネットでは、ネットワーク内を流れるパ ( 7 ) ネットワーク・サービスの里ケットの盜聴は大きな脅威である。したがって、使し鱠現在のネットワーク竟では、業務に密接に嬲里する下てパスワード (one-time password) などの盗聴に強い己のようなサービスがある。アカウント管理は必頭である。暗号化メールの利用・ sendmail などの MTA (MaiI Transfer Agent) を用電子メールの本文を暗号化し、醋中の盜聴や糒曳からいた電子メールの酉己医システム守る技術は 1990 年代前半から開発力けられてきた。・ POP や IMAP などの、各ューサーのメールポックス現在では、 PGP や S/MIME などの暗号化メールシスへのアクセスサービスを共するサーバー群テムが簡単に使えるようになった。これら支術を利用・ Web サーバーと、 Web プロキシー / キャッシュ・サーできる竟を提供し、ユーサーか安心して電子メールをバーなどの Web に里したサーバー群交換できる環竟を構築・運用することもネットワーク管・ FTP サーノヾー理の重要な業務である。これらのネットワーク・サーピスについても、障害が安全な Web サーバーの運用発生しないような円滑な運用が必喫である。とくに、も匠現在の Web サーバーでは、 SSL 技術を用いてサーバー一三ロ 12 UNIX MAGAZINE 1998.3