WebNFS ■ 図 4 同時並彳勺 NFS リクエスト サーバーは HTTP サーバーよりも高いトランザクション 負荷を処理できる。 NFS URL をサポートする Web プ ラウサは、同じ Web ページにアクセスし、同しリンクを 扱うことかできる。 HTTP と NFS プロトコルには多くの共通点がある。 いすれも、クライアントとサーバーとのあいだのファイル 中幻当こ利用できる。それでも、両者を入れ替えることはで きない。 NFS サーバーは CGI インターフェイスをサポートし ていないため、サーチェンジンとの ; 叫秀はできないし、サ ーバーサイドのイメージマップのマウスクリック座標を送 るのに NFS プロトコルは使えない (NFS は、クライア ント・サイドのイメージマップなら処理できる ) 。また、 NFS プロトコルは、基本的なファイルタイプしかサポー トしていない。ほとんどのファイルシステムと同様、通常 のファイルやシンポリック・リンクのディレクトリは区別 り、データ区されるのを待っていればよい ( 図 4 ) 。ファ イルのデータをインタリープすることもできる。したがっ できるが、 HTTP の MIME ヘッダでエンコードされた て、大きなファイルのダウンロードと同時に小さなファイ 情報は伝達できない。たとえば、 NFS クライアントは . au と . wav の違いをもつばらファイル名の拡張子によって識 ルのダウンロードもおこなえる。 別している (HTTP サーバーは、 MIME タイプのエン NFS プロトコルは、サーバーの OS に簡単かつ効率 コードにファイル拡張子を用いる ) 。大半のクライアント 的に実装できるよう設言 t されている。プロトコルデータを の実装では、クライアント上でのキャッシュがサポート XDR て符号化しているため、データはワード境界に揃え されているにもかかわらす、 NFS プロトコルは代理サー ら固定長のバイナリ表現になっているので効率的に扱 ーや代理キャッシングをまったくサポートしていない。 える。これは、サーバーの CPU か最小の負荷でもっとも 大多数の Web プラウサはそれぞれ独自のキャッシュ手法 効率よく NFS の処理を実行できるようにするためであっ を使っているので、 HTTP 代理キャッシュでは、複数の た ( 当時のもっとも強力な NFS サーバーの多くは、 CPU クライアントか 1 司じページを見た場合にだけキャッシュ機 に 10MHz の 68020 を使い、数百 MB のディスク空間 構カ黝くようになっている。 へのアクセスを提供していた ) 。 これに対し、 HTTP ヘッダは電子メールメッセージ HTTP を用いて分散型ファイルシステムを構築しよう の最初の部分のような RFC 822 [ 2 ] べースのテキスト・ とすると、 HTTP がそれらの目的のためには言されて フィールドであり、サーバーは解読に古労する。さらに いないことがすぐに分かるはすだ。そもそもファイルシス HTTP サーバーはユーサーレベルのデーモンとして実装 テムという考え方がないので、たとえば、ファイルシステ されるという不利な牛もある。カーネルに実装するより ムにどのくらいの空きスペースがあるのかを簡単に知る方 も移植陸は高いものの、システムコールのコンテキスト・ 法がない。さらに、ディレクトリに対する日寉な念がな スイッチやカーネルからユーサー空間へのデータコピーで く、その標準的な表塘去もない。ファイルやディレクト オーバーヘッドが生してしまう。これらのオーバーヘッド リのリネームもできない。 Web のコンテンツを作る場合、 HTTP はドキュメントをサーバーに置くためにしか使え を最小限に抑えることもできる。しかし、密結合型カーネ ない。ローカルなディスク上の Web ページでイ乍業をした ル窈生能を引き出したり、 OS をチューニングするのは難 だけで、それ以外の機能を求めても馮太なことが分かるだ しい。 NFS プロトコルは、 TCP 接続をより効率的に利用し、 クライアント サ 94 UNIX MAGAZINE 1997.5
イントラネットの場合は、明らかに NFS に軍配が上が る。 NFS では、リモート・ファイルシステムをあたかも ローカルにあるかのようにマウントできる。したがって、 ファイルが手許にあるのと同様であり、ファイル幻 " という考え方自体がなりたたない。実行可能なファイルで あ川ま、マウントしたファイルシステムを PATH 変数に 加えておくだけで使えるようになる。データはサーバー上 に置かれた 1 つだけなので、システム管理者は容易にフ ァイルを最新の状態に保てる。ファイルに変更を加えた場 合も読み込んだ場戸、再度コピーする必要はないし、サー バーの管理者が全ューサーのファイルをバックアッフ。する のも簡単である。 このような利点は、インターネットにもあてはまる。 NFS を利用すれは、自分の OS で日常的に使っている ファイルプラウサでインターネットのアーカイプサイトを 閲覧できるし、わざわざファイルをダウンロードしなくて も、手許のスプレッドシート・プログラムを起動するだ けで該当するデータファイルを開くことができる。 Eth- ernet LAN の利用者にとって、インターネットのバン ド幅はおそろしく狭く感しられるものだ。そのような場合 は、最初にデータをキャッシュに送る待ち時間だけですむ CacheFS などのキャッシュ・ファイルシステムか有効か もしれない。ファイル・キャッシュか利用できなけれは、 ファイル転送を使うしかない。 たとえファイルを転送する場合であっても、 NFS は FTP より優れている。 NFS クライアントはサーバ 接続し、 1 つの TCP 接続ですべてのイ乍業をこなすことが できる。これに対し、 FTP での接続はそれはど控えめな ものではない。クライアントはサーバーにコマンドを送る 際に、 TeInet とほは同様な接続を確立する。サーノヾーが クライアントにファイルを医する場合は、さらに TCP 接続をおこなう。ファイルの終りは接続の中断によって通 知することになっているので、ファイルを転送するたびに TCP 接続カ鯛かれる。通常、 FTP では大きなファイル を転送することが多い。したがって、そのたびに TCP 接 続を開くオーバーヘッドもたいしたことはないと思われる かもしれない。だが、混雑しているサーバー刎則からすれ ば、 TCP 接続は貴重な資源である。 NFS の信頼性には定評がある。「 NFS サーバーか応答 していません (NFS server not responding) 」という UNIX MAGAZINE 1997.5 WebNFS ■ メッセージがありがたくないのはもちろんだが、やがては そのサーバーから OK サインが出て、アプリケーション が仕事を再開することを知っていれは、安じ、して昼食をと りに出かけられる。 FTP の仕様でも再開の手順は定めら れている。しかし、実装されていることはめったにない。 私自身、 28.8Kbps のモデムで 1 時間かけてダウンロード している最中に TCP 接続が切断されてしまい、苛立たし く思った経験がある。 NFS と HTTP 立されると、クライアントはリクエストをいっせいに送 RPC をベースに作られている。 TCP 接続がいったん確 NFS は、非同期リクエストを並行して送れる ONC いく。 たな接続の開始とスロースタートという悪条負 : か加わって れないからだ。このようにして、接続か増えるごとに、新 をダウンロードする際に非同期リクエストを同じ接続で送 ねばならない。なぜなら、 HTTP では、複数のファイル データをダウンロードするたびに新たな TCP 接続を開か ラウザを使っている場合、 HTTP プラウサはそれぞれの る。たとえば、複数の画象を同時にダウンロードできるプ うにみえるが、それでも NFS のほうが優位に立ってい HTTP Keep-Alive で TCP 接続の間題は解消したよ める必要がなくなり、結 : 釉勺に転却間カくなる。 ようになった。これによって、毎回スロースタートから始 のファイルを転送する際にも 1 つの TCP 接続を使える ンが追加された。これで、クライアントとサーバーは複数 HTTP 1.1 の仕様には、、 HTTP Keep-Alive" オフショ ページに移るよりもすいぶん長い時間である。さいわい、 れはならない。 4 分といえば、リンクをクリックして次の 分間の TIME-WAIT 状態でこうした接続を糸旧寺しなけ 像が埋め込まれているからだ。 TCP では、サーバーは 4 かわらす、そのなかにダウンロードしなけれはならない画 の Web ページでは、データ量はそれほど多くないにもか バーヘッドは、 HTTP にとっては深刻である。はとんど いう FTP の非効率的な側面を受け継いでいる。このオー は、転送するファイルごとに新たな TCP 接続を開くと イル転送に使われる点で FTP に似ている。 HTTP 1.0 HTTP は、おもにサーバーからクライアントへのファ 93
WebNFS ■ 図 1 MOUNT のリクエスト / クライアント MOUNT のポートは ? /export/foo の ファイルハンドルは ? 、 FS ポートは ? LOOKUP 0Xf824C ” b 記 ポートは 984 ファイルハンドルは 0Xf824C ポートは 2 国 9 PO m 叩内 r Portmapper ー MOUNT @四代984 NFS@port2049 ファイルノ、ンドルは 0X203d 下のほうにある場合、 NFS プロトコルでは 1 回ごとの LOOKUP 操作しか定義されていないため、ファイルハ ンドルを取得するために数回の LOOKUP リクエストを おこなわねばならない。そのたびにリクエスト / 応答の手 順か加わるので、さらに待ち時間が長くなる。たとえは、 クライアントが pub/project/whizbang/src/main. c というパスを解釈する場合、各コンポーネントごとに 1 回 すっリクエストを送らねはならないので、結果的に 5 回の LOOKUP リクエスト / が発生する。 WebNFS では、 NFS v. 2 と v. 3 に加えてノヾプリ ック・ファイルハンドルと MCL (Multi Component LOOKUP)I というイ督はみをサポートしたため、 NFS の 初期化にかかるオーバーヘッドや LOOKUP の待ち時間 を大幅に削減できる。 ロ / ヾプリック・ファイノレ / 、ンドノレ WebNFS サーバーでは、パプリック・ファイルハン ドルを用いたファイルへのアクセスが可能になる。通吊、 NFS ファイルハンドルにはサーバーに固有のデータが含 まれており、これを用いてディスク上にあるファイルや ディレクトリの位置を特定する。たとえば、多くの UN Ⅸ 1 訳注 : パス名に含まれるディレクトリやファイル名などのコンポーネ ントを 1 っすっ解釈するのではなく、複数のコンポーネントを 1 回の 90 LOOKUP 操角三で参照する牋 図 2 パプリック・ファイノレ、ンドル NFS v. 2 すべてゼロ 長さはゼロ NFS v. 3 り、ディレクトリやサプディレクトリ上に置かれたファイ ァイルハンドルはサーバー上のディレクトリに対応してお ファイルハンドルと同じである。ー殳に、ハフ。リック・フ ハンドルは、どのような NFS 操作にも利用できる通常の 別々の値をもっことを除けは、ノワ。リック・ファイル である ( 図 2 ) 。 トの可変長で、ノワ・リック・ファイルハンドルは長さゼロ ロである。 NFS v. 3 のファイルハンドルは最大 64 バイ イト長であり、ノワ。リック・ファイルハンドルはすべてゼ 定義されている。 NFS v. 2 のファイルハンドルは 32 バ なるため、ノウ・リック・ファイルハンドルはそれぞれ別に だし、 NFS v. 2 と v. 3 ではファイルハンドルの書式が異 ファイルの LOOKUP 操作がおこなえるようになる。た によってファイルハンドルを取得することなく、以降の ファイルハンドルはある定数の値なので、 MOUNT 操作 らのデータは、クライアントからはみえない。ノウ。リック・ 番号をイ尉寺している。ファイルハンドルに収められたこれ サーバーは、ファイルのデバイス ID 、 i ノード番号、町に ルをクライアントカ畤定する際に使われる。 MCL UNIX MAGAZINE 1997.5 MCL は WebNFS で初めて導入された機能であり、かな トを 1 つの MCL に置き換えることができる ( 図 3 ー b ) 。 価するのではなく、これら 3 つの LOOKUP リクエス ス、、 a/b/c" を対象にする場合、図 3-a のように順番に評 パプリック・ファイルハンドルでは、たとえば、パ ントに対応するファイルハンドルを返す。 かできる。サーバーはパスを解釈し、最後尾のコンポーネ リック・ファイルハンドルに対応するパス本を渡すこと イアント中の 1 つのパス・コンポーネントではなく、ノワ・ に利用さこのとき MCL を使う。これにより、クラ ハフ・リック・ファイルハンドルは LOOKUP 操作の際
CIFS ■ 多くの DOS/Win32 環竟では歴史的な糸韋から、暗黙の 前提条件と考えられている。 SMB は巨大なコマンドである。 1 つのコマンドが、分 昔ファイルシステムのなかで多くの処理を実行する。数 百のコマンドがあり、それぞれ個別の機能だけを実行する Novell の NCP (Netware Core Protocol) とは好対照 である。 こでは SMB 2.0 から受け継が SMB の性能を 引き出すように設計されたリクエストだけをとりあげる。 これらのリクエストは、 NT LM 0.12 と互換性があり、 CIFS の機能を支える重要な彳齬リを果たす。 CIFS 1.0 お よび旧い SMB リクエストの一部はサポートされていな い。また、一部はより咼機能かつ高陸能なリクエストに置 き換えられている。たとえは、 CIFS では SMB 経由で のプリンタへのアクセスをサポートしていない。これは、 CIFS を純枠なファイルアクセス・プロトコルに移行させ る措置の一環である。 それでは、 CIFS が SMB から引き継いた機能を順にみ ていこつ。 ファイルアクセス プロトコルは、オーフン、クローズ、言もムみ、書込み、 検索という通常のファイル操作をサポートする。 プロトコル・バージョンのネゴシェーション SMB クライアントと SMB サーノヾーとの接続か不寉立 されると、クライアントからサーバーへサービスを要求す る準備ができたことになる。ただし、両者は初めに互いが どのプロトコルなら理解できるのかを確認しなけれはなら ない。クライアントは、理解可能なプロトコルのリストを もとにして、ネゴシェーション・リクエストをサーバーに 送る。サーバーは、クライアントとサーバーの両方か理解 できるプロトコルの山斤のバージョンを選択する。 SMB サーバーの実装では、必要に応じて SMB の方言を実装す れはよい。 2 つのセキュリティ・モード 各サーバーは、ネットワーク上のクライアントか利用で きるリソースを提供する。共有リソースには、ディレクト リ ( とその下に置かれたファイル ) 、名前付きパイフ、プ リンタなどがある。クライアントからみれば、サーバーは 78 ほかのどのサーバーからも共有リソースやサービスの提供 を受けていない。つまり、クライアントは、もつばらその サーバーからファイルやその他のリソースを受け取ると考 えている。 SMB プロトコルは、ファイルアクセスか許可される前 に、サーバーによるユーザー認証を要求する。そして、各 サーバーは自分のユーサーをそれぞれ認証する。クライア ントは、そのリソースへのアクセス許可を得るために、認 証情報をサーバーに送らなけれはならない。 SMB プロトコルのセキュリティには、、共有レベル " と、、ユーザーレベル " の 2 つの方法があり、サーバー側 で選択できる。共有レベルのセキュリティを利用するサ ーはユーザー名を要求するが、アクセス権を得るには パスワードを求められる場合もある。さらに ( 言も囚み、読 み書きなど ) 異なるタイプのアクセスには別のパスワード ( トークン ) を要求することもある。一方、ユーサーレベル のセキュリティを利用するサーノヾーは、アクセスに際して ューザー名とパスワードの両方を要求する。 2 つのレベル のセキュリティを同時に提供する SMB サーバーはない。 ただし、フロトコルとしては、そうしてはならないと定め ているわけではない。 セキュリティに関しては、これ以外にもユーサーのパス ワードの保存と伝送という間題がある。 SMB サーバーが、 パスワードをそのままのかたちで保管することはない。サ ーは、クライアントのパスワードを暗号化して保管す る。サーバーのリソースへのアクセスに際して認証を得る 場合、クライアントは、サーバーからの間いかけに応じて 自分がパスワードを知っていることを証明できるガ去で応 答しなければならない。 SMB サーバーは、パスワードの 暗号化をかならすしもサポートしていなくてもよい。 ファイルアクセス・モードの化 ファイルのオープンなど、クライアントからのさまざま なリクエストやサーバーからの応答では、下記のような符 号化されたモード情報も同時に渡される。 書込みモード 書込み時にデータをキャッシュするかどうか。 ・ write through : キャッシュせすに、直接ファイル へ書き込むようにサーバーに孑バする。サーバーは書 UNIX MAGAZINE 1997.5
WebNFS ■ は、いかなるものにもアクセスを認めている点で、より柔 軟である。 シンポリック・リンク でプロトコルの切替えが簡単におこなえることが前提とな る。ただし、この場合はクライアントの Web プラウサ HTTP サーバー上のドキュメントを参照することもでき シンポリック・リンクでは、 HTTPURL を指定して nfs : //newserver/dir/file ルカ甘旨定できる。これは、たとえば次のようになる。 URL を指定することで、別の NFS サーバー上のファイ できる。したがって、シンポリック・リンクで NFS の WebNFS では、シンポリック・リンクの URL カ甘旨定 るリンクはサーバーのルートからの相対パスである。 キュメント・ルートからの相対パスであり、絶対パスであ スラッシュて始まる URL パスは、 HTTP サーバーのド RFC 1808 の相対 URL についての記述と同しである。 こ刎列を除き、パスと相対リンクを組み合わせる力法は やディレクトリをみつける俵 1 ) 。 ルからの相対パスを新たに作成し、それを用いてファイル スであれは、クライアントはハフ。リック・ファイルハンド ク・リンクカ甘旨し示すパス名がスラッシュで区切られたパ りと調面をクライアントの手に委ねてしまう。シンポリッ はファイルハンドルを返し、シンポリック・リンクの言翹 ( ンホーネントがシンポリック・リンクであれば、サー たら、それを処理しなければならない。しかし、最後のコ 中のコンポーネントにシンポリック・リンクか含まれてい サーバーがパスの評価に MCL を利用する場合は、途 表 1 シンポリック・リンクの解釈 / ヾス リンク pub/proj/one two pub/proj/one .. / two pub/proj/one /two v. 2 だけをサポートするサー 新しし v ヾス pub/proj/two pub / two /two ノワ。リック・ファイル る。 ロ サーバーのインターネット接続 理想的には、 WebNFS クライアントは TCP でサー ーと接続でき、 NFSv. 3 てハフ・リック・ファイルハン ドルが使えたほうがよい。しかし、工堋大はこの理想にはは ど遠い。大半の NFS サーバーは TCP 接続を認めていな いし、ノウコ ) ック・ファイルハンドルや MCL をサポート するサーバーははとんどない。つまり、クライアントは、 UDP のみ利用する NFS をサポートするサーバー、 NFS 92 ハンドルや MCL などに対応していないサーバーと接続で きなくてはならないのだ。また、サーバーへのリクエスト がファイアウォールに拒否される可能性があるので、サー バーの portmapper を使わないはうがよい。さらに、遅 延増加の原因となる NFS NULL プロシージャの使用は 避けるべきである。 理想のシナリオに j プくには、以下のようにいくつかの 手順を踏む必要がある。 1. サーバーへの TCP 接続を試みる。接続か拒否された場 合は UDP に戻る。 2. ノ。リック・ファイルハンドルからの相対パスに対して、 NFS v. 3 の LOOKUP を送信してみる。ノヾージョン の違いによるエラーでリクエストか拒否されたら、 NFS v. 2 に戻る。 3. NFSERR-STALE ( あるいは同様の ) 工ラーでリクエ ストを拒否されたら、ノワ。リック・ファイルハンドル はサポートされていないものとし、パス名のファイルハ ンドルへの変換に MOUNT プロトコルを用いる。 クライアントがサーバーとのあいだで TCP 接続を確 立できなかったり、あるいは MOUNT プロトコルを使 わざるをえない場合、おそらくそれはファイアウォール経 由て接続されているサーバーである。インターネット上で NFS サーバーを利用するときは、 WebNFS のサポート と TCP への対応が不可欠である。 NFS と FTP UNIX MAGAZINE 1997.5 るのだろうか ? などのファイルアクセス・プロトコルを本寸する必喫があ であるように思われる。では、なぜ FTP の代わりに NFS 数のネットワークでイ吏われ、数多く実装されたプロトコル である。 FTP は、その単純さゆえにひろく普及し、大多 としてもっともよく使われているファイル転送プロトコル FTP はインターネットの基本フ。ロトコルであり、依然
連載 /NET WORTH—@ なっている大学ではとくにそうであるが、デスクトッフ・ 設言では、ネットワーク・トラフィックやサーバーで必要 マシンを多くのユーサーで共有しているので、 1 つのコン な資原を減らすために、デスクトップ側のクライアントに ピュータを特定のユーザーだけのものにすることはできな 多くの機能をもたせている。 いだろう。 POP これまではこのような間題を解決するために、サーバー マシン (UNIX システム、 ニコン、メインフレームな 1980 年代、 MacOS のユーザー・インターフェイスに人 ど ) にメールを集中させ、ユーサーに TeInet 端末やダム 気か集まったとき、ひろく使われているクライアント・サ 端末などで VAX や UNIX ホストにリモートログインし ーバーモデルに従って、別のカ 1 去のメールシステムか開発 てもらっていた。ューサーは、サーバーマシンにログイン された。 POP (Post Office Protocol) は RFC の過程を し、サーバー上で文字べースのアプリケーションを動かし 経て、 1984 年に初めて文書化された。 POP は単純なプロ て電子メールにアクセスする。 トコルで、ユーサーは中央のメールサーバーに TCP/IP 従来の方法では、とくにスケーラビリティに問題があ で接続し、受信したメールをローカルのワークステーショ った。サイトでメールを使うューザーか増えるにつれて、 ンやデスクトップ PC にダウンロードしたり、拡張機能 メールホストにログインするユーサー数やホスト上で動い を利用してサーバーにメールを送信し酉占医してもらうこと ているメール・アフリケーションの数か増える。ログイン ができる。 したユーザーは、サーバー上でメールファイルを操作し、 ホストのファイル資源やディスク I/O 資源にかなりの負 POP は何年ものあいだに改訂と変史がおこなわオ L 、最 荷をかける。しかもホストマシンは、メールにより生じる 新の RFC1939 が 1996 年 5 月に発行された ( 表 1 ) 。 大きなネットワーク・トラフィックも処理しなけオ L ばなら POP3 (POP version 3 ) は、現在少数の TCP/IP アフ ない。このガ去でさらに問題なのは、ユーサーのメール・ リケーション・フロトコルしか孑旨定されていない lnter- アプリケーションが低機能なものになることが多い点であ net Standard Protocol (STD 53 ) である。はかの多く る。端末ログインや Telnet でメールホストにアクセスす の TCP/IP アプリケーション (Telnet 、 FTP など ) と ると、ユーサーはホストの文字べースのメール・アプリケ 同様、 POP では、クライアント主導の単純なクライアン ーション (IBM の PROFS 、 VAX Mail 、 elm 、 pine ト・サーバーモデルが使われている。 POP サーバーは、 などのいくっかの UNIX メールプログラム ) を使うしか 予約された TCP ポート (POP3 では 110 番ポート ) で ない。マウスを使った GUI アプリケーションに農れてい クライアントからの接続を待つ。 POP クライアントは、 る Macintosh ユーザーや Windows ユーサーは、前時 サーバーへの TCP コネクションを開き、一里の文字べー f は勺な文字べースのメール・アプリケーションの使い方を スのコマンドを送る。サーバーは、クライアントのコマン 学ばなければならない。 ドが成功す川ま十 OK メッセージを、失敗すれば一 ERR メッセージを返す。クライアントカ鮗了すると、 TCP コ デスクトップで X サーバーを動かすと、魅力的な GUI ネクションは閉じられる ( 図 1 ) 。 べースのメール・クライアント (CDE に組み込まれた Sun の MailTooI クライアントをもとにした DtMail や、 POP には、認証、トランザクション、更新という 3 去も丘 NetManage に買収された Zmail) を使うことがで つのフェーズがある。 POP クライアントは認証のために きるが、この去は直接ネットワークに接続したマシンで ューザー名と文字列を送り、サーバーはそれを使ってユー しか有効ではない。イのダイやレアッフ祠線で X アプリ サーのメールポックスまたはメールドロッフ。が存在し、そ ケーションを動かしても、たいした能は望めない。 PC のユーサーに適切なアクセス権があることを確認する。も や Macintosh 用に X サーバーを購入するのは、高価な ともとの POP3 の認証では、 USER と PASS の 2 つ 買物になる。 のコマンドが使われており、ユーサー名と ( 平文の ) パス ワードを別々にサーバーへ送る。のちにオプションとし これらの去は、クライアント・サーバーエ竟における て、認証用に APOP コマンドが追加された。 APOP を利 現在の流れに逆行することにもなる。現代のソフトウェア 67 UNIX MAGAZINE 1997.5
WebNFS—インターネット対応の NFS by Brent Callaghan Af 「 om UNIX REVIEW WebNFS とは、ファイルハンドルを効率的に取得でき るように NFS プロトコルを才長したものである。ファイ ルハンドルは、サーバー上のファイルやディレクトリの場 所を特定するために NFS のすべての操作て利用される。 WebNFS を使えは、 NFS の適用範囲をファイアウォー ルの殞則にあるインターネット上のサーバーにまて拡大で きる。たとえば、ヒトゲノム・プロジェクトのデータベー スや NationaI Weather Service ( 米国商務省風象課 ) か らデータを直接読み込むようなアプリケーションも作成で きる。 ファイアウォールの壁 UNIX MAGAZINE 1997.5 イアントでは、ェクスポートされたパス名のファイルハ ルハンドルを LOOKUP 操作で取得できる。 NFS クラ れによって、工クスポートされた階層にあるはかのファイ ハンドルをすで ( コ尉寺していることを前提にしている。 NFS プロトコルは、クライアントがどこかのファイル のような理由からである。 で外部のサーバーをマウントするのは難しい。これは、次 ルい めたとしても、 NFS に組み込まれたプロトコルのせい ルの管理者が NFS ポート ( 2049 ) 経由の外部への接続を ネットで一勺な TCP に対応しており、ファイアウォー ティ以外にも間題がある。 NFS クライアントがインター うとする攻撃に弱い。ファイアウォールには、セキュリ め、これらのサーバーはファイアウォール越しに侵入しよ UNIX の認証を用いて NFS サーバーをマウントするた フォルトの、、信頼できるホスト "(trusted host) による ックを通さないように作られている。管理者の多くは、デ 現在、ほとんどのファイアウォールは NFS のトラフィ ンドルを最初に利用する。このファイルハンドルへの変 換には、 NFS の MOUNT プロトコルを利用すること がⅲ甘是となっている。しかし、 MOUNT には予約された ポートがないので、クライアントはサーバーの MOUNT サービス用のポートの指定に PORTMAP プロトコルを 使わなけれはならない。 PORTMAP のサービスは well- known ポート ( 111 ) を使うが、多くのファイアウォー ルは PORTMAP プロトコルへのアクセスを防ごうとす る。なぜなら、このプロトコルがセキュリティの抜け穴 として使われたことがあるからだ。このように、 NFS の MOUNT プロトコルは固定されたポート割当てをおこな わないため、固定されたポート割当てを実行するプロトコ ルを必要とする SOCKS などの代理 (proxy) アプリケー ションは中継できない。 待ち時間の問題 89 目的のファイルやディレクトリがファイルシステムの 特定する。 イアントは PORTMAP プロトコルでサーバーの位置を も、サーバーが別のポートに移されると、ほとんどのクラ NFS サーバーが well-known ホートに登録されていて を示したものである。 る。図 1 は、 MOUNT における主要なリクエスト / 応答 ト / 応答の交換にすくなくとも 100mS の時間が必要にな れた場所にあるサーバーとのあいだでは、 1 回のリクエス きい場合にかなりの負担になる。たとえば、 1 万マイル離 工ストとそれへの応答が発生する。これは、待ち時間が大 ウォール経由での中継か難しいだけではなく、大量のリク PORTMAP と MOUNT プロトコルでは、ファイア
連載 /NET WORTH 図 1 POP のセッション例 クライアント : クライアント : クライアント : クライアント : サー サーバー クライアント : サーバー クライアント : クライアント : クライアント : クライアント : クライアント : ノ、 TCP の 110 番ポートでクライアント妾続を待っ サーバーに接続 + OK QPOP(version 2.2 ー b3 ) ready く 1896.697170952@mfi. com> APOP spirch C4C9334baC560eCC979e58001b3e22fb + OK spirch' s maildrop has 2 messages ( 640 octets) STAT + OK 2 640 LIST + OK 2 messages(640 octets) DELE 1 POP3 サーバーがメッセージ 1 を送信 + OK 240 octets RETR 1 2 400 1 240 + OK message 1 deleted DELE 2 POP3 サーバーがメッセージ 2 を送信 + OK 400 octets RETR 2 + OK POP server at mfi . com signing off (maildrop empty) QUIT + OK message 2 deleted 次ク月妾続を待つ 接続の切断 ており、 Qualcomm で改良か続けられている。 lpswitch は、約 1 年前から Windows NT て動く POP サーバー を販売している。去万版では、 Web プラウサからサー をモニターしたり、管理することかて、きる。 初期の POP クライアントとしては、イリノイ大学ア バナ・シャンペーン校で作られた Eudora があった。 Eudora は、初めはフリー・ソフトウェアであったが、現 在は Qualcomrn か商占占化し Eudora Pro として販売し ている。フリー・ソフトウェア版である Eudora Light は、 ftp://ftp.qualcomm.com/quest/eudora/や http: UNIX MAGAZINE 1997.5 /www.eudora.com/light.html から入手できる。 PC や Macintosh 用の大部分の TCP/IP 製品には、 なんらかの POP クライアントが入っている。 XMIT 拡 張コマンドは POP の RFC で正式に定義されたもので はないが、多くの一ヨ殳的な POP クライアントでは送信 メールの処理を簡単にするために、 POP サーバーはこの 拡張コマンドをサポートしているものとみなす。 POP ク ライアントは XMIT を使って POP サーバーにメール を送り、実際のメール配送をサーバーマシンに任せてい る。これにより POP クライアントにメール交換のため 69
CIFS ■ をサポートするように言されている。ファイルは、パス 名を変更することなく再配置できる。つまり、ユーザーの プログラムか実行される場所にかかわりなく、同じ名前空 間を提供するのである。 MS DFS はさらに、レプリケー ション ( ファイルのコピーが、いくっかの異なる場所に置 かれているかもしれない ) や移動に対するマイグレーショ ン ( ファイルか夥動しても、クライアント・プログラムや クライアントのシステム管理テープルを変更する必要がな い ) をサポートしている。 CIFS には、ファイルやディレクトリの変更通知という 便利な機能もある。 Windows NT ではアプリケーション によってファイルやディレクトリ内容の変更を通知するよ うにサーバーに当求することができるのである。この機能 を利用すると、たとえば、アプリケーションはサーバーに 頻繁にポーリングしなくても、表示をいっ更新するべきか の不忍かて、きる。 CIFS はサーバーの名前角夬に依存しないので、名前解 決の仕様は CIFS には含まれていない。この特徴により、 NetBIOS の CIFS をインターネット上でより効率的に 機能させることができるだろう。 CIFS では、クライアン トはいかなる名前解決機構を用いたサーバー名でも識別で きる。 SMB の初期バージョンでは、フラットなサーバー の名前空間しかサポートしていなかった。 CIFS では、ストリームも利用する。ストリーム名は ファイル上の新しいデータ属性である。個別に叩 1 。 ck 、 ファイルロック、アロケーション・サイズ、ファイルサ イズをもつが、共有はファイル単位でおこなわれる。スト ( コロン ) とスト リームは、それを含むファイル名に リーム名を加えた形式の名前尉寺している。 CIFS は、取消し (SMB クライアントは、その時点で 未角夬のリクエストをキャンセルできる ) や、 64 ピット・ オフセットのファイル、多国語文字セットでの名前付け を容易にする Unicode によるファイル名もサポートして いる。 C 旧 S モジュール構造 82 る。アプリケーションと CIFS / サーバーの名前解決との ン・サーピスがどのように実行されるかを示したものであ 図 2 は、 CIFS 1.0 てサーバーの名・前解決やセッショ 図 2 サーパーの名前解決 アプリケーション CIFS + サーバーの名前解決 * RFC 1001 / 1002 TC P * SMB の f け兼には含まれない。 その他の トランスポート * あいだの薄い層で、アプリケーションから渡されたファイ ル名からサーバー名とサーバーのパスを分離し、名前角夬 機能を呼び出す。そして、 CIFS がそれ以降の処理を引き 継ぐ。 あるいは将来的には、 CIFS のトランスポートから 独立した仕様が定義されるであろう。 CIFS の仕様は、 既存のクライアントやサーバーと相互運用させるための TCP/IP 用と、 NetBIOS session および TCP/IP 用 という 2 つのトランスポート・マッヒングを提供するもの になると思われる。 CIFS の相互運用性 UNIX MAGAZINE 1997.5 はバッチ操作が可能かどうかといったことを oplock で れだけのファイルデータならキャッシュ可能か、あるい すべてのファイルデータをキャッシュしてもよいか、ど するのだろうか。 SMB プロトコルでは、クライアントが クライアントのキャッシュは、性能にどのように景些 検索 (find first/find next) とファイルコピーである。 クである。唯一アトミックといえないのが、ディレクトリ の取出しと設定はアトミック、ないしはは確実にアトミッ ( フラッシュ ) 、ロック、作成、オープン、ファイル情報 るわけではない。ファイルのリネーム、消去、強制書込み すべての SMB リクエストがアトミックだと定義され もっ点である。 なのは、サ→ヾーがクライアントのイ尉寺するロック情報を ューサーの認証がおこなえたことが分かる。もっとも重要 ーサー名などである。ユーザー ID か取得できたら、その たとえば、利用中のプロトコル、最大バッフアサイズ、ユ CIFS は、クライアントごとの状態を数多 <f 尉寺している。 SMB サーバーはステートレス (stateless) ではない。
A S T E C ASTE 95 使いやすい日本語環境を提供しま魂 NFS クライアントを Windows 95 に統合、 [ Wi れ d0W595 対応 NFS クライアン Windows 95 に統合された操作環境 ・ Windows 95 の工クスプローラやネットワークコンビュータアイコ ンから UN Ⅸサーバーやそのファイル、プリンタを直接参照できます ネットワークドライプを割り当てることなく UN Ⅸサーバー上のファイ ルを利用できます MS - DOS プロンプトからも使用できます。 日本語環境に完全対応 ・ ASTEC-NFS 95 は Windows 95 で多く用いられる日本語のファ イル名に対応しているため、 UN Ⅸサーバーであることを意識する ことなく利用できます UN Ⅸサーバーのファイル名の漢字コードが EUC の場合でも、自動的に MS 漢字コードとの間で変換することが できます 簡易なインストール ・インストールとアンインストールは Windows95 の標準に準拠し ているため簡単に行えますまた 32bitVxD 形式で実装しており、 Windows 95 のパフォーマンスを完全に利用できます 集中認証サーバーで一元管理 ・ユーザー認証の機構として、 U N Ⅸサーバー上で動作する pcnfsd による集中認証サーバーが利用できますこれにより認証 のためのバスワードなどをネットワーク管理者が集中管理すること ができます 動作環境 OS 機種 Windows 95 PC/AT 互換機、 PC -98 シリーズ ネットワーク TCP ハ P ネットワーク機能が利用できること 12MB 以上 ( 16MB 以上を推奨 ) メモリ ハードディスク 3MB 価格 1 ライセンス 32 , 800 円 ( 税別 ) ・ ASTEC-NFS95 は米国 FTP Software. lnc が開発し株式会社アスキーサムシンググ ッドにて日本の機種対応および日本語化した InterDrive 95 をもとにした製品です。 資料請求 No. 046